MSP Onboarding Checklist: Your First 30 Days Done Right

Picture this: three days after you sign, someone from your new provider asks for your domain admin password so they can "get started properly." No asset register, no signed handover plan, just a request that lands in your inbox like it's routine. It isn't. A proper MSP onboarding checklist runs week by week: discovery and asset inventory in week one, credential handover and a password vault set up straight after, MFA rolled out across the estate in week two, monitoring agents deployed and tested in week three, backup verification with an actual test restore before week four, and a documented 30-day review that either confirms the relationship works or flags trouble early, while you can still walk away.

If your new IT provider skips any of these stages, that's the first red flag.

What should happen before you sign anything

Discovery starts before the contract, not after. A serious MSP will ask for a full asset inventory before they quote: how many endpoints, what's on-premises versus cloud, which line-of-business applications exist, who your current provider is and how the exit is structured. I've seen clients hand over full admin access during a "trial" phase with no signed agreement in place. Don't do this. Discovery should run on a walkthrough and a questionnaire, not live access to production systems. If a provider insists they need domain admin credentials just to give you a quote, that's a sales tactic, not a technical requirement. We cover the red flags to watch for in our buyer's checklist for choosing a managed service provider, worth reading before you get anywhere near onboarding.

What do you withhold until the contract is signed

Nothing sensitive moves until ink is dry. That means no domain registrar access, no DNS control, no admin credentials to your email tenant, no access to backups, and no changes to firewall rules or MFA policy. A trial period, if you agree to one, should run on a sandbox or a limited read-only view, not production admin rights. I've had clients call me mid-panic because a "trial MSP" changed DNS records to demonstrate their monitoring tooling, and the change broke email delivery for two days. Get the contract signed, including a clearly defined offboarding clause, before a single credential leaves your side. This isn't paranoia. It's how you protect yourself if the relationship doesn't work out three months in.

Week one: how should credential handover actually work

Once the contract is signed, credential handover should go through a proper password vault, not a spreadsheet, not an email thread, and definitely not a shared Slack channel. Every credential handed over gets logged: what it is, who has access, when it was last rotated. Any provider still asking you to email them your root password in plain text in the current year should not be managing your infrastructure. Insist on a named vault (1Password, Bitwarden, or whatever your provider standardises on) with individual logins, not one shared master account. This is also the point where you should get a written asset register back from them, confirming what they now have access to and what they don't. If you're still shortlisting providers, our directory of managed service providers lists who publishes this kind of process openly versus who stays vague about it.

Week two: how do you roll out MFA without breaking everything

MFA rollout is where onboarding projects usually stall, because nobody wants to be the person locked out of the finance system on a Friday afternoon. Stagger it. Start with admin accounts and anyone with access to financial or customer data, then move to the wider team over the following days. Give staff a heads-up email before it lands, not after, and have a documented recovery process for lost devices that doesn't involve someone in IT quietly disabling MFA because it's easier. CISA's guidance on multi-factor authentication is a decent baseline if your new provider doesn't already have a rollout plan of their own. If they don't, ask why.

Week three: how do monitoring agents get deployed and verified

Monitoring agents go out server by server, not all at once in a single script run with no verification. A decent MSP will deploy in batches, confirm each agent is reporting correctly, and then show you the dashboard before claiming the job is done. Ask to see actual alerts firing, not just a green tick on a status page. I've dealt with providers who installed monitoring software and never checked whether alerts were actually routing to a human being, so a server sat down for six hours before anyone noticed. Verification isn't optional here. Get a screenshot or a live walkthrough of an alert triggering end to end before you sign off on this stage.

How do you actually verify backups with a test restore

A backup you haven't restored is a backup you don't actually have. This is the single most skipped step in MSP onboarding, and it's the one that causes the most damage later. Insist on a documented test restore within the first month, not a promise that backups are "running fine". Pick a real file or database, restore it to a separate location, and confirm it opens and the data is intact. Get the result in writing with a date on it. If your provider resists doing this because it's "extra work", that tells you everything about how they'll behave the day you actually need a restore during an outage.

By day 30, what documentation should actually exist

By the end of the first month you should have, in writing: a network diagram, an asset register, a credential access log, a documented backup and restore test result, an MFA rollout confirmation, an escalation contact list with real phone numbers, and a written SLA covering response times for different severity levels. If any of this is missing, ask for it before you pay the second invoice. Documentation isn't bureaucracy. It's the thing that saves you when the person who onboarded you leaves the MSP six months later and someone new has to pick up where they left off with zero context.

How does the 30-day review actually work

The 30-day review is a scheduled call or meeting, not an informal "how's it going" email. Go through every item above: was the backup restore actually done, is MFA fully rolled out, are monitoring alerts reaching a real person, is documentation complete. This is also your last easy exit point before the relationship settles into a long-term contract with early termination penalties. If the provider is defensive about this review or tries to skip it, that's data. Providers ranked well on our MSP Ranking Index tend to welcome structured reviews because they've got nothing to hide, and we explain exactly how that ranking works, and why it's about trust rather than raw performance claims, in our MSP Ranking Index explainer.

What do you do if onboarding goes wrong

If credentials aren't handed back properly at any point, if a provider is dragging its feet on a backup test, or if you've been burned by unclear billing during onboarding, don't just quietly move on. Document it and file a claim through HostList so other buyers can see the pattern. We take these reports seriously because onboarding failures are rarely one-off mistakes. They're usually how a provider always operates. CISA also has guidance on reporting incidents if the failure involved an actual security exposure rather than just poor process.

Frequently asked questions

How long should MSP onboarding take from contract to full handover?

A proper onboarding process, covering discovery, credential handover, MFA, monitoring and a verified backup restore, generally takes around four weeks. Anything much shorter usually means steps are being skipped, particularly the backup restore test, which needs real time to schedule and verify properly.

What's the biggest mistake clients make during MSP onboarding?

Handing over admin credentials before the contract is signed. It's the single most common thing I see go wrong, usually because a sales rep frames it as necessary for a "free assessment". Keep access locked down until you've got a signed agreement with a clear offboarding clause.

Should a new MSP demand full admin access on day one?

No. Access should be staged and logged through a password vault as onboarding progresses, not granted in full on day one. A provider asking for everything immediately, with no asset register or access log in return, hasn't got a proper onboarding process. They're just moving fast and hoping you don't notice the gaps.

What happens if the 30-day review flags problems?

Raise them in writing immediately and give the provider a short, specific window to fix them, referencing the exact SLA terms from your contract. If they can't resolve basic issues like an unverified backup or incomplete MFA rollout within that window, this is your cleanest point to exit before the relationship becomes harder to unwind.

The bottom line

Good onboarding is deliberate, staged and documented, with a genuine backup restore test and a proper 30-day review built in from the start. If a provider rushes credential handover or resists that review, treat it as a warning sign rather than a quirk of their process. Use the first 30 days as your clearest window to confirm you have chosen well, because it is also your easiest point to walk away if you have not. Check how a provider is rated before you sign anything, and report onboarding failures when they happen so the pattern is visible to the next buyer.