Nobody enjoys offboarding a client, so it tends to be rushed. The notice arrives, the account manager is disappointed, and the work is handed to whichever engineer is free. That is when things go wrong: a global admin password that only your team knew, a domain registered in your name, an EDR agent removed a week before the new provider’s arrived, or a delegated admin relationship still open months after the contract ended. Each one is a security risk for the client and a liability for you. This free MSP client offboarding checklist gives service managers and account managers a professional exit for every client. It covers the notice and termination terms, a written transition plan, documentation and credential handover, transfer of admin roles and domains, licences and the final invoice, removing your tools without leaving devices unprotected, ending GDAP relationships, written confirmation of access removal and archiving under your retention rules. A conditional phase adds joint handover tasks when an incoming provider is taking over.
Offboarding is onboarding in reverse, with less goodwill and a fixed deadline. Our MSP Client Onboarding Checklist includes a phase for taking over from an outgoing provider: requesting the handover pack, confirming the client owns its tenant and registrar, and revoking the old provider’s access. This checklist is the other side of that phase. Run it well and the incoming MSP’s onboarding is quick, the client’s staff notice nothing, and the client remembers you as the provider who left properly.
There is a selfish reason to do it carefully, too. Until access is removed, you are still able to reach the client’s systems, and if something goes wrong in that period the first question will be whether it was you. A written list of every access route, closed on an agreed date and confirmed to the client in writing, is what answers that question. It also means you stop paying for licences, agents and backup storage for a client who no longer pays you.
Credentials: a spreadsheet sent to whoever asked.
Tooling: uninstalled on the last day, ready or not.
Access: partner relationships and accounts left to expire.
Risk: an unprotected network and an open door with your name on it.
Credentials: handed over through a secure channel, receipt confirmed.
Tooling: removed only once replacement cover is confirmed.
Access: every route listed, closed and signed off.
Risk: none left behind, and a letter that proves it.
Seven phases take a departing client from notice to archive. Phase 3 appears only when another provider is taking over.
List everything before anything is removed. The plan is what the access-removal letter is checked against at the end.
Shown only when an incoming provider is taking over. The client stays in charge of what is shared and when.
Credentials never go by email or spreadsheet. Use a secure share and get receipt confirmed.
Remove protection only when the client or the incoming provider confirms cover is in place.
Most MSPs can name their RMM agent and their admin accounts. The routes that get missed are the ones created once, years ago, by an integration or a vendor portal. Build this list during the transition plan, not on the last day, and use it to check the access-removal letter before it is sent.
| Access route | How it ends | Evidence to keep |
|---|---|---|
| GDAP relationships | Terminated by you in Partner Center, or by the client under Partner relationships in the Microsoft 365 admin center | Termination notification and date |
| Reseller relationship | Removed in Partner Center once no subscriptions are active | Screenshot or audit log entry |
| Named admin and service accounts | Deleted or disabled in the tenant, firewall and each vendor console | List of accounts removed |
| Enterprise applications | Deleted from Microsoft Entra ID, which revokes the consent your tools were given | Application names and dates |
| RMM and remote access agents | Uninstalled and removed from your console, with the device list reconciled | Device count before and after |
| EDR and backup | Uninstalled after replacement cover is confirmed, then the client removed from your console | Client or new provider’s confirmation |
| VPN, firewall and Wi-Fi | Your accounts and certificates removed, shared secrets changed by the client | Change confirmation |
| Registrar and DNS | Domains and DNS hosting moved to an account the client controls | Transfer confirmation |
Notice, plan, handover, tool removal and sign-off follow the same sequence whoever handles the client. Conditional logic adds the joint handover tasks only when a new provider is taking over, so the same template covers every kind of exit.
The confirmation of access removal goes to the client only after the service manager has checked every route on the plan and answered Approved. The approval, the dates and the evidence attached to each task are kept against the client.
If a former client later suffers an incident, the completed checklist shows when each account, relationship and agent was removed, who did it and what the client confirmed receiving. That record is worth more than any memory of a hurried last week.
Offboarding is one of the processes most MSPs never write down until a messy exit forces it. The MSP process management guide covers the full client lifecycle, and CheckFlow for MSPs runs it across every client from one place.
The other end of a handover is the incoming provider’s takeover. The MSP Client Onboarding Checklist covers it, and the final invoice follows the same checks as the monthly MSP Billing Reconciliation Checklist.
It is the process a managed services provider follows when a client leaves. It covers the termination terms, a transition plan, handing over documentation and credentials, transferring admin roles and domains to the client, settling licences and the final invoice, removing the MSP’s tools and access without leaving devices unprotected, and confirming in writing that every access route has been closed.
Check the agreement first, because some contracts say exactly what is returned at exit. In practice, information about the client’s own systems, such as credentials, network diagrams, configurations and asset lists, should go to the client. Your internal procedures and templates usually remain yours. Refusing to hand over the client’s own information rarely protects you and often ends up in a dispute you lose.
Terminate it in Partner Center, or ask the client to remove your roles in the Microsoft 365 admin center under Settings and Partner relationships. Either way, your security groups lose access to that customer. Don’t rely on expiry: relationships can last up to two years and some auto-extend. Ending GDAP doesn’t remove the reseller relationship, which is a separate step once no subscriptions remain.
New commerce subscriptions can be transferred to the incoming CSP partner mid-term. The new partner sends a transfer request, you select and submit the subscriptions, and billing responsibility moves from the transfer date. If the client is buying elsewhere or directly, subscriptions you can’t cancel run until their term ends, so agree in writing who pays for that remaining commitment.
No, unless the client tells you to in writing. Removing EDR or backup before replacement cover is confirmed leaves the client unprotected, and a ransomware incident in that gap will be blamed on whoever left it. Agree a cutover sequence: the new tools go in and are confirmed, then yours come out. If the client delays, record it and confirm your exit date.
Only as long as your agreement and the law allow. Under UK and EU GDPR, a processor must delete or return personal data at the end of the service, at the controller’s choice, unless law requires it to be kept. Return or delete backups and client data as agreed, and keep your own business records, such as invoices and tickets, for your stated retention period.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
