The first 30 days with a new managed IT provider sets the tone for the next three years. Done well, MSP onboarding is a structured, documented, predictable process that ends with your environment fully understood, properly secured, and actively monitored. Done badly, it’s a chaotic month of “we’ll get to that” emails — followed by a relationship you’re already tired of by month four.
This is a buyer’s guide to what onboarding should actually look like, week by week. Use it to evaluate whether the provider you’re about to sign with knows what they’re doing, and to hold a current provider accountable if you’re already mid-engagement.
Why onboarding is the truest signal of MSP quality
Sales decks all look the same. Pricing all looks roughly the same. The thing that varies enormously between MSPs — and that almost no buyer evaluates — is how they actually onboard a new customer.
Mature providers run onboarding the way airlines run pre-flight checklists: documented, sequenced, and the same every time. Weak providers run it the way an undergrad runs a group project the night before it’s due. The difference shows up in your day-to-day support quality six months later, but the warning signs are visible inside week one.
Two simple tests:
- Ask any prospective MSP to send you their onboarding runbook for a customer your size. A real provider has one and will share it. A weak provider will say something like “every onboarding is custom” — which usually means undocumented.
- Ask who is responsible for what during onboarding — and whether you’ll have a single named onboarding lead, or just a rotating cast of engineers. A single accountable lead is the difference between weeks 1–4 going smoothly and going sideways.
The 30-day timeline
Here’s what good onboarding looks like, broken into the four weeks. Use this as a checklist against your provider’s plan — and look for what they’re missing.
Week 1: Discovery and documentation
The single most important week. Everything that happens later depends on whether the new provider actually understands your environment.
What should happen:
- Kickoff meeting with your team and the MSP’s onboarding lead, vCIO, and the engineer(s) who will own your account day-to-day. Not just the salesperson.
- Environment discovery — automated scanning of your network, endpoints, servers, cloud tenants, and security posture. Modern MSPs use tools like RMM agents, M365 read-only scans, and network discovery appliances.
- Stakeholder interviews — short conversations with your leadership, finance, and key department leads to understand business context, peak periods, and risk tolerance.
- Vendor and contract inventory — a list of every IT-adjacent vendor (telecom, cloud, software, security, hardware) with renewal dates and contacts.
- Initial documentation drafted in their documentation platform (commonly IT Glue, Hudu, or similar).
What you should receive by end of week 1:
- A written environment summary with what was found
- An issues list of anything urgent the discovery surfaced
- A named primary contact at the MSP
- A secure way to share credentials (a password vault, not email)
If week 1 ends without these deliverables, the rest of the month is going to slip.
Week 2: Tooling deployment and baseline security
The MSP installs their tools and brings your environment under their visibility.
What should happen:
- RMM agent deployment to all endpoints (laptops, desktops, servers) — usually scripted via Group Policy, Intune, or a remote management push. Should be invisible to end users.
- EDR / antivirus migration from whatever you had to whatever the MSP standardizes on. Run in monitor mode for a few days before enforcement to avoid breaking things.
- Patch management activation — the MSP starts seeing patch state across all devices, defines a maintenance window, and either inherits your existing schedule or proposes a new one.
- Email security baseline — verifying SPF/DKIM/DMARC, M365 or Google Workspace tenant audit, removing legacy auth.
- Backup verification — the MSP confirms backups are running, restorable, and meeting retention targets. If backups have been quietly broken for months, this week is when you find out. It happens more than you’d think.
- Privileged access cleanup — old admin accounts disabled, MFA enforced on all admin access, shared accounts retired.
What you should receive by end of week 2:
- Confirmed coverage report — every device the MSP can see, every device they can’t, and a plan for the gap
- Baseline security posture report — what’s in place, what’s missing, and what’s planned
- First successful test backup restore — for at least one important system
Week 3: Process integration and team enablement
This is where the MSP’s processes start replacing whatever ad-hoc support you had before.
What should happen:
- Help desk transition — your team starts opening tickets through the MSP’s portal, email address, or phone. Old support channels (your friend the IT guy, that tech you used to text) are formally closed.
- End-user communication — a clear, plainspoken email goes out to your whole team explaining the new MSP, the new ticket process, and what to do for routine issues.
- Onboarding training session — typically a 30-minute live walkthrough for your team showing how to submit a ticket, how to escalate, and what response times to expect.
- Internal IT handoff (if you have one) — formal documentation of which work belongs to your internal IT staff and which belongs to the MSP, with a shared ticketing convention.
- First QBR scheduled — a quarterly business review on the calendar, typically 60–90 days out, with a defined agenda template.
What you should receive by end of week 3:
- Ticket submission instructions in a format you can forward to staff
- Response time SLA reminder — what’s promised at each severity level
- Escalation matrix — who to call, in what order, when something is on fire
Week 4: Project planning and roadmap
The MSP shifts from “ingesting your environment” to “planning what to do with it.”
What should happen:
- Findings review — a meeting with leadership to walk through the discovery output, security gaps, vendor risks, and capacity issues
- 30/60/90-day roadmap — what the MSP recommends prioritizing in the first quarter, with rough effort and cost estimates for each
- Quick-win deployments — anything urgent (MFA gaps, missing backups, expiring licenses) gets fixed during onboarding, not deferred
- Documentation handoff — you receive read-access to your own documentation in their platform. You should be able to see your network diagrams, password vault, vendor list, and runbooks at any time.
What you should receive by end of week 4:
- A written 90-day roadmap with prioritization rationale
- A completed onboarding sign-off — a formal document confirming what was discovered, what was deployed, and what’s outstanding
- Documentation access to your own data
If you reach day 30 without a written roadmap and full documentation access, the relationship is already off-track.
What good onboarding produces
By the end of 30 days, a buyer working with a competent MSP should be able to answer all of these questions:
- Who is my primary contact at the MSP, and how do I reach their backup?
- How do I (and my team) submit a ticket?
- What response times can I expect at each severity level?
- What’s our security posture today, and what’s the plan to improve it?
- Where is my password vault, my network documentation, and my admin account list?
- What’s on the roadmap for the next 90 days, and how much will it cost?
- Do I trust this team to handle a real incident on a Saturday night?
If you can answer these clearly, onboarding worked. If you can’t, that’s the report card — share it with the MSP and ask for the missing pieces in writing.
What most companies don’t realize
Three things experienced buyers know:
Bad onboarding is rarely fixed by good operations. If the first 30 days were chaotic, undocumented, and rushed, the next three years will operate from a weak foundation. The same engineering bench that runs sloppy onboarding runs sloppy support. It’s almost never the case that an MSP delivers great daily service after a botched onboarding.
Documentation is the truest test of MSP maturity. A provider with thorough, accurate, accessible documentation will outperform a flashier provider with sparse documentation, every time. Ask to see actual documentation samples before you sign — redacted, of course — not just a list of “we use IT Glue” features.
Onboarding is not a place to save money. A discounted or “complimentary” onboarding often means corners cut: shallow discovery, minimal stakeholder interviews, no real findings review. The downstream cost of that shortcut is enormous. Pay for proper onboarding even if it means a one-time fee — it’s the cheapest form of insurance you can buy.
How to evaluate an IT provider’s onboarding before you sign
Use these questions in the sales process:
- “Can I see your onboarding runbook for a customer my size?”
- “Who will lead my onboarding, and how many other onboardings is that person running concurrently?”
- “By day 30, what specifically will I have received in writing?”
- “Who has access to my documentation, and do I have read access from day one?”
- “What’s an example of a discovery finding that surprised a recent customer?”
- “How do you handle backups that have been quietly broken when you onboard a new client? What was the most recent example?”
The answers tell you whether onboarding is a real process at this provider — or a marketing word.
Three things to insist on before signing: (1) a written 30-day onboarding plan with named owner, (2) read access to your documentation from day one, and (3) a 90-day roadmap delivered no later than day 30. None of these are optional.
Frequently asked questions
How long does MSP onboarding take?
Properly done, 30 to 45 days for a 25–150 employee company. Larger or more complex environments (multiple offices, regulated data, custom applications) can extend to 60–90 days. Anything less than 21 days is suspicious — there’s not enough calendar time for real discovery, deployment, and training.
Should I pay an onboarding fee?
Often, yes. A real onboarding involves senior engineering time, vCIO involvement, and a structured deliverables process. A flat fee in the $5,000–$25,000 range is normal for SMB onboarding; some providers waive it on multi-year contracts. Be cautious of “free” onboarding — it’s usually shallow.
What happens if onboarding goes badly?
Document everything in writing as it happens, and escalate to the MSP’s leadership early — not at day 60. Most contracts have a “satisfaction during onboarding” out-clause that lets you exit without penalty if onboarding fails objectively measurable criteria. Read your MSA before you sign for this language; if it’s not there, ask for it.
Will the MSP take over my existing tools, or replace them?
Both, depending on the tool. They’ll typically inherit your Microsoft 365 / Google Workspace tenant, firewalls, and core network gear. They’ll typically replace the RMM, EDR/antivirus, ticketing, and backup tools with their own standardized stack. Ask what’s being replaced and why during the discovery week.
How do I onboard my team to the new MSP?
Three things, in this order: (1) a clear all-staff email explaining the change and the new ticket submission process, (2) a 30-minute live training session with the MSP, (3) a one-page reference card listing how to submit a ticket, what response times to expect, and who to call in an emergency. Most MSPs will provide draft copy for you to send.
Keep learning
- How to Choose an MSP: The Complete Buyer’s Guide — the natural prequel to onboarding
- 12 MSP Red Flags to Watch for Before You Sign — Red Flag #8 covers onboarding warning signs
- MSP Pricing Guide — onboarding fees as a cost category
To compare providers known for strong onboarding, browse the MSP directory.