Client Offboarding Checklist for MSPs and IT Teams

Updated: November 2026

Client offboarding is the structured process of ending a service relationship: revoking access, handing back data and credentials, returning or reassigning equipment, and closing out documentation without leaving a security hole behind. For an MSP, a departing client means a tenant inside your RMM, a stack of admin credentials, backups and access tokens to unwind in the right order, and for an in-house IT team changing providers, it means getting every one of those keys back. This client offboarding checklist walks both sides of the exit, phase by phase, so nothing slips.

TL;DR

• The short answer. Offboarding runs five phases: lock the timeline, revoke access in sequence, hand over data and documentation, pull agents and reconcile licenses, then verify and retain records.
• Sequence matters. Kill live sessions, VPN and admin roles first, because API tokens keep working after an account is disabled.
• Gate the handoff. Settle final billing before full data handover, and retain records three to seven years.
• IT teams changing providers. Confirm you own the tenant, a working global admin account, the domain and the backups before the outgoing MSP's access ends.

What Does Client Offboarding Mean For An MSP?

Client offboarding is the process an MSP runs when a client leaves: transferring what belongs to them, revoking what belongs to you, and documenting the whole exit. It's the mirror image of onboarding. Where onboarding grants access, provisions agents, and builds the runbook, offboarding reverses each step in a controlled order. A good onboarding and offboarding checklist treats them as two halves of the same lifecycle, not two unrelated events.

This is different from an employee offboarding checklist or an HR offboarding checklist for managers, which deprovision one departing worker inside a single company. It's closer to a vendor offboarding checklist run from the provider's side. The stakes are wider, too. You hold administrative control over another company's entire IT estate, so a sloppy exit leaves a security gap in someone else's business. CyberSheath's MSP offboarding guide warns that severing ties too early can leave the client stranded and paying to recover data, admin credentials, and backups.

The fix for high-stakes work is repeatability. Build one offboarding process checklist and run it identically every time, whether you're releasing a 200-seat client or a single contractor account you managed as a favor. A reusable IT offboarding checklist template removes the improvisation that causes missed steps under deadline pressure, and it gives a junior tech a clear runbook instead of a guessing game. The same document doubles as proof, later, that the exit followed a defined process.

Client Offboarding vs Employee Offboarding

Employee offboarding runs inside one company and starts with HR, so it follows its own process. The table shows where the two overlap and where they split, which matters for IT teams that run both.

Offboarding Your MSP From the Client Side

If you're the in-house IT lead replacing an MSP, run the same checklist from the other side of the table. Before the outgoing provider's access ends, confirm your company owns the Microsoft 365 or Google Workspace tenant, holds a working global admin account, controls the domain registrar and DNS, and can sign in to the backup platform. CyberSheath notes that an incoming MSP has no authority to make the outgoing one hand over information, so list the handover items in the release letter and ask the departing MSP to sign it.

Ask for the same package this checklist tells an MSP to deliver: the credential inventory, network diagrams, vendor contacts, the latest full backup, and the list of agents to remove. Once the new provider is live, remove the old provider's accounts, delegated admin roles, and remote tools on your own schedule.

Vendor Offboarding Checklist

The same logic applies when your company drops any vendor, from a SaaS tool to a contractor. Work through these steps before the contract lapses:

Forgotten integrations and unused seats are where shadow IT starts, so log each vendor's exit in the same place you track approved apps.

The Client Offboarding Process At A Glance

Here's the full client offboarding process in one view. Copy it into your PSA as a project template, or save it as an offboarding checklist PDF your team works top to bottom. Owners are a starting point; adjust them to your roles.

The table also works as one half of an IT onboarding and offboarding checklist pair. Build it next to your MSP onboarding checklist so every access grant, agent, and license you add on day one has a matching removal step on the way out. In Excel or Word, add a column for the date each task closed so the sheet doubles as your audit trail.

The Account Manager's Offboarding Checklist

Technicians own the access and asset rows. The account manager owns the calendar, the paperwork, and the relationship, so if you manage the account, this is your slice of the table:

• Confirm the contract end date, the notice period, and any terms that survive termination.
• Send the written offboarding plan and get the client's sign-off on the dates.
• Tell your own team the account is winding down: no renewals, new projects, or fresh access.
• Name one contact at the incoming provider for the technical handover.
• Issue the final invoice and confirm payment before the full data handoff.
• Collect both signatures on the completion record and run the exit interview.

Now the detail behind each phase.

Phase 1: Lock The Timeline And Honor The Contract

The exit starts with a date and a document. Confirm the contract end date, the notice period, and any obligations that survive termination, then put the plan in writing. An offboarding client communication template keeps this clean: end dates for every active service, who does what, and when access ends. Vague timing is where handovers go wrong, so name the day. Exit terms are easiest to settle before signing, which is why they belong on any list of MSP contract questions.

Support does not stop the moment notice lands. You honor the SLA through the contract end date. Techs still answer tickets, backups still run, and monitoring stays live until the agreed cutover. MSP360 puts this first in its client offboarding guidance: provide support until the end of the contract, because your contractual obligations run to the last day.

Money comes before data. Invoice the final billing cycle, settle any outstanding balance, and make full payment a precondition of the complete data handoff. This is standard practice, and stating it plainly in the offboarding plan avoids an awkward conversation later. You can hand over what the client needs to keep operating while the final invoice clears, then release the full archive on payment.

Line up the right people early, on both sides. Name a single point of contact at the incoming provider so the technical handover has one channel, not five. Internally, tell your own team the account is winding down so nobody renews a license, opens a new project, or provisions fresh access mid-exit. A short offboarding client communication template, one email to the client and one internal notice, keeps everyone reading from the same schedule.

For a one-person shop, the exit can mean releasing a client you've run end to end. In the r/msp thread below, a solo provider taking a full-time role asked how to let their last client go, and one reply suggests a 30 to 60 day handover plan with a named MSP and a packet covering tenant admin roles, licensing ownership, and the device inventory.

How Should You Sequence Access Revocation?

Revoke access in a deliberate order, fastest and most dangerous paths first. The sequence, not just the action, is what closes the security window. An offboarding security checklist that yanks everything at random still leaves gaps, because some credentials survive the obvious kill switch.

Start with the live paths. Terminate active sign-in sessions, disable single sign-on, pull MFA registrations, and cut VPN and remote-access certificates. Remote pathways are the ones an attacker reaches first, so they go first. Then strip admin roles and privileged group memberships across every tenant, directory, and management console you touch. For Microsoft 365 clients, that includes ending your GDAP relationship so your technicians lose their delegated admin roles in the tenant.

In Microsoft Entra ID, clear Account enabled on each account, then select Revoke sessions on its overview page, as Microsoft's revocation steps lay out. Revoking sessions invalidates refresh tokens, but an access token Entra already issued can keep working until it expires, one hour by default, so allow for that window at cutover.

Here's the trap. Disabling a user account does not revoke API tokens, access keys, and OAuth grants. Those are machine credentials that authenticate on their own, independent of any login session, and they keep working until you revoke them explicitly. The same goes for service accounts, shared secrets, and app passwords. Walk the list and kill each one by hand. A user offboarding checklist that stops at "disable the account" is the reason orphaned integrations still phone home months after a client leaves.

Document each revocation as you go, with a timestamp. That log becomes the evidence package in Phase 5 and the proof you need if anyone ever questions when access ended.

Handing Over Credentials, Backups, And Documentation

Everything the client needs to run their environment without you goes back to them, organized and complete. This is the heart of any IT offboarding checklist.

Start with the credential and access inventory. Hand over administrative credentials for every in-scope device: servers, workstations, routers, firewalls, switches, storage, and the applications that sit on top. Include domain registrations and DNS, firewall rules and configs, wireless keys, and the vendor contacts and account numbers for every third-party service you managed on their behalf. Network diagrams and IP schemas go in the same package. If you built and maintained this in a documentation platform, a clean export beats a scramble across tabs, which is one reason strong IT documentation for MSPs pays off most on the way out the door.

Backups are their own workstream. Provide the backup schedule, the location where backup data lives, the credentials to retrieve it, the application used to run and restore it, and the most recent full backup itself. A client who inherits a backup job they can't authenticate into has no backup at all. Confirm the incoming provider can read the format before you consider this step done.

Set data retention expectations in writing. Tell the client exactly what you will keep, in what form, and for how long, and what you will delete. That statement protects both sides and feeds directly into the compliance phase below. For data you hold on your own storage, MSP360 suggests sending a 30-day notice and deleting it only after that window closes.

What About Removing Your RMM And PSA Agents?

Your agents are your access, so pulling them is part of revoking access, not a cleanup chore. Once the new provider is ready and the handover is confirmed, remove your RMM agent, your remote-access tools, your EDR or antivirus, your monitoring probes, and your PSA integrations from every endpoint. Leftover agents are a live security exposure: they hold privileged access, they can push scripts, and they keep pumping a departed client's data into your dashboards.

Do it in coordination, not a race. Ripping monitoring and security tools before the incoming MSP has theirs in place leaves the client unprotected in the gap, which is its own liability. Agree on a cutover window, confirm the new provider's coverage is live, then remove yours and verify each endpoint reports clean. Reconcile the removal against your asset inventory so no device gets missed, because the one machine you forget is the one still calling home in six months.

This is also where a consolidated stack earns its keep. When RMM, PSA, and documentation live in one system, offboarding is a single-source pull instead of a hunt across eight tools with eight separate agent lists. OpenFrame is open, AI-native infrastructure for IT and security that puts RMM, PSA, MDM, and documentation in one console, with the AI agents Fae and Mingo working inline, at $1 per device per month including 10M AI tokens, with a 14-day free trial. Disclosure: OpenFrame is built by Flamingo.

Equipment And License Return

Hardware and licenses both cost money, and both get forgotten in the rush. Walk the asset list and settle every item. Loaner laptops, spare firewalls, cellular failover units, and any hardware you own on the client's premises come back or get formally transferred. Log the serials and the condition on return.

Software licenses are the quieter line item. Any seats you provisioned under your own agreements, Microsoft 365 through your CSP, security tooling, backup capacity, need to be reassigned to another client or cancelled so you stop paying for a customer who left. Licenses the client owns directly get transferred into their name and tenant. A current IT inventory makes this a checklist item instead of a discovery project, since you already know exactly what's deployed and who's paying for it. Reconcile at the end so nothing keeps billing against a closed account.

Device Collection and Wipe

Device collection starts with ownership. Devices the client owns stay with the client, either handed over in the client's own management or released from yours. Hardware you own comes back, gets logged by serial number and condition, and is wiped before reuse, the same disposal path as any device in your IT asset lifecycle.

In Intune, Retire removes managed data and settings but keeps user content, and it runs the next time the device checks in, while Wipe resets the device to factory settings. Before you retire or delete a Microsoft Entra joined device protected by BitLocker, back up its recovery key, because Intune removes the key protectors and suspends BitLocker on the OS volume, per Microsoft's retire guidance. Remove the Windows Autopilot registration too, so the client's new provider can register the device in its own tenant.

Moving Microsoft 365 Licenses to the New Partner

If you resell Microsoft 365 through the CSP program, the client's subscriptions can move to the incoming partner through a Partner Center transfer. The new partner creates the request, you approve and submit it, and transfers take up to 72 hours to complete, per Microsoft's transfer guide. A request nobody acts on expires after 30 days, so agree on the date with the incoming provider before the old contract ends.

How Long Should You Keep Offboarding Records?

Keep the offboarding record long enough to satisfy audits and disputes, which usually means years, not months. This is the offboarding compliance checklist, and it's the part an auditor cares about most.

SOC 2 doesn't prescribe a retention period, so three years is a workable default that spans several annual audit periods. Regulated clients need longer: HIPAA requires covered entities and business associates to keep required security documentation for six years from creation or the date it was last in effect, under 45 CFR 164.316, which is why the chart below sets seven years for finance and healthcare clients. Any client under an active legal or litigation hold sits outside the normal schedule; hold everything until counsel releases it. When retention lapses, dispose of the data on a defined schedule rather than letting it linger in a forgotten folder, since data you no longer need is only risk.

What goes in the archive: the signed offboarding plan, the access-revocation log with timestamps, the data-handoff confirmation, the asset and license reconciliation, and the sign-off from both sides. Store it where it survives staff turnover and stays retrievable for the full window. That package is your proof the exit was clean.

How Do You Verify The Exit Is Really Done?

Verification is a separate step, not an assumption. When the tasks are checked off, prove it. Run a residual-access sweep: search every directory, console, and third-party platform for lingering accounts, tokens, sessions, or agents tied to the client, and confirm each is gone. The revocation log from Phase 2 is your checklist here, one line closed against each entry.

Bundle the results into an evidence package: what access existed, when it was revoked, who confirmed it, and the final residual-access scan showing clean. That chain-of-custody record is the difference between saying the client was offboarded and proving it. If a former client's environment is breached after you leave, that package is what shows the door was locked behind you.

One easy miss lives outside your own walls: shared and third-party systems. Password vault entries, shared inboxes, RMM and PSA seats you granted, and any integration where the client's identity federated into a vendor platform all need a second sweep. These sit beyond the primary directory, so a revocation pass focused only on your core tenant leaves them live. Check each one against the access inventory you exported in Phase 2 and close the loop.

Close with the exit interview. Ask why the client left, what worked, and what didn't, then document the answer. It's the cheapest market research you'll get, and the feedback often exposes a fixable gap that's costing you other accounts. A departing client has no reason to spare your feelings, so listen. File the notes with the archive and the offboarding is complete.

Run this client offboarding process the same disciplined way every time and the exit stops being a scramble. It becomes a clean, repeatable handover that protects your client, your compliance posture, and your reputation, which is the one thing a departing client carries straight to the next MSP owner they talk to.