MSP Client Offboarding Checklist: The Full Exit

A complete MSP client offboarding checklist — credential disposition, access removal order, data handover, and the proof-of-completion evidence.

Most MSPs have an onboarding process. Far fewer have an offboarding one. One r/msp poster put it exactly:

"We have a well defined process to onboard new units into a client. The step we keep missing is offboarding."

— r/msp, May 2025

The result is predictable. Months after an exit, the old client's gear is still phoning home:

"The problem is that we still have their Ubiquiti Wi-Fi showing up in our console. No one has removed it."

— r/msp, September 2025

This article is the full checklist, phase by phase, with the two rules that make an exit defensible instead of merely finished. It works for voluntary exits and hostile ones — the phase order never changes, only the clock.

The two rules that govern every phase

Rule 1 — sequencing. You remove your own access last: only after credential disposition, data handover, and the documentation package have been delivered and receipted by whoever is taking over. If you delete your access first and the handover turns out to be incomplete, you've converted a clean exit into an incident, because you can no longer get in to fix it.

Rule 2 — evidence. Open one PSA ticket for the entire exit the moment notice arrives. Every step below that changes state produces an artifact — a screenshot, a CSV export, a receipt email — filed to that ticket. A checkbox is marked done when the evidence is filed, not when the action is performed. At the end, the ticket is your proof-of-completion file. More on why that matters in the last section.

Phase 0 — Notice and decision (Day 0–2)

• Get the notice in writing. If it came by phone, reply the same day by email confirming the end date. No offboarding work starts on a verbal-only notice.
• Open the offboarding ticket. All time, evidence, and correspondence goes there.
• Classify the exit: voluntary or hostile. Hostile means the relationship is broken, the client is uncooperative, or they refuse to name who is taking over. If they only ask for "a spreadsheet of all the accounts," don't stall and don't dump credentials into a spreadsheet — the client's signing authority becomes the receiving party, and everything is handed to them personally, receipted.
• Read the contract before you promise anything. Notice period, whether offboarding labor is billable, data-return and retention clauses, early-termination fees, and any annual license commitments you resell.
• One voice. All communication routes through a single named Offboarding Lead. Techs do not answer scope questions from the client or the incoming MSP.
• Book the sign-offs now. A scope-freeze acknowledgment around day 5 and a closure signing on exit day. Signatures are the step that slips; calendar them on day 0.

Phase 1 — Inventory and scope freeze (Day 1–5)

The inventory is the master list everything else runs from. A system you miss here is a system still in your console six months from now.

• Export the asset inventory from your RMM before anything is uninstalled. Hostname, OS, last user, serial, agent install date. In some RMMs, deleting the device is what queues the agent uninstall and it takes the device history with it — the export has to exist first.
• Enumerate every credential and identity your shop holds for this client. Sweep, in order: your password vault's client folder, embedded passwords in your documentation platform, MSP-held accounts in the client's Microsoft 365 tenant and on-prem AD, network gear local admins, every cloud portal where an MSP email is the login (registrar, DNS, backup, EDR, mail filter, VoIP, ISP, LOB vendors), recovery emails and MFA phones that point at your shop, service accounts your tooling created, break-glass accounts, and certificates and keys. Each item found becomes one row in a register — more on that below.
• Freeze scope. From the freeze date: no new projects, no non-essential changes. Security patching and incident response continue as contracted until the exit date.
• Get the freeze and the inventory summary acknowledged in writing. An email reply saying "acknowledged" is enough at this gate.

Phase 2 — Credential disposition (Day 6–15)

This is the phase that separates a professional exit from a password dump. The rule: you almost never hand over a password you have been using. Either you set a fresh secret and transfer that, or you hand over an existing secret only where rotation would break production — and you record why. A password you generated fresh and transferred once is provably out of your hands the moment the receiver rotates it. A password your team has been typing daily for years is not.

Every credential gets exactly one disposition:

Two steps in this phase deserve special attention:

• Verify the receiving party's identity before any secret moves. Confirm the incoming MSP's contact through a channel the client established — never someone who introduced themselves. Attackers understand that a change of provider is the easiest moment to impersonate one.
• Never transmit credentials with their context in one channel. Password-manager one-time shares are best. Failing that, an encrypted archive by one channel and the passphrase by another (SMS or a call you initiated to a verified number). Never plaintext email, never a spreadsheet — and putting a password on the Excel file doesn't change that; it only slows an attacker down.

Phase 3 — Data and backup handover (Day 8–18)

• Run a backup and prove it restores. One file-level restore from a server backup, one mailbox item if you run SaaS backup. Screenshot both. A backup you didn't test is a rumor, and the final backup is a classic flashpoint in bad-exit disputes.
• Re-run a final backup within 24–48 hours of exit day — a "final" backup taken mid-exit is weeks stale by day 30.
• Decide the fate of historical backup data with the client, in writing. Export and hand over, retain for a defined window then destroy, or destroy at exit on explicit written instruction. If the client won't decide, retain-then-destroy is the defensible default.
• Written receipt for every dataset, with a file hash recorded for anything large.

Phase 4 — Access removal (Day 16–30)

The order inside this phase matters: tool footholds and network access first, your named admin accounts second, partner-level tenancy links (GDAP, CSP) absolutely last — because you may need tenant access to cleanly remove the earlier layers.

• RMM and remote access: uninstall agents from every endpoint, then wait a few business days and sweep for stragglers — devices offline at uninstall stay queued until they next come online. The exit criterion is zero devices reporting, screenshotted, before you delete the client org from your console. This screenshot is the direct cure for the "their Wi-Fi is still in our console" failure quoted at the top.
• Microsoft 365 / Entra ID: remove service principals and app registrations your shop created, your conditional-access exclusions and named locations (not the client's break-glass exclusions — those must survive the exit), your mail connectors and transport rules (after MX moves, never before), and any MSP mailboxes or aliases in the tenant. Departing MSPs leaving their own mailboxes alive in a client tenant is a real, documented failure — one poster reported losing two clients to cheaper competitors and "neither of them disabled our email accounts" (r/msp, May 2024). For the per-user version of this tenant work — departing employees rather than departing MSPs — see the audit-proof M365 user offboarding checklist.
• Firewall and network: export configs first, create the receiver's admin and get their written "I'm in," then remove yours. Delete WAN management rules for your office IPs, tear down site-to-site VPNs at both ends, and transfer device registration or console ownership so licensing renewals chase them, not you.
• DNS and registrar: export zone files, move the domain out of your account if it's in there, and rotate every recovery path that points at your shop. A recovery email pointing at your shop means you still effectively own their domain. And whatever the billing dispute: the domain is client property, full stop. Withhold labor if unpaid — never the domain.
• Your last account in each system is deleted by the receiving party, not by you. You can't delete the branch you're sitting on, and their deletion of your final account is itself evidence. Then attempt a sign-in and screenshot the failure. That failed-login screenshot proves absence of access — which no list of completed steps can.

Phase 5 — Documentation package (parallel with 3–4)

One folder: documentation export, asset inventories, network diagram and IP schema, config exports, zone files, license and subscription list with renewal dates, warranty contracts, a post-exit rotation recommendation for things you can't rotate out of your own head (krbtgt, DSRM), and a known-issues list — incoming teams regularly call out its absence, so include it even when it's embarrassing. Deliver by a client-controlled path, and get a receipt naming the file and its hash. The MSP client handover document breaks this package down item by item — including what may legitimately be withheld — from both sides of the transition.

Phase 6 — Billing closure (Day 20–30)

Stop-billing date in writing. Offboarding labor invoiced as its own itemized line — disputes shrink when the invoice reads like the work. Cancel every client-tied recurring cost on your side, and handle resold license commitments per your contract's early-termination clause, which you read in Phase 0 for exactly this reason.

Phase 7 — Post-exit verification (exit day, T+7, T+30)

• Exit day: every register row has a disposition, date, method, and receipt. Negative-access proof per system. Every tech attests in the ticket: no client credentials in personal vaults or browsers, no client MFA tokens left in authenticator apps.
• T+7: orphan sweep. Search your RMM for the client's hostnames (zero hits expected), check monitoring queues, and search your shared mailboxes for verification-code emails addressed to client systems — the signature of a missed recovery path.
• T+30: execute the scheduled destruction of retained archives, record the date and method, and close the ticket.

The part almost everyone skips: proof

Here is the gap in nearly every offboarding process, in practitioners' own words:

"Whats the best software you guys are using that creates an automatic 'proof of completion' report every time someone is offboarded?"

— r/msp, February 2026

"We disable sign-in, revoke sessions, remove licenses, strip roles, convert mailbox, etc… but at the end of the day the 'proof' is basically just ticket notes and screenshots."

— r/msp, February 2026

The answer isn't software. It's a credential handover register: one row per credential, identity, dataset, or asset you held — with its disposition, date, delivery method, and the name of the human who confirmed receipt in writing. The register never contains a secret; it records what happened to each one. When it's complete, it's signed by your lead, the client's authorizer, and the receiving party.

The test for a finished offboarding is simple: if the client's lawyer, their new MSP, or a cyber-insurance auditor asks "prove you left cleanly" a year from now, can you answer in ten minutes? A signed register plus an evidence ticket answers it. Ticket notes and vibes don't.