A reliable MSP onboarding checklist covers key steps including a structured intake questionnaire, full asset discovery, RMM deployment, a security baseline (MFA, patching, endpoint protection), verified backups, and documented runbooks handed over at a proper kickoff. Run it across 30, 60, and 90 day phases with named owners for each deliverable, and don’t call a client “onboarded” until you’ve completed a test restore and delivered the first SLA scorecard.
TL;DR:
- Completing asset discovery, security hardening, and backup restore tests within the first 60 days is crucial to verify the environment is fully functional and secure.
- Document ownership of all accounts and credentials clearly at the start, and continuously test restore procedures to ensure backup reliability.
- Break onboarding into three phases with specific deliverables and accountable owners, avoiding the pitfalls of treating it as a one-time event.
- Use structured questionnaires and automation to map client systems into your PSA and RMM, ensuring data accuracy and seamless integration.
- Establish clear communication, escalation procedures, and compliance considerations tailored to the client’s industry from day one.
Table of Contents
- MSP onboarding checklist: the 30/60/90 phased plan
- What goes in the onboarding questionnaire?
- How do you document a client’s IT systems properly?
- RMM deployment and monitoring setup
- Security baseline: what has to be non-negotiable
- Backups and the test restore that actually proves recovery
- Kickoff meeting and the welcome kit
- Go-live checks and the first 72 hours
- The first QBR and proving the SLA is real
- How a provider runs this checklist for clients
- Change management and impact assessment during onboarding
- Training and knowledge transfer for the client’s internal team
- Client communication plan and escalation procedures
- Compliance and regulatory requirements relevant to the client
- Integration with the client’s existing IT processes and tools
- Three lessons that actually save onboarding projects
- Get your onboarding handled by a team that’s already run this checklist
- Templates and guides worth keeping on hand
- Sources
MSP onboarding checklist: the 30/60/90 phased plan
Onboarding fails when it’s treated as a single event instead of a sequence. A structured 90 day plan breaks the work into three phases, each with its own deliverables and its own accountable owner, so nothing gets quietly skipped when the team gets busy with other tickets.
Here’s how the phases should run.
- Days 1 to 30, discovery and handoff. Run the kickoff meeting, complete the onboarding questionnaire, and get credentials into escrow. Deploy the RMM agent across all endpoints and servers. Build the baseline documentation set: asset inventory, network diagram, and admin account list. The project lead owns this phase, and the client should receive a documented asset register and a signed access agreement by day 30.
- Days 31 to 60, hardening and verification. Turn on full monitoring with alert thresholds tuned to the client’s environment. Apply the security baseline: MFA everywhere it’s supported, a patch cadence, and endpoint protection with confirmed telemetry. Configure backups and run the first test restore. The technical lead owns this phase, and the deliverable is a documented security posture report plus a written restore result.
- Days 61 to 90, proof and handover to steady state. Hold the first quarterly business review, present the SLA scorecard, and agree on a remediation schedule for anything still open. Account management owns this phase. The client walks away with a scorecard, a punch list with dates, and a clear escalation path for day 91 onward.
The reason this cadence works better than a single “go live” moment is accountability. Each phase has a named owner and a client-facing artefact, so if something slips, you know exactly where and why. Skipping straight to monitoring without finishing discovery is the single most common onboarding mistake, because it leaves technicians guessing about what’s actually on the network when the first ticket lands. A phased approach forces discovery to finish before hardening starts, and hardening to finish before you claim credit for it in a QBR.
What goes in the onboarding questionnaire?
The questionnaire is where onboarding either becomes a system or stays a folder of PDFs nobody opens again. An automated intake process that feeds directly into your PSA and RMM turns client answers into structured records instead of another document to re-type manually.
At minimum, collect:
- Company and site details, including all physical locations and remote workers
- Primary and secondary points of contact, with escalation authority noted
- Existing admin accounts and current owners of each one
- Critical business systems, ranked by what breaks the business hardest if it goes down
- Current service tiers, warranty status, and licence counts for major software
- Existing vendors and any contracts still in force
Map every field to a PSA or RMM record during intake, not after. If a client lists a line of business application, that becomes an asset record with an owner and a criticality rating on the same day, not a note buried in an email thread.
Ownership matters here too. The client retains business ownership of every account and domain; TechBug’s approach, and the standard any competent provider should follow, escrows the credentials without ever taking silent control of the client’s identity.
Pro Tip: Test your questionnaire import into a sandbox PSA record before the first real client fills it out. A broken field mapping on day one means retyping every subsequent client’s data by hand for months.
How do you document a client’s IT systems properly?
Documentation has one job: let a technician who’s never seen this client before resolve an incident at 2am without waking anyone up. That means five specific artefacts, not a folder of screenshots.
A documentation framework built for continuity recommends building these in order, testing each one as you go:
- Asset and vendor inventory, with owner, warranty expiry, vendor contact, physical location, and a criticality rating for every device
- Network diagram showing segmentation, firewall rules, and every point where the client’s network touches the internet
- Restore runbooks, written as step-by-step instructions, not summaries
- Access and credential escrow, stored separately from general documentation
- Dependency maps showing which systems fail if a given server or service goes down
Run automated discovery tools first to pull the bulk of the asset list, then verify manually, because automated scans miss shadow IT, personal devices on the guest network, and anything air gapped for compliance reasons. Well-structured documentation pays for itself the first time a technician outside the original onboarding team has to touch the account.
Store all of it somewhere reachable when production is down. A knowledge base hosted on the client’s own file server is useless during an outage of that same server. Operational readiness reviews should specifically check that documentation is accessible from outside the client’s network, not just that it exists.
RMM deployment and monitoring setup
Getting agents onto every endpoint sounds simple until you hit a legacy line of business application that doesn’t tolerate a new background process. Build compatibility checks into the rollout before you push agents at scale.
- Pilot on a small, low-risk group first. Five to ten machines, ideally excluding anything running specialised or older software, confirms the agent doesn’t conflict with existing tools.
- Roll out in waves, not all at once. Servers first, then workstations, watching each wave for performance issues before moving to the next.
- Enable baseline monitors immediately. Disk space, CPU and memory thresholds, patch status, and backup job success or failure are the non-negotiables from day one.
- Set alert thresholds to the client’s actual environment. A server running at 85% memory constantly might be normal for that workload; a generic threshold will just generate noise.
- Build automation playbooks for the top five recurring alert types so a disk space warning or a failed service restart triggers a scripted fix before it becomes a ticket.
- Test rollback procedures before you need them. If an agent interferes with a critical application, you need a documented way to pull it without breaking production.
Change control matters here more than most technicians expect. Every monitor threshold change or automation script update should go through the same approval step as any other production change, because an untested automation running unattended at 3am can do real damage.
Security baseline: what has to be non-negotiable
Every onboarding needs a hard security floor before you call the client covered, because 42% of cyberattacks target small businesses, and most of them exploit gaps that a basic baseline would have closed.
- Enable MFA on every account that supports it, and document every exception with a written mitigation plan, not a verbal “we’ll get to it.”
- Define a patch cadence with a testing window before deployment, and a documented rollback path if a patch breaks something.
- Deploy endpoint protection and confirm telemetry is actually reporting back, not just installed and assumed to be working.
- Run an access review across every system and remove standing admin rights wherever a lower privilege level would do the job.
Patch testing deserves its own discipline. A patch that breaks a line of business application on a Tuesday afternoon is worse than the vulnerability it was meant to fix, so a structured patch management process with a defined test group before broad rollout avoids that trap entirely.
Pro Tip: Document every MFA exception with a name, a reason, and a review date. “We’ll fix it later” without a date attached is how exceptions become permanent security holes.
Backups and the test restore that actually proves recovery
A backup that’s never been restored is a guess, not a safety net. Onboarding is the moment to prove otherwise, because this is when the client is paying the most attention to what they’re getting.
The standard approach is the 3-2-1 method: three copies of data, on two different media types, with one copy stored off site. Set a Recovery Point Objective and Recovery Time Objective for every critical system individually rather than applying one blanket target across the whole environment, because a file server and a payment processing database don’t tolerate the same amount of data loss.
- Configure backup jobs against the RPO and RTO agreed for each system, not a generic default
- Schedule a test restore before the 60-day mark, never after
- Restore to an isolated environment and verify data integrity, not just that the job “completed”
- Document the restore time achieved against the RTO target, and file it where the client can see it
Requiring a documented test restore during onboarding, rather than deferring it to “sometime in year one,” is the single clearest signal that backups are actually working. An MSP that can’t produce a restore result is asking the client to trust a backup job log, and log entries don’t recover a deleted database.
Kickoff meeting and the welcome kit
The kickoff sets the tone for the entire engagement, and a rushed one costs you goodwill you’ll spend months rebuilding. Send a pre-read pack at least two days before the meeting: the questionnaire results, a draft project timeline, and a list of what the client needs to have ready.
The welcome kit itself should include:
- Primary and after-hours contact details, with response time expectations attached
- A visual project timeline showing the 30/60/90 milestones
- A clear list of client to-dos, including who needs to grant access and by when
- Step-by-step instructions for how staff raise a ticket or request support
Assign roles explicitly during this meeting, not by assumption. Name who owns the client relationship, who owns the technical rollout, and who signs off on each phase gate. A client who knows exactly who to call for what stops flooding the wrong inbox during week one, which alone prevents a good chunk of early friction.
Go-live checks and the first 72 hours
Go-live isn’t a date on a calendar; it’s a gate with conditions attached. Confirm backups are running and verified, agree on a change window with the client, and send a communication ahead of time so nobody’s surprised by a brief service interruption.
- Confirm the pre-go-live checklist is complete, covering backups, monitoring, and a documented rollback plan if something goes wrong.
- Run validation tests across the first 72 hours, checking backup job completion, monitoring alert accuracy, and that every ticket channel is actually routing correctly.
- Have the technical lead sign off on validation results before declaring the environment stable, not the account manager.
- Set an early triage path so anything flagged in those 72 hours goes straight to the onboarding team, not the general queue, because they have the context to fix it fast.
Early incidents in this window aren’t a failure of onboarding. They’re expected, and how fast you catch and fix them is what the client actually remembers.
The first QBR and proving the SLA is real
The first quarterly business review is where onboarding either earns its keep or gets quietly written off as overhead. Bring the SLA scorecard with real numbers, not a summary slide.
- Report uptime against the agreed target, patch compliance percentage, ticket volume trends, and the restore result from the backup test
- Walk through every remediation item still open, with an owner and a target date attached to each one
- Compare the environment against the baseline captured during discovery, so the client can see concrete progress
Pro Tip: Never bring a QBR with an open item that has no date attached. An undated action item signals the engagement has stalled, even if the work is actually progressing.
Document every remediation commitment in writing after the meeting. A verbal agreement to “look into it” evaporates by the next quarter; a dated action item in a shared document doesn’t.
How a provider runs this checklist for clients
A provider can apply this structure across new managed IT engagements, using a vendor-agnostic approach so clients aren’t locked into a single software stack just because it suits an internal preference. Documentation ownership ideally sits with the client from day one; backups should be tested during onboarding rather than assumed, and proactive monitoring should run from the moment agents deploy, not after the first outage forces the issue.
That combination—tested restores, documented ownership, and monitoring live from early onboarding—is what separates effective onboarding from onboarding done on paper. Readers running their own IT team can borrow this structure directly. Those who’d rather hand the whole process to a team that already runs it can see how TechBug’s managed IT services map onto every phase above.
Change management and impact assessment during onboarding
Every technical change during onboarding, from deploying an RMM agent to enforcing MFA, has the potential to disrupt a workflow the client depends on. Treat each one as a change requiring assessment, not a routine task to push through quietly.
Before rolling out any change, document what it affects: which systems, which staff, and what the fallback is if something breaks. A patch rollout that touches an accounting workstation during month end close needs a different timing conversation than the same patch on a spare desktop. Build a simple impact rating, low, medium, high, and require sign off from the account owner before anything rated medium or above goes ahead.
Communicate every change window in advance, even small ones. Staff who find their screen locked for a reboot they weren’t warned about lose trust fast, and that trust is disproportionately hard to win back during onboarding specifically, because the client hasn’t yet built confidence in your judgment.
Keep a change log throughout the 90 days, separate from the general ticket system. When something goes wrong in month four, being able to show exactly what changed, when, and who approved it turns a difficult conversation into a five-minute one. This log also becomes the backbone of your documentation set once onboarding closes, because most of what breaks later traces back to a change made early.
Training and knowledge transfer for the client’s internal team
Onboarding isn’t just about your team learning the client’s environment. It’s equally about the client’s staff learning how to work with you, and skipping that step creates friction that outlasts the whole 90 day window.
Run a short training session for the client’s internal IT contact or office manager, whoever fields the day-to-day questions, covering how to raise a ticket, what counts as an emergency versus a standard request, and how to reset common things like a locked account without waiting on a callback.
Document this training as a short reference guide, not just a live session nobody remembers a month later. A one-page cheat sheet with screenshots covering the top five things staff ask about, password resets, printer issues, VPN connection, beats a lengthy manual nobody opens.
If the client has any internal IT capability at all, be explicit about where the boundary sits. Define what they’re expected to handle themselves and what should always come to your team, particularly around security incidents, where a well-meaning but underqualified internal fix can make forensics much harder later.
Revisit this training at the 60 day mark. Staff who were trained on day one often forget half of it by week three, and a short refresher costs little compared to the tickets generated by confusion over process.
Client communication plan and escalation procedures
A client who doesn’t know how to reach you in an emergency will find out the hard way, usually at the worst possible time. Define the communication plan explicitly during onboarding, not as an afterthought once something’s already gone wrong.
Set out response time expectations by severity level: a full outage gets a different response time than a slow printer. Put this in writing and attach it to the SLA, so there’s no ambiguity when a client calls at 6pm on a Friday expecting the same response time as a Tuesday morning ticket.
Name an escalation path with at least two levels. If the assigned technician doesn’t respond within the agreed window, the client needs to know exactly who to call next, and that person needs to actually be reachable, not just listed on paper.
Agree on communication channels early. Some clients want a shared chat channel; others want everything through a ticketing portal with no exceptions. Mismatched expectations here generate more friction in the first month than almost any technical issue does.
Build a simple incident communication template in advance, covering what you’ll tell the client during an outage, how often you’ll update them, and who sends the all clear. Having this ready before you need it means the first real incident doesn’t turn into an improvised scramble on top of an already stressful outage.
Compliance and regulatory requirements relevant to the client
Compliance obligations vary enormously by industry, and treating every client with the same generic security checklist misses requirements that carry real legal weight for some of them. A medical practice, a legal firm, and a retail business each carry different obligations around data handling, retention, and breach notification.
Identify during the questionnaire stage whether the client operates in a regulated sector and what frameworks apply to their industry specifically. Don’t assume; ask directly, because clients often don’t realise their own obligations until someone points them out.
Where a recognised framework applies, the NIST Cybersecurity Framework gives a solid structural reference for organising controls around identifying, protecting, detecting, responding, and recovering, even for clients with no formal regulatory mandate. It’s a useful common language between your technical team and a client’s compliance obligations, even when it isn’t a legal requirement itself.
Document compliance-relevant controls separately from general IT documentation, because auditors and regulators often want evidence in a specific format, and scrambling to reconstruct that evidence after an incident is far harder than maintaining it as you go.
Never present compliance advice as a substitute for the client’s own legal or industry-specific guidance. Your job is to implement the technical controls a framework or regulation requires; whether a particular framework legally applies to their business is a question for their own compliance advisor or legal counsel, not a call for a technician to make alone.
Integration with the client’s existing IT processes and tools
Few clients are a blank slate. Most arrive with existing tools, informal processes, and habits that took years to form, and onboarding goes smoothly only when you work with those realities instead of replacing everything on day one.
Map what’s already in place during discovery: existing ticketing habits, whatever password manager staff already use, and any automation or scripts the previous provider or internal team built. Some of it will be worth keeping; some will need replacing, but you won’t know which is which until you’ve actually looked.
Where the client uses tools your team doesn’t typically support, decide early whether to integrate with them or migrate away, and be upfront about the tradeoffs of each path. Ripping out a tool staff have used for years without a clear reason creates resistance that slows the entire onboarding down.
Test integrations before relying on them in production. A PSA that’s supposed to sync with the client’s existing accounting software for billing purposes needs a real test with real data, not just a checkbox saying the connection was configured.
Keep a running list of every existing process you’ve decided to keep, replace, or modify, with a reason attached to each decision. That list becomes useful documentation in its own right, and it protects you if a client asks months later why something changed.
Three lessons that actually save onboarding projects
Documentation drifts the moment nobody’s assigned to update it after a change. Tie every documentation update to your change management process, or watch the network diagram go stale within weeks.
Credential ownership gets murky fast if you don’t state it plainly on day one. The client owns their accounts; you hold the keys in escrow, not the other way round.
Skipped restore tests are the quiet failure nobody notices until it’s too late. If a backup has never been restored, treat it as unverified, no matter how clean the job logs look.
— Ru
Get your onboarding handled by a team that’s already run this checklist
Running this whole checklist properly takes real hours: discovery, documentation, MFA rollout, patch testing, and a genuine test restore, all before you’ve delivered a single dollar of ongoing value to the client. Some providers run this exact process regularly as a managed engagement, so the onboarding cost and risk sits with a team experienced in it, not with whoever on your staff can spare the time.
A first engagement with TechBug typically starts with a conversation about your current environment, a straightforward IT consulting session, not a sales pitch, followed by a scoped plan covering managed IT services, security baseline work through Cyber Security – ACSC Essential 8, and backup verification through cloud backup solutions. If your business needs a proper onboarding done once and done right, request a quote and get a scoped plan back within days.
Templates and guides worth keeping on hand
A few resources worth bookmarking alongside this checklist: the NinjaOne client onboarding guide for questionnaire design, the 90 day onboarding structure for phase milestones, the operational readiness guide for documentation scoring, and the downloadable onboarding template for a ready-made starting checklist.
Sources
- MSP Client Onboarding Best Practices and Checklist
- MSP Onboarding Checklist: Your First 90 Days (2026)
- Operational readiness guide