Guide
The MSP client onboarding checklist (first 30 days)
The contract is signed on a Friday, and on Monday the client’s office manager emails asking why the printer still does not work. That gap between signature and control is where onboarding goes wrong: the new client expects service immediately, while you still do not know where the admin passwords live or which of the forty laptops belong to people who left last year. A written, repeatable checklist closes the gap. Ours splits the first 30 days into a tight first week and a steadier three-week stretch.
Everything here assumes you are working on a network you have been authorized in writing to manage. Get the signed agreement and a named client contact before a single agent goes out.
Before day one
- Confirm scope in writing: which sites, which users, which devices, and what is out of scope (personal phones, the owner’s home network, a line-of-business app the vendor supports).
- Get the outgoing provider’s contact and a handover date, if there is one. Be polite; you will need them.
- Create the client organization in your RMM and PSA with its sites, and create a matching folder in your documentation system.
- Schedule a kickoff call with the decision-maker and the day-to-day contact.
Week 1: discovery and control
The goal of week one is simple: know what exists and hold the keys to it.
| Area | Task | Done when |
|---|---|---|
| Accounts | Inventory every admin account: domain, Microsoft 365 or Google Workspace, firewall, Wi-Fi, NAS, hypervisor, registrar, DNS host | A list exists with owner and MFA status per account |
| Credentials | Move every credential into your vault under the client’s folder; rotate anything shared by email or written down | No credential lives outside the vault |
| Access | Create named admin accounts for your techs; do not share one “msp-admin” login | Each tech has an individual account with MFA |
| Network | Run discovery on the client’s own network (with their approval) to find switches, APs, printers and unmanaged devices | Discovered device list reconciled against client’s list |
| Domains | Record registrar, renewal dates and DNS records; confirm who can log into the registrar | Registrar access confirmed and vaulted |
| Backups | Identify what is backed up, where, and when it was last restored successfully | A test restore is scheduled |
| Contacts | Agree who can authorize changes and who can only raise tickets | Authorized contacts recorded in PSA |
A lightweight asset scanner or network mapper speeds up discovery; see our network and asset tools category and the Lansweeper and Auvik reviews. For a free first pass on the first site visit, Angry IP Scanner lists what answers on the subnet in minutes, and Wireshark is the tool to reach for when an inherited network problem needs packet-level evidence. To see which file shares on old PCs and NAS boxes any user can write to, LizardSystems Network Scanner checks read/write access per share, though client work needs its paid business licence.
Week 1 checklist
- Signed agreement and authorized-contact list on file
- All admin credentials vaulted and high-risk ones rotated
- MFA confirmed on the client’s identity provider admin roles
- Network discovery completed and reconciled
- Registrar, DNS and certificate expiry dates recorded
- Backup status known, test restore booked
- Break-glass account created, credentials sealed in the vault
Deploying the RMM agent through the client’s own tools
Do not email agent links to users and ask them to run them. It trains staff to do exactly what phishing emails ask for, and you lose track of what was deployed. Generate the agent package from your RMM console for that client and site, then push it through the management tooling the client already has.
| Client environment | Deployment route | Notes |
|---|---|---|
| On-premises Active Directory | Group Policy software installation or a startup script scoped to a pilot OU | Start with an OU of five machines, then widen |
| Microsoft Intune | Win32 app or line-of-business app assigned to a pilot group | Use a device group, not a user group, for predictable targeting |
| Apple devices with an MDM | Push the macOS agent package plus its configuration profile for privacy permissions | Without the profile, remote control and scripts will prompt users |
| No central management | Hands-on or remote session per machine, with the user present | Slow, but a good excuse to meet everyone |
A quick check after rollout, run from a domain-joined admin workstation, confirms which computers have checked in to Active Directory recently so you can compare against the RMM’s device list:
$cutoff = (Get-Date).AddDays(-30)
Get-ADComputer -Filter {LastLogonTimeStamp -gt $cutoff} -Properties LastLogonTimeStamp |
Select-Object Name, @{n='LastSeen';e={[DateTime]::FromFileTime($_.LastLogonTimeStamp)}} |
Sort-Object Name | Export-Csv .\ad-active-computers.csv -NoTypeInformationAnything active in AD but missing from the RMM is either offline, blocked, or a machine nobody told you about.
Weeks 2–4: baseline, policy and handover
With agents reporting, move from “what exists” to “what state is it in”.
| Week | Focus | Output |
|---|---|---|
| 2 | Baseline patch and health scan across all endpoints | Baseline patch report: missing updates by severity, OS versions, unsupported machines |
| 2 | Apply monitoring policies: disk, services, backup job status, AV status | Alert noise tuned so every alert means action |
| 3 | Assign devices to patch rings and apply the patch policy | Pilot group chosen with the client contact |
| 3 | Remediate the worst findings: end-of-life OS, disabled AV, no backups | Short remediation list with owners and dates |
| 4 | Documentation handover and first client review | Client-facing summary and internal runbook |
The baseline patch report is the most valuable document you will produce this month. It shows the client where they started, protects you if something old breaks later, and gives the first monthly compliance report a real comparison point. Our monthly patching routine picks up from here.
Weeks 2–4 checklist
- Baseline patch report generated and saved with the date
- Monitoring policy applied and noisy alerts tuned
- Patch rings assigned, pilot users agreed with the client
- End-of-life systems listed with a replacement plan
- Documentation complete: network diagram, asset list, vendor contacts, runbooks
- Former provider’s access removed and confirmed in writing
- 30-day review meeting held and notes filed
Common onboarding mistakes
- Leaving the previous provider’s tools running. Two RMM agents fight over patching and reboots. Remove the old agent once yours is verified, and make sure the old provider’s accounts are disabled.
- Skipping the test restore. “Backups run nightly” is a status light, not evidence.
- Deploying policy before baseline. If you patch first, you lose the before-and-after picture.
- One shared technician login. It makes the audit log useless. See securing your RMM.
Picking the tool that carries the checklist
Multi-tenant organization structure, policy inheritance and good reporting make onboarding faster. Compare the options in our RMM software category, read the NinjaOne review, or see the NinjaOne vs Atera comparison. When you start trials, follow the steps on where to get these tools safely.