The MSP Client Handover Document: What a Complete One Contains

What belongs in an MSP client handover document — the documentation package, the credential register, and the receipts that prove they changed hands.

There is no industry-standard handover document for an MSP transition. Most providers improvise one, which is why the same argument replays in contested exits:

"the incoming MSP is claiming they should be given access to all of the systems and there should be a period of co-managed support. Our process has always been once you have access you own it."

— r/msp, March 2026

Both parties in that thread are guessing, because neither has a document that defines what a complete handover is. This article defines one. It's written for all three parties: the outgoing MSP assembling it, the incoming MSP (or internal IT team) receiving it, and the client whose business it actually belongs to.

A complete handover is not one file. It's three deliverables plus the receipts that prove they moved:

1. The documentation package — everything the receiver needs to run the environment.
2. The credential handover register — one row per credential or asset, recording what happened to each. No secrets in it, ever.
3. The credentials themselves — delivered separately, by a method that is not a spreadsheet.

Treat them separately, because they have different security properties and different failure modes.

Part 1: The documentation package

One folder, delivered as a single archive to a client-controlled destination — their SharePoint, their drive. Not the outgoing MSP's portal, which dies at exit. The contents:

1. A README index — what's in the package, the date, and who to contact with questions during the retention window.
2. Full documentation export for the client from the outgoing MSP's documentation platform (IT Glue, Hudu, or wherever it lived).
3. Asset inventory — every endpoint and server: hostname, OS, serial, last user. Exported from the RMM before agents were uninstalled, because in some consoles deleting the device deletes its history. Phase 1 of the MSP client offboarding checklist sequences this export ahead of any uninstall.
4. Network documentation — a diagram (hand-drawn-then-photographed beats nothing), IP schema, VLAN table, ISP circuit IDs and support numbers.
5. Config exports — switches, APs, NAS, hypervisor host list. Firewall configs are the exception: they contain hashed and encoded secrets, so they travel by the encrypted credential channel (Part 3), not in the plain package — with a note in the README saying so.
6. DNS zone file exports for every domain.
7. License and subscription list — what's licensed, through whom, renewal dates, and a flag on everything currently billed through the outgoing MSP. This list is what prevents the "our email stopped working because a subscription lapsed" call in month two.
8. Warranty and support contracts with expiry dates.
9. Post-exit rotation recommendations — the things the outgoing MSP cannot rotate out of its own knowledge. If they held Domain Admin, the receiver should reset the krbtgt password twice (10+ hours apart), reset DSRM passwords on the DCs, and rotate trust and connector account passwords. A professional outgoing MSP writes this paragraph itself; it transfers the responsibility visibly instead of hoping nobody asks.
10. A known-issues list — open tickets at scope freeze, chronic problems, workarounds in place. This is the item most often omitted because it's embarrassing, and its omission is a recurring complaint from incoming MSPs. Include it.
11. The credential handover register (Part 2) — the completed copy travels inside this package.

What the outgoing MSP may legitimately withhold: its internal tooling documentation, its proprietary scripts and automation (unless contracted as deliverables), other clients' data in any form, and the full text of its internal tickets — a summary export of this client's ticket history is a reasonable ask, but many MSAs treat PSA history as MSP property, so scope it by agreement rather than assumption. Whatever is withheld should be listed in the closure paperwork, so it's a decision on paper rather than a discovery later.

The receipt: the package is zipped, hashed, and the receiver confirms in writing — one line naming the filename and its SHA-256 hash. Thirty seconds of effort, and nobody can later claim the package was never delivered or was altered afterward.

Part 2: The credential handover register

This is the document most transitions are missing entirely, and it's the one that settles disputes. The concept:

One row per credential, identity, dataset, or physical asset the outgoing MSP held — tenant admin accounts, break-glass accounts, firewall logins, registrar access, RADIUS secrets, SSL private keys, backup tenancy, Wi-Fi PSKs, even office keys and alarm codes. Each row records:

• What it is (system and credential identity — never the secret itself)
• Who held it at exit
• Its disposition — one of five: rotated-then-transferred (fresh secret set, delivered), transferred as-is (unchanged, with the reason on record), destroyed, client-retained, or retained (temporarily, with a destruction date)
• Delivery method, date, and the named person who confirmed receipt in writing

The register never contains a password. A register containing a password is a leaked-password list with signatures on it. It does, however, map the client's entire estate and its privileged account names — so it travels only inside the package by the client-controlled path, never attached to shared or vendor tickets.

Why the disposition column matters: the default for every shared credential should be rotate-then-transfer — the outgoing MSP sets a fresh secret and hands over that, and the receiver rotates again on receipt. A secret generated fresh and transferred once is provably out of the old provider's hands. A secret their techs typed for five years is not, and no signature can make it so. "Transferred as-is" exists for the genuine exceptions — the copier's scan-to-SMB account hard-coded into forty device address books — and each one carries its reason in writing.

When every row is filled, the register is signed three ways: the outgoing MSP's offboarding lead, the client's authorizer, and the receiving party. That signed page is the proof-of-completion artifact this industry keeps asking for.

Part 3: The credentials — and why the spreadsheet has to die

The status quo, from both directions:

"They just want me to provide an excel document of all the accounts I use"

— r/msp, May 2026

"When you win a new client and you're doing the handover with the incumbent IT provider, what service do you use to receive all the passwords etc? I'm sure there's a better way than a password protected Excel document."

— r/msp, August 2023

There is a better way, and it costs nothing. The rule: secrets never travel with their context in one channel. In order of preference:

1. Password-manager native share — a one-time share link from Keeper, Bitwarden Send with an expiry and access cap, or a 1Password item share restricted to the receiver's email. The platform gates access; the email only carries the link.
2. Encrypted archive, split channel — a 7-Zip AES-256 archive (with filename encryption on) travels by email or file link; the passphrase travels by a different channel — SMS to a verified phone, or read aloud on a call the sender initiated to a number the client provided. Four-plus random words, single use.
3. In person — for hostile exits: printed register, verbal walk-through, signed on the spot. Slowest, strongest.

Never: plaintext email, chat, the PSA ticket, or an Excel attachment — password-protected Excel included; its protection is a speed bump. And before any secret moves at all: verify the receiving party's identity through a channel the client established, never someone who introduced themselves. An MSP transition is a known social-engineering window.

Reading it from the incoming side

If you're the incoming MSP or an internal IT team taking over, this contents list is your demand letter. What you are owed:

• Fresh admin identities created for you on client-owned systems, confirmed working before the incumbent's access is removed — not the incumbent's old passwords.
• The data — final backups, tested, plus a written decision trail on what happens to historical backup sets.
• The package — all eleven items above, receipted.
• Receipted credentials by one of the three methods, with the register telling you which secrets were rotated at handover and which arrived as-is so you know exactly what to rotate first.

What you are not owed: live access to the incumbent's own tooling — their RMM, their PSA, their filter tenancy. Those are their systems, shared across their other clients. The boundary is client-owned systems; everything on the client's side of it transfers, nothing on the incumbent's side does. Knowing that line before the first phone call keeps the transition professional in both directions — and if the incumbent hands you a complete package unprompted, you've learned something about the standard they worked to.

The one-page test

A handover document is complete when a third party — the client's lawyer, an insurance auditor, the next MSP after this one — can pick it up cold and answer three questions: what existed, who has it now, and who confirmed that in writing? If any answer requires someone's memory, the handover isn't done; it's just over.