Documentation & SOPs

Onboarding Into Existing Documentation for MSPs

How to take over a client environment with inherited documentation that ranges from excellent to nonexistent. Covers the assessment, stabilization, and build-out process.

Workflow guide Â· Updated Feb 2026

By MSP Workflows Team

Contents

1.Inheriting Someone Else's Documentation
2.Assess what you've received
3.Secure credentials immediately
4.Stabilize the critical systems
5.Build documentation to your standard
6.Deliver a baseline documentation package to the client
7.Trust nothing you inherit
8.Set realistic expectations
9.What if the previous MSP refuses to hand over documentation?
10.How do you handle a client with no documentation at all?
11.Should the documentation build-out be billed separately?

Inheriting Someone Else's Documentation

When you take over a client from another MSP (or from their internal IT), the documentation you receive ranges from comprehensive to a zip file of random screenshots. Sometimes you get nothing at all and the previous provider ghosts the transition. Regardless of what you receive, treat inherited documentation as unverified until proven otherwise. Credentials may be outdated. Network diagrams may be wrong. Backup configurations may not match what's actually running. Your first job is to assess, not to import.

Assess what you've received

Review whatever documentation the previous provider handed over. Grade it against your documentation checklist: what's present, what's missing, and what's present but looks outdated or suspect. Common findings: credentials that don't work, network diagrams that don't match the actual environment, backup configurations that were changed after the diagram was created, and SOPs that reference tools the client no longer uses. Document what you found and what's missing. This becomes your remediation plan.

Secure credentials immediately

This is the highest priority and it happens on day one. Change all admin-level passwords: domain admin, firewall admin, cloud tenant admin, backup admin, and any shared service accounts. Verify that no unauthorized accounts exist (check Active Directory, Microsoft Entra ID, firewall user lists, and backup tool access). Store the new credentials in your vault. Remove the previous provider's access from everything. This is non-negotiable and should be completed within the first 48 hours.

Stabilize the critical systems

Before building comprehensive documentation, stabilize the three things that will cause the most damage if they fail: backups, security controls, and remote access. Verify that backups are running and recent. Check that antivirus/EDR is active on all endpoints. Confirm that MFA is enabled on remote access paths. If any of these are broken, fix them before doing anything else. A documentation project doesn't matter if the client gets ransomwared during the transition.

Build documentation to your standard

Using your documentation checklist as the guide, build the client's documentation from scratch rather than trying to clean up what you inherited. You'll go faster starting clean than trying to validate and correct someone else's records. Start with the network diagram (scan and map), then device inventory (pull from your RMM agent deployment), then credentials (already handled in step 2), then backup documentation (verify and document actual configuration), then everything else. Target: complete baseline documentation within 30 days of onboarding.

Deliver a baseline documentation package to the client

At the end of the onboarding documentation build-out, provide the client with a summary: what's documented, what gaps remain and when they'll be addressed, and what the ongoing documentation maintenance process looks like. This demonstrates value from day one and sets expectations for the partnership. Clients who see organized, thorough documentation early in the relationship trust the MSP more than clients who never see evidence of documentation at all.

Trust nothing you inherit

Even documentation that looks professional and complete should be verified. The previous provider may have had great documentation practices 18 months ago and then let everything go stale. A network diagram dated last week could still be wrong if it was copied from an older version without verification. Validate everything against the actual environment.

Set realistic expectations

Tell the client that full documentation takes 2 to 4 weeks. Critical items (credentials, backups, security) will be handled in the first 48 hours. Everything else follows a structured build-out. Clients appreciate transparency about the timeline more than a vague promise that everything will be "taken care of."

What if the previous MSP refuses to hand over documentation?

This happens more often than it should. If the previous provider won't cooperate, work directly with the client to reconstruct critical information. The client usually has some credentials (email admin, ISP account), and you can discover the rest through RMM deployment, network scanning, and vendor contact. It takes longer but it's not a blocker.

How do you handle a client with no documentation at all?

Treat it as a green-field documentation project. Deploy your RMM agent to discover and inventory the environment. Run a network scan to map topology. Collect credentials from the client directly. Build everything from scratch against your documentation checklist. It's more work upfront but produces cleaner results than trying to fix incomplete records.

Should the documentation build-out be billed separately?

Some MSPs include it in the onboarding fee. Others bill it as a separate project. Either approach works as long as the cost is accounted for. Don't absorb 20+ hours of documentation labor as an untracked cost. It's real work that produces real value and should be priced accordingly.

← Back to all guides