Service transition · 15 minute read

MSP client offboarding checklist

End a managed-service relationship without leaving orphaned agents, credentials, automations, data, or responsibility behind. This checklist keeps the transition recoverable until the client or successor has proven control.

Use the free template Read the full process Download CSV Download Markdown

Last reviewed November 1, 2026Tool-neutral · evidence-first

Copy-ready template

MSP client offboarding checklist: ten accountable handoffs

Assign an owner, due date, status, evidence link, and exception owner to every line. The downloadable CSV is ready for a PSA or project board; the Markdown version includes the full operating checks and closeout tests.

1Confirm authority, scope, owners, support boundaries, and the effective exit date.
2Export the authorized asset, service, incident, policy, backup, and risk baseline.
3Inventory every technician identity, session, credential, token, integration, and trust path.
4Transfer registrant, billing, recovery, notification, and administrative ownership before revocation.
5Revoke people and sessions, rotate shared credentials, and test former access paths.
6Stop or transfer scheduled jobs, scripts, patching, reboots, alerts, reports, and backup work.
7Assign one receiving management authority for each service and test representative workflows.
8Remove RMM and remote-access components in waves, including helpers and unattended access.
9Classify client data for return, justified retention, deletion, or an approved exception.
10Reconcile every asset and exception, record risk owners, and obtain closeout acceptance.

Detailed evidence register

Track the exit across 32 accountable controls.

The public, vendor-neutral register expands this ten-step guide into control-level rows for authority, inventory, secure transfer, access revocation, agent removal, data disposition, acceptance, exceptions, and post-exit verification. Nizlo maintains the external resource; no account or email address is required.

Open the evidence register Download the 32-control CSV

Ten steps from notice to verified closeout

Adapt the sequence to the contract, client risk, and receiving provider. Keep a recovery path until the new owner has tested access and management on representative systems.

1. Confirm authority, scope, and the exit date

Start from the contract, current service inventory, and written client direction. An offboarding runbook should identify who can approve changes, when management authority transfers, what support continues during transition, and which emergency contacts remain valid.

Name the client sponsor, outgoing owner, incoming owner, effective date, support boundary, and escalation contacts.
List every in-scope tenant, site, device, service, domain, subscription, integration, and data store.
Record legal holds, retention duties, insurance requirements, and contract-specific return or deletion terms before changing data.

2. Freeze scope and preserve transition evidence

Create a time-stamped baseline before removing anything. Preserve the records needed to explain the managed state, transfer responsibility, resolve billing, and investigate a later question without retaining data beyond the agreed purpose.

Export the authorized asset list, service inventory, open incidents, change history, patch state, alert state, backup status, and unresolved risks.
Record active policies, monitors, scripts, schedules, exclusions, maintenance windows, and deployment rings.
Hash or otherwise identify important exports and store them in the approved transition location with a named custodian.

3. Inventory every identity and trust path

RMM access is only one part of the relationship. Reconcile technician accounts, guest identities, service principals, API keys, certificates, local administrators, VPNs, remote-support tools, delegated tenants, password vaults, and break-glass procedures.

Map each identity or credential to an owner, system, privilege, purpose, and revocation method.
Include shared accounts, unattended-access identities, device credentials, webhook secrets, and cached sessions.
Identify access granted through groups, federation, delegated administration, application consent, or upstream identity providers.

4. Transfer ownership before revoking access

Avoid creating an outage or an unmanaged security gap. Move registrant, billing, recovery, notification, encryption-key, and administrative ownership to the client or approved successor before the outgoing provider loses the ability to complete the transfer.

Verify the recipient can sign in, use MFA, receive recovery messages, and perform the required administrative action.
Transfer documentation, vendor contacts, renewal dates, license quantities, and support entitlements through an approved channel.
Do not send passwords or secrets in ordinary email; use an agreed secure handoff and record receipt without copying the secret into the ticket.

5. Revoke people, sessions, credentials, and integrations

Disable access in a controlled order after ownership is proven. Removing a visible account is not enough when active sessions, tokens, application grants, service credentials, or remote-access pathways remain valid.

Remove outgoing technicians and guests from client groups, roles, vaults, portals, VPNs, and delegated-administration relationships.
Revoke sessions and refresh tokens, then rotate shared, service, API, webhook, recovery, and local-administrator credentials.
Verify removed identities cannot authenticate through a direct URL, API, remote agent, cached session, or alternate tenant.

6. Stop automation without abandoning work in flight

Scheduled jobs can keep changing a client environment after the commercial relationship ends. Freeze new high-risk execution, reconcile queued and active work, and hand over any automation the client is authorized to retain.

Inventory patch jobs, scripts, remediations, software deployments, reboots, reports, alerts, ticket rules, and backup schedules.
Cancel or complete in-flight work deliberately; distinguish queued, running, completed, failed, cancelled, and unknown results.
Remove secrets and provider-specific dependencies from transferred automation, or document why it cannot be transferred safely.

7. Transfer management authority service by service

Make the new control plane authoritative before retiring the old one. Coexistence should be brief, documented, and tested because two tools competing over policy, patching, security controls, or device configuration can produce ambiguous results.

Assign a named authority for identity, endpoint management, RMM, EDR, backup, DNS, email, networking, certificates, and vendor portals.
Test one representative device and one critical workflow under the receiving authority before wider cutover.
Define the exact point when the outgoing system stops monitoring, patching, automating, backing up, and opening tickets.

8. Remove agents and remote-access components in waves

Use a controlled removal plan that preserves support long enough to recover failures. Uninstalling the main RMM agent does not prove that helper services, remote-control modules, scheduled tasks, certificates, firewall rules, or service accounts are gone.

Pilot removal on representative workstations, servers, offline devices, and systems with another management agent present.
Verify services, processes, files, tasks, extensions, certificates, accounts, network listeners, and unattended-access records are removed as intended.
Track devices that are offline, inaccessible, failed, excluded, or awaiting local action; do not report them as complete.

9. Return, retain, and delete data by rule

Separate the client copy, the provider's justified retention copy, and data that should be deleted. Apply the contract, law, insurance, incident, and litigation requirements instead of using one indefinite retention rule for every artifact.

Classify exports, logs, recordings, tickets, credentials, configuration backups, reports, invoices, and personal data by disposition.
Record the location, custodian, access restriction, retention period, deletion trigger, and exception authority for retained material.
Delete only after required transfer and hold checks pass, then preserve defensible evidence of the completed disposition without retaining the deleted content itself.

10. Reconcile exceptions and obtain closeout acceptance

The engagement is not closed while an endpoint, credential, job, data set, or responsibility has an unknown state. Produce a concise exception register and have the authorized parties accept ownership of every remaining item.

Reconcile the final asset count against the baseline and receiving system; explain every difference.
Test former access paths, alert delivery, management authority, backup responsibility, and emergency contacts after cutover.
Record open exceptions, risk owner, compensating control, due date, evidence location, and final client or successor acceptance.

Share this resource

Cite the canonical checklist

Editors, educators, and resource librarians can link directly to this public, ungated version. The checklist and both downloads remain available without registration.

Nizlo. "MSP Client Offboarding Checklist." Last reviewed November 1, 2026. https://nizlo.com/guides/msp-client-offboarding-checklist

Frequently asked questions

Timing, access, evidence, and agent removal

How long should MSP client offboarding take?

The timeline depends on the contract, environment size, successor readiness, retention duties, and open risks. Set a written exit date and milestones, but keep a controlled recovery path until representative access, management, automation, backup, and agent-removal tests pass.

What should an MSP remove when a client leaves?

Reconcile technician and guest identities, active sessions, API keys, service credentials, delegated access, VPNs, password-vault access, RMM and remote-control agents, helper services, scheduled tasks, certificates, firewall rules, integrations, and provider-owned automation. Record exceptions instead of treating an unknown state as removed.

Should credentials be transferred or rotated during offboarding?

Transfer ownership through an approved secure channel, verify the receiving party can use the required access, and then rotate shared, service, API, webhook, recovery, and local-administrator credentials. Do not place secrets in ordinary email or copy them into the closeout ticket.

What evidence should an MSP keep after offboarding?

Keep only evidence justified by the contract, law, insurance, incident response, billing, or litigation requirements. Document each retained artifact's purpose, location, custodian, access restriction, retention period, deletion trigger, and exception authority without retaining client content indefinitely by default.

How do you prove an RMM agent was fully removed?

Test representative workstations, servers, offline devices, and systems with another management agent. Verify that services, processes, files, scheduled tasks, extensions, certificates, accounts, network listeners, helper modules, and unattended-access records are gone, and track every failed or unreachable device as an open exception.

Complete the client lifecycle

Build the handoff requirements during onboarding.

A clean exit starts with an accurate baseline, named owners, tested access, and documented acceptance. Use the companion checklist to establish that evidence before management begins.

Read the MSP client onboarding checklist

Test the exit before trusting the rollout

Include clean removal in a 14-day RMM pilot.

Qualified MSP and IT operators can evaluate Nizlo without a credit card on authorized lab or noncritical Windows or macOS systems. Nizlo remains Windows-first, so verify required workflow depth on each platform. Founding Tester discounts are awarded by successful paid upgrade order: the first five receive 75% off for life, the next five 50%, and the next ten 25%. Applying or starting a trial does not reserve a position.

Start the 14-day trial