Why MSP onboarding is its own process
A managed services onboarding is a technical migration wearing a kickoff call as a disguise. The commercial half looks like any other service business. The other half has no equivalent anywhere else: you are inheriting administrative control of the systems the client's business runs on, from a provider who is on their way out.
You are taking custody of admin access
Onboarding a marketing client means a folder and a kickoff call. Onboarding a managed services client means becoming global admin on their identity tenant, their firewall, their hypervisor, and their backup console. Every one of those handovers can fail quietly.
Another provider is being removed mid-flight
In most MSP onboardings there is an incumbent whose agents, admin accounts, and vendor relationships have to come out without an outage. That sequencing constraint does not exist in any other kind of client onboarding.
Agents have to land on every endpoint
RMM, EDR, and backup agents installing on 90 of 104 machines is not 87% done. It is 14 unmonitored, unpatched, unprotected endpoints you will find out about later.
Backups are unverified until you restore one
You inherit a backup configuration, not a working recovery capability. The two are only the same thing after a test restore, and that test belongs inside onboarding, not on the roadmap.
That is why an MSP onboarding checklist is ordered by dependency, not by convenience. Agents cannot deploy before you hold admin credentials. Backups cannot be verified before agents report. The outgoing provider cannot be cut off before you can prove you can operate without them.
How long each phase takes
These are typical elapsed windows across the industry rather than a promise, and they are worth checking against your own last three onboardings. Note the third column: most of the elapsed time in an MSP client onboarding process is spent waiting on somebody who does not work for you.
| Phase | Typical elapsed time | What it usually waits on |
|---|---|---|
| Pre-kickoff discovery | 3 to 10 business days | Client returning the questionnaire and site access |
| Contract and scope confirmation | 2 to 5 business days | Client signature and legal review |
| Credential and admin tenant handover | 3 business days to 3 weeks | The outgoing provider, more than anything else |
| RMM and endpoint agent deployment | 1 to 2 weeks | Machines being powered on and reachable |
| Backup and continuity verification | 3 to 7 business days | Restore test windows and storage seeding time |
| Documentation capture | Runs across the whole project | Whoever is doing the technical work |
| User communication and rollout | 1 week | The client's leadership announcement |
| First 30 days review | Day 30 | A scheduled calendar invite |
A cloud-only client under 25 seats with a cooperative incumbent commonly lands in the two to four week range. Multi-site, on-premises, or regulated environments routinely run six to twelve weeks. If your onboardings run long, measure where the waiting happens before you try to work faster.
The complete MSP client onboarding checklist
Eight phases in dependency order. Prune what does not apply to a given environment during the kickoff, and keep the phase structure identical for every client so a technician moving between accounts always knows where they are.
Pre-kickoff discovery
Everything here should arrive on a questionnaire before anyone drives to a site. Discovery gaps are what turn a fixed-fee onboarding into an overrun.
Owner: Technical lead, with the client's IT champion
Endpoint count by type: workstations, laptops, physical servers, hypervisors and guest VMs, mobile devices in scope
Identity platform and topology: Microsoft Entra ID, on-premises Active Directory, hybrid with Entra Connect, or Google Workspace, and which directory is authoritative
Every SaaS tenant you will be asked to administer, with the account that currently holds global admin on each
Network hardware: firewall make, model, and firmware, switch stack, wireless controller, and any site-to-site tunnels
ISP circuits with account numbers, contract end dates, and static IP assignments
Current backup product, what it covers, retention, where the copies live, and the date of the last verified restore
Line-of-business applications with vendor, support contract, and the internal person who actually owns each one
Existing security tooling: EDR or antivirus product, MFA coverage percentage, email filtering, DNS filtering
Compliance obligations in scope: HIPAA, PCI DSS, CMMC, SOC 2, or cyber insurance control requirements
The outgoing provider, their contract end date, and whether they have been told yet
Anything explicitly out of scope, written down before kickoff rather than argued about after the first ticket
Contract and scope confirmation
Discovery usually changes the numbers the proposal was built on. Reconcile the commercial terms against what you actually found before the technical work starts.
Owner: Account owner
Signed MSA and SOW on file with the service catalog attached
Covered device and user counts agreed, with the true-up mechanism and the review date written down
SLA tiers defined: severity levels, initial response targets, resolution targets, and coverage hours, in the client's language rather than your internal shorthand
After-hours and emergency rates agreed, so the first weekend incident is not a pricing conversation
Named client-side decision maker plus a technical champion authorized to approve changes
Escalation path handed over in writing, in both directions, before anyone needs it
Onboarding project fee and timeline quoted separately from the recurring fee
Letters of authorization signed for ISP, registrar, and vendor account changes
Data handling, confidentiality, and breach notification terms reviewed if the client is regulated
Offboarding and data-return terms agreed now, while the relationship is new
Credential and admin tenant handover
The phase that stalls most often, and the one where a missed step leaves you unable to fix something at 2am. Nothing here belongs in a ticket, an email thread, or a spreadsheet.
Owner: Senior engineer, with a second engineer verifying
Global admin or delegated admin access granted on every tenant in scope: Microsoft 365, Entra, Azure subscriptions, Google Workspace
Break-glass account created, excluded from conditional access, credentials sealed and stored separately from the working set
Domain registrar and DNS access confirmed, with the current zone exported and saved before anything is changed
Firewall, switch, and wireless controller admin credentials rotated to accounts you control, vendor default accounts disabled
Hypervisor, server local admin, and out-of-band management credentials captured and rotated
Backup console access confirmed under an account you own rather than an account the outgoing provider owns
CSP relationship, partner of record, and vendor billing ownership transferred where the contract says they should be
Every credential filed in your password manager or documentation platform against the client record, with MFA enrolled on each administrative account you now hold
The outgoing provider's remaining access enumerated, with a removal date scheduled rather than executed immediately
A written list of any credential you could not obtain, what it blocks, and the recovery path with an owner and a date
RMM and endpoint agent deployment
Deployment is not finished when the installer runs. It is finished when the installed count reconciles against the discovery inventory twice.
Owner: Deployment engineer
Client site or tenant created in the RMM first, with the correct policy group, so no agent lands in a default bucket
RMM agent deployed by GPO, Intune, or scripted install, then reconciled against the discovery endpoint count
EDR or antivirus deployed, with the previous product fully uninstalled rather than left dormant and conflicting
Backup agents deployed and every protected workload confirmed to be assigned to a live job, not just licensed
Patch policy applied with maintenance windows the client approved in writing
Monitoring thresholds configured: disk, memory, service checks, certificate expiry, backup job failure, and offline endpoint
Alerts routed into your PSA with the correct client mapping, so tickets land against the right account from day one
Remote access tested on every endpoint, including the laptops that were not in the building during rollout
Endpoint count reconciled a second time after seven days, because machines that were powered off during rollout are the ones that break your inventory
Outgoing provider's agents removed once yours are reporting cleanly
Backup and continuity verification
You inherited a backup configuration. Until something restores, you have not inherited a recovery capability. Do this inside onboarding, while the client still expects the disruption.
Owner: Backup or infrastructure engineer
Every server, workstation set, and SaaS tenant in scope confirmed to be covered by a defined job
SaaS backup handled separately, since Microsoft 365 and Google Workspace retention is not a backup you can restore from on your terms
Retention configured to match what the contract promised rather than what the previous provider left behind
A real test restore performed: one file, one mailbox item, and one full VM if the client has virtualized workloads
RPO and RTO documented per workload and acknowledged by the client in writing
At least one copy held outside the production environment, immutable if the product supports it
Backup failure alerting routed somewhere a person reads daily, not to a shared mailbox nobody opens
Restore procedure written where an on-call engineer can follow it without calling anyone
Documentation capture
Documentation written during onboarding is accurate. Documentation written six months later is archaeology. Capture it as each phase finishes rather than as a final task.
Owner: Whoever performed the work, reviewed by the technical lead
Network diagram covering circuits, firewall, VLANs, switch stack, wireless, and any site-to-site connectivity
Server and workload inventory with role, operating system, patch state, dependencies, and application owner
Identity documentation: domains, sync topology, conditional access policies, and license entitlement counts
Application list with vendor, support contact, contract number, and renewal date
Runbooks for the client's unusual or recurring procedures, including the ones with no modern replacement
Vendor contact list with account numbers and the authorization each vendor requires before they will talk to you
Renewal calendar for licenses, warranties, circuits, certificates, and domain expiry
Standard operating procedures for anything a new technician would otherwise have to interrupt someone to ask about
A scheduled review date, because the gap between the documentation and the environment is what makes year two harder than year one
User communication and rollout
The client's staff did not choose you and mostly did not know this was happening. What they experience in week one sets how they talk about you internally for a year.
Owner: Account owner, with the client's leadership fronting it
Announcement sent by the client's leadership rather than by you, because adoption follows their authority
Service desk contact routes published: portal, email address, and phone number, with what each one is for
Severity definitions and response targets published in plain language
A short live or recorded session covering the new support process and what changes for users
Direct escalation route given to the office manager or IT champion before they need it
Expectations set for the visible changes: MFA prompts, new agents, password policy, and patch reboots
VIP handling confirmed if the client has executives with different expectations
Out-of-hours contacts collected for the people authorized to approve emergency work
The client's decision maker given a live view of onboarding progress, so status is something they check rather than something they request
First 30 days review
The step most often skipped, and the one that catches everything discovery missed while the client still considers it part of onboarding rather than a complaint.
Owner: Account owner plus the technical lead
Device and user counts reconciled against the contract and billing trued up
First month of tickets reviewed by category, since early ticket themes are a direct readout of what discovery missed
Every backup job confirmed to have succeeded and been verified at least once since deployment
Patch cycle confirmed to have run, with reboot compliance where you expect it
Every remediation item from discovery either closed or converted into a dated project with a named owner
Outgoing provider access confirmed fully revoked and their agents confirmed removed
Thirty-day review held with the client's decision maker: what went well, what is still open, what the roadmap looks like
First monthly report date and first QBR scheduled before the review call ends
Anything you had to correct during this onboarding fed back into the template so the next client starts from the corrected version
Where MSP onboarding actually stalls
Onboardings rarely fail on the technical work. They stall in two places, and both are visibility problems rather than capability problems.
Credentials that never arrive
The incumbent is slow, the registrar login belongs to a former employee, or the firewall password was set in 2019 by a contractor. Track each missing credential as its own task with what it blocks, a recovery path, and a date. A missing credential recorded as a task gets chased. A missing credential mentioned on a call becomes something everyone assumed somebody else had.
Client-side tasks nobody can see
Signing a letter of authorization, approving a maintenance window, producing an accurate staff list. Each takes the client minutes and costs you days, because the delay is invisible to them and looks like your delay from where they sit. Assign client-side tasks to a named person on their side with a due date, in a place they log into.
Both fixes are the same fix: the onboarding has to be visible to the client, not just tracked internally. For the ongoing account rhythm that starts once onboarding closes, see our guide to managing MSP clients at scale.
What the client sees during onboarding
Almost every MSP onboarding checklist is written entirely from the provider's side. The client, meanwhile, has handed over the keys to their business and has no idea what is happening for three weeks. That silence is where the first doubt about the switch starts.
Give the client
The onboarding phases and which ones are finished
Tasks assigned to their side with due dates: registrar login, signed letters of authorization, staff list, approved maintenance windows
Documents you requested and which are still outstanding
Milestones reached, so the account owner can answer their own board without emailing you
Notifications when a phase completes or something needs their input
Keep internal
Credentials, which belong in your documentation platform or password manager, never in a client-facing portal
Internal notes, technician commentary, and time entries
Your other clients and their projects
Draft checklist steps you have not published yet
The practical test: if the client's decision maker wants to know where onboarding stands, can they find out without emailing you? If not, you will spend the whole onboarding writing status updates instead of finishing phases.
Turn this checklist into a Pathalize template
Describe your onboarding in plain English and Pathalize drafts the checklist with phases and owners. Edit it until it matches how your team actually works, save it as a template, and start every future client from the corrected version. Client contacts get a branded portal showing their phases, the tasks waiting on them, and what is finished, and client seats do not consume your paid seats.
Pathalize is not a PSA and not an RMM. Keep tickets and billing in your PSA, monitoring and agents in your RMM, and credentials in your documentation platform. Pathalize is where the checklist lives and where the client watches it move.