MSP Client Offboarding Checklist: Admin Access, Backups, and the Blame Handoff

Client offboarding is where a messy MSP relationship can become a security incident, a billing fight, or a blame museum.

The client wants control. The incoming IT team wants credentials. The outgoing MSP wants to stop being responsible for systems it no longer owns. Everyone says they want a clean handoff. Then nobody can prove who has the DNS registrar login.

That is the problem this MSP client offboarding checklist is meant to solve. It is not a revenge folder. It is a receipt: access transferred, tools removed, backups proven, bills closed, vendors reassigned, and risks accepted in writing.

If you cannot prove those things, you are still in the relationship. You just stopped getting paid for it.

What client offboarding has to prove

Offboarding should answer five questions:

1. Who controls the environment now? Admin rights, vendor portals, domains, DNS, cloud tenants, line-of-business apps, and emergency contacts.
2. What did the outgoing MSP deliver? Documentation, password vault records, network diagrams, backup instructions, support history, and known issues.
3. What access did the outgoing MSP remove? Named technician accounts, delegated tenant access, shared secrets, RMM, EDR, MDM, remote access, backup consoles, and monitoring.
4. What financial obligations remain? Final invoice, prepaid services, license transfers, renewals, cancellation dates, and vendor-owned subscriptions.
5. Who accepted the handoff? A named client signer, date, exceptions, and the list of items still missing.

The goal is not a perfect goodbye. The goal is a defensible one.

CISA's joint advisory for MSPs and customers calls out three relevant basics: identify and disable unused accounts, enforce MFA on MSP accounts that access customer environments, and make ownership of ICT security roles clear in contracts. NIST SP 800-53 AC-2 says account management needs processes for creating, modifying, disabling, and removing accounts, plus alignment with personnel termination and transfer processes. That sounds bureaucratic until a former provider still has a global admin account six months after termination.

This is also where your shared responsibility matrix stops being a compliance artifact and starts being a survival tool. If the matrix never said who owns backups, identity, firewall changes, and vendor coordination at termination, offboarding becomes a memory contest.

Start with the cutover facts

Do not start by exporting everything you can find. Start by naming the transition.

Capture these facts first:

• Contract termination date.
• Technical cutover date.
• Outgoing MSP point of contact.
• Client business owner who can accept risk.
• Incoming provider or internal IT contact.
• Emergency support window during the cutover.
• Systems that must not be changed until after hours.
• Any legal, compliance, or payment disputes that should stay out of the technical meeting.

That last line matters. The handoff meeting is not the place to litigate why the relationship ended. It is where you keep payroll, email, network access, backups, and business apps from becoming collateral damage.

Your MSP SLA should already define coverage windows, exclusions, escalation, and termination conditions. If it does not, offboarding will expose the gap.

The MSP client offboarding checklist

Use this as the working checklist. Add client-specific systems, but do not remove the evidence column. The evidence is the whole point.

Area	What to hand off or close	Done evidence
Microsoft 365 or Google Workspace	Global admin ownership, delegated admin removal, MFA status, license list, mail routing, shared mailboxes, retention notes	Named client or incoming provider admin confirmed, former MSP access removed, screenshot or export saved
Identity and directory	Entra ID, Active Directory, SSO, break-glass accounts, conditional access, security groups	Admin list exported, stale accounts disabled, break-glass owner named, MFA confirmed
Domains and DNS	Registrar login, DNS host, nameservers, SPF, DKIM, DMARC, MX records, website hosting, SSL renewal ownership	Client-controlled login confirmed, current DNS export saved, renewal owner recorded
Network and security	Firewall, VPN, Wi-Fi, switches, ISP, static IPs, port forwards, remote access, SIEM or log tools	Config backup delivered, admin ownership moved, remote access reviewed, exception list signed
Backups	Server backups, Microsoft 365 backup, endpoint backup, SaaS backup, BCDR appliances, cloud storage, restore runbooks	Backup location, retention, billing owner, restore access, and last successful restore test recorded
Password vault and documentation	Passwords, MFA recovery codes, diagrams, vendor contacts, asset lists, procedures, warranties	Export delivered through approved method, client confirms receipt, exceptions listed
RMM, EDR, MDM, and agents	RMM agents, endpoint protection, MDM profiles, patching tools, remote support tools, monitoring alerts	Removal plan documented, timing approved, remaining agents listed with reason
Line-of-business apps	Accounting, ERP, CRM, phone system, print management, industry apps, admin portals	Admin owner changed, vendor support contact updated, open tickets exported
Commercial items	Final invoice, prepaid services, license terms, vendor subscriptions, cancellation dates, hardware return	Final billing note sent, license transfer status recorded, open balances or credits listed
Acceptance	What was delivered, what was excluded, unresolved risks, signer, date	Signed acceptance email, ticket, or document stored with the offboarding record

If this table feels boring, good. Boring is the target state.

Microsoft 365 offboarding for MSP clients

Microsoft's former-employee offboarding guidance starts with a simple idea: block access, protect data, and make sure the right people can still reach mail and files. The client version is bigger, but the logic is the same.

For a Microsoft 365 offboarding MSP workflow, confirm:

• The client has at least two named global admins or appropriately scoped admin roles.
• Former MSP delegated access is removed from the tenant.
• All MSP technician accounts are disabled or deleted after the cutover.
• Shared admin passwords are rotated.
• Break-glass accounts are owned by the client or incoming provider.
• Conditional access policies are exported or documented.
• Mail routing, SPF, DKIM, and DMARC are recorded before DNS changes.
• Shared mailboxes, aliases, and transport rules are documented.
• Microsoft 365 backup ownership is clear, especially if backups sit in the outgoing MSP's storage.

Do not casually delete accounts just because the relationship ended. Some tenants have audit, legal hold, retention, or mailbox access requirements. The offboarding record should say what was disabled, what was transferred, what was retained, and who approved it.

If the environment uses conditional access, pair this with a Microsoft 365 conditional access baseline. You do not want the incoming provider learning during cutover that a legacy policy blocks every admin except one former technician.

Backups are not handed off until restore ownership is clear

Backups create the ugliest offboarding fights because everyone uses the same word for different things.

A backup can mean:

• A BCDR appliance at the client site.
• Cloud storage billed to the MSP.
• Microsoft 365 backup in a vendor portal.
• Image backups tied to an agent license.
• File backups in a bucket the client has never seen.
• Retention snapshots that disappear when the contract ends.

The checklist needs to answer four backup questions:

1. Where are the backups stored?
2. Who pays for them after termination?
3. Who has restore authority?
4. What happens to retention after the final service date?

Do not accept "backups are good" as evidence. Record last successful backup date, last restore test if available, retention period, storage owner, restore contact, and any systems not covered.

If backups remain in MSP-controlled infrastructure for a transition period, write down the expiration date and retrieval process.

Remove tools in the right order

Agent removal is not a trophy hunt. Remove the wrong tool too early and you blind the transition team.

Use a sequenced plan:

1. Confirm the incoming provider has access and monitoring where needed.
2. Export inventory, alerts, configurations, and relevant ticket history.
3. Transfer or document EDR, MDM, backup, and remote access ownership.
4. Remove MSP-only accounts and shared secrets.
5. Uninstall RMM and remote support agents after the client approves timing.
6. Confirm no MSP-owned alerting, scripting, or scheduled tasks remain active.

If a tool cannot be removed yet, document why. Maybe the incoming provider needs two weeks to deploy replacement monitoring. Fine. That is an exception, not a mystery.

This is where client roadmaps can help. A roadmap should already show managed systems, upcoming renewals, known risks, and planned work. Offboarding should not require an archaeological dig through old tickets.

Keep the handoff meeting calm

The handoff meeting has one job: reduce operational risk.

Use this agenda:

1. Confirm cutover date and support window.
2. Review admin ownership for identity, domains, DNS, firewall, backup, and key apps.
3. Walk through open incidents, unresolved projects, and known risks.
4. Confirm tool removal timing.
5. Review billing and license ownership.
6. List missing items and who owns each one.
7. Confirm acceptance format and deadline.

Do not editorialize. Do not explain every client mistake. Do not turn the call into a courtroom. If a risk exists, state it plainly and attach evidence.

Bad: "They never listened to us about backups."

Better: "Server backup retention is seven days. No restore test is on record in the last quarter. Client accepts this risk or asks the incoming provider to test restore before agent removal."

That is not softer. It is stronger because it is usable.

Copy/paste acceptance record

Use this at the end of the process.

MSP Client Offboarding Acceptance Record

Client:
Outgoing MSP:
Incoming provider or internal IT owner:
Technical cutover date:
Contract termination date:
Acceptance signer:
Acceptance date:

Delivered items:
- Admin ownership transferred for:
- Documentation delivered:
- Password vault or credential transfer completed:
- Backup ownership and restore process documented:
- Vendor and license ownership documented:
- RMM, EDR, MDM, backup, and remote access tools removed or scheduled:

Known exceptions:
- Item:
  Owner:
  Risk:
  Due date:

Remaining financial items:
- Final invoice:
- Prepaid services or credits:
- License transfer or cancellation notes:

Client acceptance:
I confirm receipt of the offboarding package listed above, including the documented exceptions and remaining items.

Name:
Title:
Date:

Store the acceptance record in the client file, PSA ticket, and whatever system your agreement names as the official record. If the client refuses to sign, store the refusal and the delivered package anyway.

Where Scopable fits

Offboarding should not start when the client fires you.

The cleanest MSPs already know which systems they manage, which findings are open, which risks were accepted, which vendors are client-owned, and which roadmap items were deferred. That information should be visible before the relationship is under stress.

That is the same discipline behind better assessments, roadmaps, QBRs, quotes, and project handoff. Exits are not fun. Ambiguity is just expensive.

If you are trying to turn client assessments and roadmaps into cleaner commercial records, join Scopable early access.

FAQ

What should an MSP give a client during offboarding?

Give the client admin ownership, current documentation, credential transfer, backup ownership details, vendor contacts, license notes, open risks, final billing status, and a signed acceptance record. Do not rely on a generic password export alone.

Should an MSP remove RMM before or after handoff?

Usually after access transfer and documentation export, not before. The incoming provider needs time to deploy replacement monitoring. Document the removal date, client approval, and any agents left in place temporarily.

Who owns backups after an MSP contract ends?

The contract should say. If it does not, write it into the offboarding record before termination. The client needs to know where backups live, who pays for storage, who can perform restores, and when retention expires.

What is the biggest MSP offboarding mistake?

Leaving access behind. Old delegated admin rights, shared passwords, remote support tools, VPN accounts, and backup consoles are a liability after the relationship ends. Remove them deliberately and keep proof.