Operations

MSP client offboarding checklist: how to lose a client well

Every MSP has an onboarding process. Far fewer have an offboarding one, because nobody enjoys planning for the day a client leaves. But clients do leave: they get acquired, they take IT in-house, they chase a cheaper contract. An MSP client offboarding checklist is what separates a professional exit that earns referrals from a messy one that ends in disputed invoices and awkward security questions. Here is ours, item by item, with what each step is actually protecting you from.

What an MSP client offboarding checklist has to cover

Offboarding is three things at once: a security event, because your access to someone else's estate is ending; a legal event, because contracts, data protection and licence ownership all come due; and a reputation event, because the way you leave is the story that client tells their peers for years. The onboarding checklist you run on day one deserves a mirror image at the end, and it splits naturally into four phases: agree the exit, hand over the estate, remove yourself, and close out cleanly.

Phase one: agree the exit in writing

1. Re-read the contract before you respond to notice. Your agreement almost certainly specifies a notice period, what offboarding assistance you owe, whether you can charge for it, and how long you must retain data. Check it before you promise anything. Skip this and you end up negotiating terms mid-transition, doing weeks of handover work for free, or holding data longer or shorter than you agreed to, and every one of those becomes a dispute at exactly the moment goodwill is lowest.

2. Fix a cutover date and name a contact on each side. A transition needs a single agreed end date, usually 30 to 60 days out, and one named technical contact at your firm, at the client, and at the incoming provider if there is one. Skip this and the offboarding drifts for months: you keep responding to tickets you are no longer paid for, nobody knows who owns an outage in week seven, and you carry liability without revenue.

Phase two: hand over the estate, not a spreadsheet

3. Export a complete asset inventory. The successor needs every device, server and network appliance you managed, with OS versions, warranty status, patch state and assigned users, as of the cutover date. Skip it and every unknown machine discovered over the next year gets blamed on you, fairly or not. A dated, complete export is your evidence of what good order you left things in.

4. Transfer documentation, credentials and ownership. Admin credentials for every in-scope system, network diagrams, the domain registrar login, DNS, Microsoft 365 admin roles, and any licences or vendor accounts registered in your name rather than the client's. Transfer ownership, not just passwords. Skipped, this is the classic horror story: eighteen months later the client's domain lapses or a certificate expires, the renewal notices are going to your billing inbox, and their website is down because of an account nobody remembered you owned.

Phase three: remove yourself completely

5. Uninstall your agents and revoke your access. RMM agents, remote access tools, your technicians' admin accounts, API keys, delegated admin relationships. All of it, on the cutover date, and keep a record of the removal. Skip it and you retain silent access to an estate you no longer manage, which means that if anything goes wrong there, ever, you are a suspect with no contract protecting you.

6. Check the places access hides. Break-glass accounts, your phone number on MFA resets, firewall rules allowing your network in, conditional access exclusions, backup consoles, and mail forwarding to your service desk. These outlive the obvious accounts because nobody documented them. Skipped, they surface in the client's next security audit as unexplained third-party access, and the finding has your company's name on it.

Phase four: close out data and the relationship

7. Return, then delete, client data on a schedule you can evidence. Hand over ticket history, backups and stored files, then delete your copies once the agreed retention period ends, while holding anything a regulator or the contract obliges you to keep. Skip the deletion and you are a data protection liability holding personal data with no lawful basis; delete too eagerly and you may destroy something the client was legally required to retain.

8. Write a final handover summary and get sign-off. One document: what was transferred, what was removed, what was deleted and when, and anything still outstanding. Ask the client to sign it. Skipped, you have no proof the exit was clean if questions come later, and you lose the closing conversation, which is where a well-run exit turns into a future referral. Clients who leave well come back, and they talk.

Where this fits with Helios

Most of this checklist is discipline, not tooling, but the tooling decides how painful it is. Because Helios keeps a live per-client inventory of devices, patch state, protection status and tickets, the handover exports in phase two are a few clicks rather than a week of archaeology, ticket history can be pulled through the API, and removing a client is a clean, logged operation rather than a hunt through every endpoint. The same records that power a good QBR are the ones that make a good exit.