Offboarding is a reputation asset, not a cost to minimize
Most MSPs treat an exit as sunk cost. The revenue is gone, the relationship is over, and the transition work gets whatever attention is left after billable work. That reading is wrong, and it is wrong for a specific reason: the exit is the part of the relationship with the widest audience.
Three parties watch how you conduct a handover. The client, who will describe it to every peer who asks how the switch went. The incoming provider, who is a peer in the same local market and will remember whether you were professional or obstructive. And the client’s own staff, who will land at other companies over the next five years and carry the impression with them. None of those parties see your renewal rate. All of them see whether you handed over the firewall password without a fight.
Be honest about the size of the claim: this is a plausible source of referrals, not a channel you can attribute. Nobody can show you a dashboard proving a clean exit produced revenue. What is observable is the reverse. MSPs that stall on credentials, surprise clients with an offboarding fee, or delete backups on the notice date generate stories that circulate in peer groups and local business associations for years. The asymmetry is the argument: the upside is a maybe, and the downside is durable.
Clients leave for scope, not always for failure
Plenty of exits are acquisitions, an internal hire, or a move to a provider with a compliance certification you do not hold. Those clients have no complaint about you and will answer a reference call honestly if you leave them able to.
Some of them come back
The in-house IT hire leaves. The new provider is cheaper and slower. A return is only possible if the exit did not end the relationship personally.
The incoming provider is a future referrer
MSPs refer work they cannot take: wrong vertical, wrong size, wrong stack, geography. The provider taking your client over is deciding right now whether you are someone they would pass work to.
Documentation protects you either way
A written handover record with dates and sign-offs is the answer if a dispute arrives six months later about what was transferred and when. That value does not depend on referrals at all.
Publish the timeline in the first week
Most managed services agreements carry a 30 to 60 day notice period, which is also roughly how long a real transition takes. The failure mode is not running out of time. It is that nobody writes the sequence down, so the tenant transfer waits on a credential inventory that nobody started, and the last week turns into a scramble with the client watching.
Send a written offboarding plan within five business days of receiving notice. Name one owner on your side. Copy the incoming provider directly, so the two engineers can talk without routing every question through the client’s office manager.
| Window | What happens | Who owns it |
|---|---|---|
| Days 1 to 5 | Acknowledge notice in writing, confirm the contract end date, name the transition owner, publish the plan, introduce the incoming provider's engineer | Account owner |
| Days 5 to 15 | Credential and admin access inventory, documentation export, asset and license inventory, flag anything licensed on your paper | Lead technician plus account owner |
| Days 10 to 25 | Backup set delivered, test restore witnessed by the incoming provider, tenant and CSP subscription transfers scheduled around billing dates | Lead technician |
| Days 20 to 30 | Incoming provider deploys their agents, then you remove yours, then you remove your own admin and delegated access | Lead technician |
| Final week | Final invoice, prepaid balance settled, recurring billing cancelled, client property returned, monitoring removed from your NOC | Account owner plus finance |
| 1 to 2 weeks after | Exit interview, backup deletion confirmation in writing, internal review of when the account actually started drifting | Account owner |
Send a short status note weekly against that plan, even in the weeks where nothing moved. Silence during an exit reads as stalling, and a client who thinks you are stalling starts copying their lawyer on emails.
Phase 1: credential and documentation handover
This is the phase that makes or breaks your reputation, because it is the phase where an MSP can quietly hold a client hostage. Do the inventory first and hand it over as one package rather than answering credential requests one at a time for three weeks.
Microsoft 365 or Google Workspace: transfer global admin or super admin to a client-owned account, and confirm the client controls at least one break-glass account before you touch anything else
Partner relationships: end GDAP relationships, delegated admin privileges, and partner-of-record designations, and note the date each one ended
Domain registrar and DNS: registrar login, registrant contact updated to the client, DNS host access, and a current export of the zone file
Network gear: firewall, switch, wireless controller, and VPN concentrator admin accounts, plus current configuration backups
Servers and hypervisors: local and domain admin accounts, hypervisor management, SAN or NAS management, out-of-band controllers such as iDRAC or iLO
Line-of-business applications: admin accounts for ERP, practice management, accounting, and anything else you administer on the client's behalf
Vendor and carrier portals: ISP, VoIP, backup vendor, licensing portals, hardware support contracts, and any account where you are the named contact
Certificates and secrets: SSL certificate ownership, API keys and service accounts you created, and a list of anything scheduled to expire in the next twelve months
Documentation export: network diagrams, runbooks, asset inventory, vendor contacts, and renewal dates, exported from IT Glue, Hudu, or Confluence into a format the client can read without your license
Your own access: remove break-glass and technician accounts last, after the client and incoming provider confirm they hold everything, and send written confirmation of the removal date
Hand credentials over through a method the client already uses, and require the receiving person to confirm each system by name. A signed inventory listing every system, who received it, and on what date is the single most useful artifact from an offboarding for both sides.
Phase 2: backup delivery and verification
Backups are where an offboarding turns into a legal problem fastest. The client’s data is the client’s data, and a backup that only restores inside your tooling is not a handover. Verify, do not assert.
Read the retention and deletion clauses in the agreement before you start, and tell the client what they say rather than letting them find out later
Deliver the most recent full backup set in a format the incoming provider can restore without a license from your backup vendor
Include the retention history the contract requires, not only the newest full set
Run at least one test restore with the incoming engineer watching: a file-level restore, a mailbox, and a full VM if the environment has one
Deliver a copy of any long-term archive covered by a compliance obligation, and identify which regulation it falls under
Record chain of custody: what was delivered, on what media or through what transfer, on what date, and who received it
Agree in writing on the date your copies are deleted, then send confirmation when the deletion actually happens
Keep your backups running until the incoming provider's backups have completed a successful cycle, not until the contract end date
That last item costs you a few weeks of storage and removes the worst outcome in the whole process, which is a client with no usable backup during the window between two providers.
Phase 3: license and subscription transfer
Licensing is where transitions slip, because the deadlines belong to vendors rather than to either provider. Sort licenses into three buckets in the first two weeks and tell the client which is which in plain language.
| Bucket | Typical examples | What has to happen |
|---|---|---|
| Transfers to the new provider | Microsoft CSP subscriptions, some cloud backup seats, hosted voice | Schedule the move before the term rolls over, since a renewal mid-transition locks the subscription for another term |
| Stays with the client | Perpetual licenses bought in the client's name, domain registrations, SSL certificates, hardware support contracts | Update the registrant, billing, and technical contacts away from your team, then confirm renewal dates in the handover pack |
| Ends at the contract | RMM agents, EDR and antivirus seats, remote access, monitoring, and PSA-linked tooling bought on your agreement | Say so in week one so the incoming provider can license replacements before your seats stop |
Write the renewal date next to every line. A client who loses email because a CSP subscription lapsed in the handover gap will blame the outgoing provider regardless of who was formally responsible that week.
Phase 4: agent and tooling removal
Sequence is the whole point here. The incoming provider deploys first, you remove second. Uninstalling your EDR before theirs is running leaves the client unprotected during exactly the window when two teams are changing credentials on everything.
Incoming provider deploys their RMM, endpoint security, and backup agents and confirms check-in counts
You remove your RMM agent, endpoint security, backup agent, remote access tools, and monitoring probes
You remove scheduled tasks, scripts, and patch policies your RMM pushed, including anything that survives the agent uninstall
You remove your monitoring targets, network probes, and alerting rules so nothing pages your NOC after the end date
You remove technician VPN accounts, jump host access, firewall rules that exist only for your tooling, and any site-to-site tunnel to your infrastructure
You reconcile against the asset inventory by count, and chase the endpoints that were offline during the removal push
You archive the client's ticket and documentation history per your retention policy, then remove the account from active monitoring and billing
Never remotely wipe, lock, or disable a device during an exit, and never let a script do it on a schedule. Whatever the provocation, that action converts a contract ending into a legal event, and it is the story that follows an MSP around a market.
Phase 5: final invoicing and financial close
Money is the last impression. A final invoice with a line the client did not expect erases whatever goodwill the previous four phases earned, and it is the detail people repeat.
Issue the final invoice covering the prorated managed services period through the contract end date
Bill project work in flight against its original scope, and write off anything you cannot show evidence for
Settle prepaid blocks, retainer credits, and unused hours, refunding rather than expiring them where the contract allows
Cancel recurring billing, auto-charges, and any standing payment authorization on the same day the contract ends
Pass through hardware, license, and vendor charges with the underlying invoice attached
Charge a transition fee only if it was in the signed agreement, and itemize what it covers
Return client property: spare hardware, licenses held in your name, keys, badges, and physical documentation
Confirm in writing that the account is closed with no further charges pending
Phase 6: the exit interview
Run it after the handover finishes, not during. A client will not tell you anything useful while they still need something from you. Twenty minutes, the account owner rather than a salesperson, no attempt to save the account.
What triggered the decision, and roughly when did it start
What would have changed the outcome, if anything would have
Which parts of the service worked, and who on the team did well
Where did response or communication feel slow, with an example
Was there a moment you expected us to raise something and we did not
How did the handover itself go, including anything the incoming provider flagged
May we check in in twelve months
Would you refer us for work outside the scope you just moved
Then run the internal version separately. Look back through the account history and find the month the relationship actually started drifting, which is almost never the month notice arrived. Missed QBRs, a slipped project, a change of contact on their side that nobody registered. That is the pattern worth catching on the accounts you still have, and the account rhythm covered in our MSP client management guide is what surfaces it earlier.
What the client should see while this runs
Nearly every offboarding guide is written for the MSP’s internal use, which is why so many exits feel opaque from the client side. The client is coordinating two providers at once and has no view of either queue. Giving them a live view of the transition removes most of the chasing.
The phases and where you are in them
Six phases with completion state. This answers the question the client is actually asking, which is whether the transition finishes before the contract does.
What is waiting on them
Signing the credential receipt, naming who receives global admin, approving the backup deletion date. Named person, due date, visible to both sides.
What is waiting on the incoming provider
Agent deployment, restore witnessing, CSP acceptance. Making this visible stops the client assuming every delay is yours.
The handover documents in one place
Credential inventory, network diagrams, asset list, license register, and the backup chain of custody, in one location instead of scattered across a month of email threads.
A client who can see the transition progressing does not need a weekly reassurance call, and the record it leaves behind is the same record that protects you if a question comes up later. For what a client-facing view should contain generally, see our guide to client portals.
If you are the client leaving your MSP
A good share of the people searching for this are not MSPs buying software. They are business owners who just gave notice and want to know what to ask for. Here is the short version, with no product attached.
Read the transition, retention, and deletion clauses in your agreement before you give notice, not after
Ask for a written credential and admin access inventory with a handover date, and confirm you hold a break-glass admin account in your own tenant
Ask for a restorable backup set plus a test restore your incoming provider watches, and get the deletion date in writing
Ask which licenses are on your paper, which move with the new provider, and which stop at the contract, so nothing lapses in the gap
Ask that agent removal happens after your new provider is deployed, not before
Ask for a final invoice, settlement of any prepaid balance, and confirmation that recurring billing is cancelled
Keep your outgoing provider's access live until the incoming provider has tenant access, because a dark account during a transition is worse than a few extra days of overlap
If your outgoing provider volunteers most of that before you ask for it, that is worth remembering. They are the kind of firm worth recommending to someone whose needs they do fit.
Where Pathalize fits, and where it does not
Pathalize covers two parts of what is on this page: the checklist as a reusable template your team runs the same way every time, and the client-facing view of the handover. It does not touch the rest, and pretending otherwise would waste your evaluation time.
| Part of the offboarding | What runs it |
|---|---|
| The checklist itself, with owners and dates | Pathalize. Save the six phases as a template, generate a fresh copy per departing client, and track completion across every account in one dashboard. |
| What the client sees during the transition | Pathalize. A branded per-client portal showing phase status, the tasks waiting on them, and the handover documents. Client seats do not consume your paid seats. |
| Storing and rotating the credentials | Your password manager or PAM tool. Pathalize is not a credential vault and should not hold client secrets. |
| Removing RMM, EDR, and backup agents | Your RMM. Pathalize tracks that the removal task is done and by whom, and does nothing to the endpoints. |
| License and subscription transfers | The vendor portals, including Microsoft Partner Center. Pathalize holds the register and the deadlines, not the entitlements. |
| Final invoicing and prepaid settlement | Your PSA and accounting system. Pathalize does not invoice, meter time, or take payments. |
| Monitoring and alerting during the gap | Your RMM and monitoring stack. Pathalize is not an RMM and does not watch devices. |
The short version: it is the project layer and the client-facing surface, sitting next to the PSA and RMM you already run. See Pathalize for MSPs for how the same templates cover onboarding and recurring service work.