Offboarding should leave the customer able to operate without reconstructing years of decisions. A ZIP file is only part of the exit: the customer needs a readable inventory, usable evidence, replacement reporting and an agreed access transition. Begin while the existing service can still answer questions.
Identify what the customer needs back
List domains, approved senders, DNS configuration, signing dependencies, change approvals, report provenance, incident history and unresolved exceptions. Include the current owner for each stream and the evidence needed to continue monitoring. Do not export passwords, private signing keys or unrelated customer records into an ordinary handover archive. Handle any necessary secret transfer through an explicitly approved secure process.
Separate customer-owned records from shared service infrastructure. A customer may own the domain while an MSP hosts a reporting destination or policy dependency. Document each dependency and the sequence for replacement. Removing a dashboard account does not necessarily remove a live DNS dependency, and deleting a DNS record can have effects beyond analytics.
Establish continuity before termination
Record the current reporting destinations and the customer's approved replacements. RFC 9990 describes aggregate reporting and external destination authorization. Check the applicable authorization and receiving setup rather than assuming that a new mailbox address will receive reports immediately. Preserve evidence across the agreed transition window and avoid counting duplicates twice if both systems collect them.
Verify representative sending flows under the retained configuration. Change reporting endpoints and mail-path dependencies as separate approved tasks with separate rollback conditions. A reporting migration should not accidentally replace the sender's signing identity. Use RFC 9989 to keep alignment tests tied to actual messages, not solely record presence.
Verify the export and receipt
Produce a manifest with file names, scope, date range and cryptographic hashes. Ask the recipient to confirm that the archive opens, the inventory matches the agreed domains and the evidence can be interpreted. A successful upload alone does not establish a usable handover. Record gaps explicitly and assign the remaining remediation.
Suppose the customer downloads an archive whose bytes match the agreed manifest, but cannot interpret its sender identifiers and the replacement collector has not yet received an expected report. Byte integrity passed; usability and reporting continuity remain unresolved. Supply the missing inventory mapping, investigate destination authorization and collection timing, and agree what observed evidence will close each gap.
In a separate hypothetical case, the replacement collector works but the MSP still has an active export credential. Retire that credential through the approved exit plan and verify denial at the service boundary. Neither scenario is an actual receipt, customer approval, delivery or revocation. Keep the remaining duties and authorized transition access explicit rather than treating an uploaded archive as completed offboarding.
Retire access with a retention decision
Inventory service accounts, API grants, report recipients and human memberships. Revoke the MSP's access only according to the agreed exit plan, while preserving any approved recovery responsibility. The customer should verify its own continuing administrative access. OWASP authorization guidance supports checking permissions consistently rather than relying on a removed user-interface entry.
Document retained data, purpose, retention authority and eventual deletion responsibility. This guide does not prescribe a universal legal retention period. Where contracts, litigation holds or regulatory obligations affect deletion, obtain the appropriate review. End with an accepted receipt, remaining exceptions and an explicit end to service obligations, not an unsupported promise that all copies everywhere were erased.