Design the exit before dependence becomes normal
A SaaS exit plan is not a pessimistic appendix for the end of a contract. It is evidence that the organisation understands what the service holds, which work depends on it and how responsibility would move if the supplier, price, risk or business need changed. The plan should influence selection, architecture and operating practice from the start.
Begin with the business journeys that would stop or degrade. Map users, data, integrations, identity, configuration, reports, automation and support. Then identify the minimum safe state after exit: replacement service, temporary process, retained archive or retirement. Different journeys may need different destinations and timing.
Do not reduce lock-in to whether a CSV export exists. An export may omit relationships, history, files, permissions, workflow rules and derived data. Practical portability depends on meaning, completeness, rate limits, documentation, skills, time and the ability to test the result.
| Area | Question | Proof to obtain |
|---|---|---|
| Data | What can be exported with meaning intact? | Sample export and schema |
| Configuration | Which rules must be recreated? | Versioned configuration inventory |
| Integrations | What must be rerouted or replaced? | Dependency map and fallback |
| Identity | How is access withdrawn and moved? | Joiner, mover and leaver test |
| Assurance | How are deletion and closure confirmed? | Contract terms and exercise |
Set exit scenarios and triggers
Plan more than one scenario. A controlled renewal decision allows months of preparation. A supplier acquisition, service deterioration, security concern, disputed price or insolvency may provide less time and less cooperation. Record which assumptions depend on normal supplier assistance.
Define triggers that start review rather than forcing immediate termination. Examples include a material subprocessor change, unsupported integration, repeated service-level failure, unacceptable contract amendment or a strategic consolidation decision. Give each trigger an owner and evidence threshold so concern becomes a governed assessment.
Connect the scenario to business impact. A collaboration tool, payroll platform and customer transaction service cannot share one generic recovery horizon. Determine tolerable disruption, data loss, manual capacity and regulatory or contractual dependencies with the accountable service owner.
Inventory everything the service has accumulated
Record core records, attachments, audit history, comments, dashboards, calculated fields, templates, automation, integration credentials, webhooks, roles, groups and retention rules. Include supplier-created configuration and partner extensions. These elements often determine whether exported data remains understandable and usable.
Identify authoritative and derived information. A report can be recreated if its source data and logic are preserved, while an opaque score may not be portable. Decide whether derived values must be exported, recalculated or retired and document the consequence for historic comparisons.
Track volume and growth. A sample export that works for a thousand records may not establish the time or cost of moving years of attachments and logs. Measure realistic throughput and API limits before setting an exit window.
Test export quality, not the export button
Request a representative export during evaluation or pilot. Check identifiers, relationships, timestamps, encodings, files, deleted states and a sample of priority records. Record what requires a separate request, professional service or privileged interface.
Import the sample into a neutral store or prototype destination and recreate a small journey. This reveals whether field meaning, ordering and relationships survive outside the original interface. A file that opens is not the same as a service that can be reconstructed.
Use the vendor evaluation scorecard to treat exit evidence as a gate or weighted criterion according to risk. Unknown export limits should remain visible as unknowns, not receive an optimistic midpoint because the supplier expects them to work.
Map integrations and alternate paths
For every connection, record direction, business purpose, owner, authentication, data exchanged, frequency, error handling and dependent journey. Separate an interface that can be redirected from one built around proprietary workflow or identifiers.
The GOV.UK API guidance notes that reliance on a third-party API can tie a service’s availability to that provider and recommends preparing alternatives or queued processing where appropriate. The context is government services, but the dependency discipline applies widely.
Decide how events created during transition will be handled. A parallel run can create conflicting updates, while a hard cutover can create an operational freeze. Design reconciliation, duplicate prevention and communication for the chosen pattern rather than treating integration as a sequence of endpoint changes.
Put usable assistance into the contract
Review notice periods, renewal mechanics, export rights, formats, API access, assistance, charges, retention after termination, deletion evidence and support during dispute or transition. Legal interpretation belongs with qualified reviewers, while operational teams should specify the evidence and activity they need.
Avoid clauses that sound broad but leave delivery undefined. State expected datasets, configuration artefacts, documentation, timing, security method, named interfaces and acceptance. If assistance is optional, model its cost and availability rather than assuming goodwill at the end of the relationship.
Check subprocessor and hosting dependencies. The service may rely on storage, identity, analytics or communication providers whose closure timetable differs. The EDPB cloud-services report highlights roles, transfers and supplier controls in an EEA public-sector context; specific obligations still require jurisdictional review.
Prepare identity, security and deletion
Plan how administrators, users, service accounts and integration credentials are removed or rotated. Confirm which logs and records must remain available during transition and who can access them. An early identity shutdown can prevent export, while a late shutdown can leave unnecessary access.
Define secure transfer, validation and storage for exported material. Temporary migration copies may be more exposed than the governed service because they sit in shared folders or contractor workspaces. Give every copy a purpose, owner and deletion date.
Request deletion confirmation that covers active systems and the supplier’s stated backup lifecycle. Record lawful or contractual retention exceptions separately. Do not claim that every byte is immediately erased when the provider’s architecture supports a staged, documented process.
Exercise the plan while the service is healthy
Run a tabletop exercise with business, technology, security, privacy, procurement, legal and support participants. Walk through the trigger, decision authority, supplier contact, export, alternate process, communication, migration and closure. Capture missing names, evidence and access rather than debating the perfect replacement product.
Add a technical sample each year or after material change. Export a bounded dataset, validate it, restore a journey and confirm credentials and documentation still work. Exercises should not expose live data unnecessarily, but they must be realistic enough to detect drift.
Measure time, manual effort, unresolved dependencies and the age of critical evidence. Update the cost model and recovery horizon from observed results. A plan that has never exercised its hardest step is a hypothesis, not operational assurance.
Make portability part of normal operation
Keep data dictionaries, integration maps, configuration inventories, decision records and administrator knowledge current as part of change control. Exit readiness decays every time the service changes without updating these artefacts.
Review the plan before renewal, major expansion, acquisition, new sensitive data, critical integration or supplier platform change. Link the review to the enterprise applications pathway so portability remains an architecture and ownership concern rather than an isolated procurement file.
The best exit plan does not make switching easy in every circumstance. It makes dependency visible, prices the work honestly and preserves credible choices. That evidence improves both the current supplier relationship and any future decision to remain, renegotiate, replace or retire.
