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.

Last reviewed September 26, 2026Tool-neutral · evidence-first

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.

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 systems. 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.

Apply for the Founding Tester pilot