A managed services exit plan is not a document opened in the final month of a contract. It is a maintained operating capability that lets the customer transfer a service in-house, move to a replacement supplier, disaggregate part of the scope, or stabilize operations during supplier failure. The plan must recover more than files: authority, identities, configurations, automation, licenses, dependencies, evidence, and practical knowledge all sustain the service.
Exit readiness changes normal operations. Assets are registered as they appear, customer-controlled repositories receive current artifacts, privileged access is attributable, export paths are exercised, and runbooks are tested by people outside the incumbent team. This costs something during the term, but it avoids trying to reverse years of undocumented operational decisions while commercial leverage and staff availability are disappearing.
Define exit scenarios, authority, and service priorities
Model planned expiry, termination for cause, supplier distress, partial termination, emergency suspension, and transition after merger or strategic insourcing. Each scenario needs an initiating authority, notice path, transition period, minimum service obligation, cooperation duty, security controls, charging rule, and decision forum. Keep a short continuity-first playbook for cases where legal or financial uncertainty outpaces the full transition plan.
Name exit managers for customer and supplier and identify a replacement-supplier interface before one is selected. Define who may approve data transfer, credentials, architecture changes, staff communication, and risk acceptance. The Sourcing Playbook treats resolution planning as part of good sourcing. In private agreements, the same principle means preparing credible continuity options before distress makes normal cooperation unreliable.
| Scenario | Lead time | Immediate priority | Distinct control |
|---|---|---|---|
| Planned expiry | Contracted runway | Orderly knowledge and asset transfer | Milestone plan and acceptance |
| Replacement supplier | Procurement dependent | Secure collaboration without service loss | Clean-room access and tri-party governance |
| Insourcing | Capability build required | Train and authorize retained team | Shadow, reverse-shadow, competency sign-off |
| Partial exit | Varies by service boundary | Separate dependencies and shared tooling | Disaggregation map and cost allocation |
| Supplier distress | Possibly days | Protect service, data, and critical staff | Emergency access and current escrowed artifacts |
Maintain a service and exit asset register
Inventory applications, environments, data stores, repositories, pipelines, infrastructure definitions, monitoring, dashboards, alerts, tickets, knowledge articles, domains, certificates, secrets, keys, service accounts, devices, licenses, subcontracts, reserved capacity, vendor contacts, support entitlements, and operational records. For each item, record owner, location, administrator, purpose, dependency, contract right, transfer method, export format, renewal date, and deletion requirement.
Classify assets as customer-owned, supplier-owned but transferable, third-party transferable, shared and replaceable, or non-transferable. The UK Model Services Contract guidance discusses registers for assets and subcontracts and the process for transfer or access on exit. Even where that template does not govern the relationship, an updated register turns vague cooperation into a list of executable transfer decisions.
Repatriate data with completeness and usability proof
Define customer data broadly enough to include business records, metadata, relationships, attachments, identity mappings, audit trails, configuration, telemetry required for continuity, and open work such as incidents and changes. Specify canonical formats, schema and code lists, time zones, retention, legal holds, encryption, transfer channel, rate limits, incremental extracts, cutover delta, reconciliation, and final deletion. A database dump without application semantics may be technically complete and operationally useless.
Test export and import at representative volume while the service is healthy. Reconcile record counts, control totals, referential integrity, attachments, timestamps, permissions, and sampled business journeys. Preserve chain of custody for regulated evidence. Define acceptance tolerances and remediation. Keep an independent customer copy at a frequency aligned to recovery needs when lawful and technically feasible; an export route controlled solely by the departing supplier is a weak emergency option.
Transfer control and revoke every access path
List human accounts, federated roles, local administrators, API tokens, service principals, SSH keys, signing keys, break-glass accounts, support channels, VPNs, device certificates, password vault entries, and access granted to subcontractors. Decide which identities transfer, which are recreated, and which must be revoked. Move authoritative control of domains, certificates, repositories, cloud organizations, and key-management boundaries before disabling the incumbent's access.
Run revocation as a controlled sequence tied to cutover. Premature removal can prevent support; delayed removal preserves unnecessary privilege. Capture last-use evidence, rotate shared secrets, invalidate sessions, remove trust relationships, review logs for unexpected access, and obtain a supplier attestation after independent verification. The NCSC supply-chain security guidance calls for clear return and deletion requirements on termination or transfer; access closure is the other half of that obligation.
Separate portable tooling from incumbent dependencies
Determine whether infrastructure code, deployment pipelines, monitoring rules, tests, scripts, dashboards, ticket workflows, CMDB records, and automation can run under customer or replacement control. Store customer-specific artifacts in repositories the customer can access during the term. Document build prerequisites and license constraints. Replace hard-coded supplier tenancy, private package feeds, personal accounts, and opaque managed tooling before they become cutover blockers.
Not everything should transfer. A supplier's general platform may be shared across customers and protected background intellectual property. Define an equivalent-outcome obligation: export customer configuration and evidence, supply documented interfaces, and provide enough assistance to recreate the capability. Identify third-party contracts that can be assigned or novated, those requiring fresh procurement, and those whose notice periods exceed the exit schedule. Budget double-running where safe cutover requires overlap.
Transfer operational knowledge through demonstrated work
Documentation alone does not prove operational competence. Build a service handbook containing architecture, service maps, business calendar, support model, escalation, known errors, recurring work, capacity limits, recovery, security procedures, vendor contacts, change patterns, and pending risks. Assign an owner and review date to each artifact. Record decisions and rationale so the incoming team understands why a control exists and when it may be changed.
Use teach, shadow, reverse-shadow, and independent-operation stages. The incumbent demonstrates; the incoming operator observes; the incoming operator performs while the incumbent watches; then the incoming team handles a representative shift and scenario set independently. Assess competency for routine work and incidents, not meeting attendance. ISO/IEC 20000-1 covers planning, transition, delivery, measurement, and improvement of services; exit acceptance should protect that lifecycle rather than focus only on artifact delivery.
| Transfer domain | Acceptance test | Common hidden gap | Owner after exit |
|---|---|---|---|
| Data | Import and reconcile a representative export | Missing metadata or relationships | Customer data owner |
| Automation | Deploy and roll back from transferred code | Supplier-only runner or package feed | Incoming platform owner |
| Operations | Resolve simulated incident from alert to closure | Undocumented escalation or access | Incoming service owner |
| Identity | Enumerate, transfer, revoke, and verify | Machine tokens and persistent sessions | Customer security owner |
| Licenses | Confirm assignments and effective dates | Non-transferable shared agreement | Commercial owner |
| Knowledge | Incoming team completes reverse shadow | Documents without practiced judgment | Incoming operations lead |
Rehearse exit readiness throughout the service term
Refresh the exit plan after material architecture, supplier, scope, location, or tooling changes and at least at the contractual review cadence. Run focused tests: quarterly contact and repository access checks, periodic data export, annual credential inventory, restore demonstration, and a tabletop transition. Track stale assets, transfer blockers, unsupported dependencies, unowned artifacts, and knowledge concentration as service risks.
During an actual exit, use a milestone plan with dependency, owner, evidence, acceptance authority, target date, rollback, and status. Govern service performance and transition risk together so the incumbent cannot improve transfer statistics by neglecting live operations. Define charges and cooperation before termination. Establish stop conditions when data reconciliation, security, or recovery evidence is inadequate, and retain a documented route back to the incumbent service until cutover is accepted. ISO outsourcing guidance emphasizes governance across the relationship; maintaining exit capability is part of controlling that relationship, not evidence of mistrust.
Managed services exit takeaways
- Plan for expiry, replacement, insourcing, partial exit, and supplier distress.
- Maintain ownership, transfer, license, and dependency data for every service asset.
- Test data for usable reconstruction, not merely successful download.
- Transfer control before sequencing comprehensive identity and secret revocation.
- Move customer-specific automation out of supplier-only tools or define recreation rights.
- Accept knowledge through reverse shadow and scenario performance.
- Rehearse parts of the exit during normal service and track blockers as operational risks.
Managed services exit plan FAQ
When should the exit plan be written?
Draft it before contract signature, baseline it during transition, and maintain it throughout service. Transfer rights, formats, assistance, charges, and licenses are difficult to negotiate after termination is likely.
Should the customer pay for exit assistance?
The contract should distinguish included readiness work, ordinary transfer obligations, and additional termination services. Price rules, caps, and approval should be clear in advance so commercial disputes do not delay continuity.
Does source-code escrow solve exit risk?
Only partially. Source without current dependencies, build instructions, infrastructure, licenses, data, keys, tests, and capable operators may not restore service. Validate deposits and design a broader continuity path.
Conclusion
A credible managed service remains transferable while it is running. Keep assets visible, data reconstructable, access attributable, tooling portable, licenses understood, and knowledge practiced by more than the incumbent. Close the transition only after unresolved defects have named owners, retained evidence is accessible, final invoices can be reconciled, and deletion or continued retention is authorized for every remaining copy. When those controls are refreshed and tested, exit becomes a governed transition with measurable acceptance instead of an urgent attempt to discover what the supplier actually operates.