What a Software Exit Plan Should Include Before You Need It

A software subscription can be easy to cancel and difficult to leave. The organisation may be able to download a list of customers, but not the documents attached to their records. An application may belong to the business, while its deployment process depends on an account controlled by a former supplier. A replacement system may be ready, but nobody knows how to transfer the work still in progress.

These problems become visible when circumstances change: a product is retired, prices increase, a contract ends or the organisation needs capabilities its current platform cannot support. By then, the time available to investigate can be limited.

A software exit plan gives the organisation a practical route through that change. It should explain what must move, what must keep working, who can authorise the transition and what evidence will show that the service is safe to continue. The best time to establish those facts is while the existing relationship is working well.

Define the service that must survive the move

Start with the work people depend on, rather than the name of the product. A customer management platform may support enquiries, appointments, document collection, approvals and reporting. Replacing the contact database alone would leave much of the service behind.

Identify the essential transactions and the people who rely on them. Record which tasks could tolerate a short interruption, which need a temporary manual route and which must remain available throughout the change. Include customers, partners and external users as well as staff.

Describe a credible exit scenario. Moving a hosted application to another support company is different from replacing a subscription product with a new platform. The first may preserve the software; the second may require different workflows, data mappings and staff training. A plan should make that distinction clear before anyone estimates the effort.

Prove that an export is usable

An export button is a starting point. Ask what it actually produces and whether someone outside the current platform can understand it. A file containing thousands of records is of limited value if its status codes are unexplained, its identifiers change between downloads or important relationships are missing.

Take a representative set of records through a trial export. Include an active case, a completed case, a record with several attachments and an example with a complicated history. Check whether the exported material preserves the information needed to continue the work and explain previous decisions.

For an application-handling service, that might mean retaining the application, applicant, supporting documents, reviewer comments, current stage and decision history together. Separate spreadsheets and a folder of files may be sufficient, provided there is a reliable way to reconnect them. Filenames that only make sense inside the old system need investigation.

Document field meanings, relationships, date formats and known exclusions. Compare record counts and key totals with the source, then inspect individual examples. Where possible, load the sample into an independent test environment or reader. The useful result is evidence that another team can interpret the material, rather than confirmation that a download completed.

Include configuration and business rules

Data does not explain everything a system does. Approval routes, permissions, pricing rules, document templates, scheduled jobs and report calculations may be stored separately from the records they affect. Some may exist only in settings screens or in the knowledge of a particular administrator.

List the configuration that would have to be transferred or recreated. Record the purpose of each important rule, its owner and an example of its expected behaviour. If an export of the configuration exists, test it; if it does not, agree how it will be documented and checked.

For bespoke applications, examine source code, build instructions, dependencies and deployment access together. Possessing a code archive does not establish that a new team can build, run or maintain it. Arrange a controlled demonstration using the documented materials and record any missing steps or supplier-specific services.

For subscription software, the replacement may implement the same business rule differently. Preserve the intended outcome and the evidence needed to test it. Copying every existing workaround into the next platform can make the move more expensive without improving the service.

Check who controls the accounts and dependencies

A system may rely on domain names, hosting, identity services, email delivery, payment providers, file storage and reporting tools. Moving the application will not automatically move those dependencies.

For each one, identify the account holder, administrator, billing owner and recovery route. Confirm that the organisation has appropriate access and that access recovery does not depend on a supplier employee's personal email address or phone. Use a secure credential store and controlled account access for the handover.

Map the integrations as well. Record which system sends information, which receives it, who owns the connection and how a change of supplier would affect authentication, schedules and error handling. Include less visible connections such as overnight exports and spreadsheets refreshed from the old platform.

Some assets can be transferred; others must be replaced. A licence may need to be purchased again, an integration may need new credentials, and a third party may need time to approve a change. Establish those requirements with the relevant providers while there is time to act on them.

Make the time and cost of leaving visible

Ask for a specific description of exit assistance: available export formats, extraction times, support effort, access after termination and any charges. Check the applicable agreement alongside a practical demonstration. A general assurance that the supplier will help does not provide enough information to schedule a transition.

Estimate the whole move. Include data extraction and checking, replacement integrations, configuration, staff training, overlapping subscriptions and the period needed to consult historical records. Identify assumptions that could change the estimate, such as a large document library or a restricted export interface.

GOV.UK's guidance on managing technical lock-in recognises that provider-specific services can offer worthwhile benefits. It recommends weighing that value against the difficulty of switching, and including the estimated time and cost of leaving in hosting plans and business cases.

The same decision discipline is useful for wider business software. An organisation may reasonably accept a costly exit in return for a valuable capability. That choice should be explicit, affordable and reviewed as the service grows.

Plan how work in progress will move

A trial export describes the system at a point in time. Live services continue to change afterwards. Customers submit requests, staff update cases, payments arrive and documents are replaced. The exit plan needs a way to account for those changes.

Decide how the final transfer would work. Options may include a short pause in updates, an initial transfer followed by a final set of changes, or a staged move of separate teams or services. Choose an approach that the platforms can actually support and that the operation can tolerate.

Identify where new work will be accepted during the transition and how staff will avoid processing it twice. Agree how to reconcile open items, attachments and important totals after the final transfer. Give someone authority to accept the result or delay the switch.

Set a clear recovery point too. Once the new system has accepted transactions, returning to the old one requires a plan for those transactions. Define when a return remains practical and what the team will do if a problem emerges later.

Rehearse a small, meaningful part of the exit

A full migration rehearsal may be disproportionate for a small service. A focused exercise can still expose important gaps. Ask a colleague or prospective support team to work from the plan without relying on the person who wrote it.

Choose an exercise with a clear outcome: reconstruct an active case from exported material, build a test copy of a bespoke application, or produce an essential report without querying the live supplier platform. Use a controlled environment and suitably protected test data.

Record elapsed time, missing access, unexplained fields and manual interventions. Feed those findings back into the plan and the cost estimate. If the exercise requires help from the current supplier, document that dependency rather than assuming the same person will always be available.

Give the plan an owner and a review point

An exit plan becomes less reliable as systems change. A new integration, a larger document store or a revised approval process can make last year's assumptions wrong. Review it before renewal and after material changes, with responsibility shared across the service owner, technical team and people managing the supplier relationship.

Start with one important system. Identify the essential service, test a representative export, confirm account control and write down the largest unknowns. Assign an owner and a next action to each gap. That creates a useful working plan without turning the exercise into a speculative replacement project.

Gemstone's data and integration work and hosting and support services address the connected parts of running a digital service. Understanding those connections makes a supplier change easier to assess, budget and deliver when the organisation needs it.