Software Vendor Exit Plan: Test the Way Out

What should a software vendor exit plan prove?

A software vendor exit plan should show how a defined workflow can move, what evidence would make the replacement acceptable and who can approve the change. Start with a small rehearsal before treating an export button as an exit route. This is business education, not financial advice. Financial decisions belong with a licensed financial adviser. Contract and data-protection questions need qualified legal advice.

Our proposed method starts with a question. Could the next owner complete the work without quietly returning to the old system?

That is different from choosing software. Our build versus buy framework compares the commitment. This playbook examines the way out of one existing dependency. It is a planning method, not a migration we have performed or a promise that a particular product can be replaced.

Does having an exit plan mean you should leave?

No. The UK government's cloud lock-in guidance balances switching difficulty against the value of staying. It recommends considering exit time and cost, and using open standards and formats for software as a service. That is guidance for government cloud decisions. It does not establish your contractual rights or prove that an export recreates a working application.

Write the decision being considered before assembling a replacement shortlist. Perhaps a needed function is disappearing. Perhaps the business wants to test an alternative before renewal. Name the trigger and the evidence that would justify action.

Also write down what would support staying. Otherwise, the exercise can become a search for reasons to replace a supplier the team already dislikes. A documented limit can be an acceptable trade-off when the benefit and contingency are understood.

What exactly has to move?

Define the smallest complete business task. Avoid starting with a list of screens.

For a wholly fictional example, suppose a team uses a hosted tool to receive requests, attach supporting files and record approval. The task is complete when an authorised colleague can find the request, read its evidence and identify its current decision. These are invented requirements, not facts about a client.

The NCSC's supply-chain mapping guidance includes suppliers, subcontractor relationships, services and information flows. It also stresses controlled storage of the resulting map. Use that as context for a focused dependency inventory, not a reason to copy sensitive operating details into an unrestricted document.

For our fictional task, record the request source, file store, identity service and destination for approved work. Name who can verify each connection. Mark an unknown connection as unknown. Do not fill a gap with the architecture everyone assumes exists.

Separate what must move from what may be rebuilt and what must remain available only as a record. Assign a person to each unresolved choice. The supplier's export documentation, the business requirement and the receiving system's supported input are separate pieces of evidence.

How do you make the rehearsal safe?

The FTC's Start with Security guide recommends fictitious information when real personal data is unnecessary for training or development. It also limits access by business need. Apply those principles to an authorised test environment. Keep customer records and credentials out of a casual demonstration.

Ask the responsible technical and security owners to define the permitted test. Record the environment and the actions approved for it. This worksheet authorises no export, account change or production cutover. If a proposed rehearsal needs real restricted information, pause that part until those owners establish an appropriate method.

Write expected results before the test. A test without a stated requirement can end with everyone admiring whatever happened to arrive.

What should the export test actually check?

Use a small, deliberately varied set of invented records. Include cases that challenge the specific requirement, rather than repeating the easiest record. The following is our original paper exercise. No software was tested.

Assume the fictional source contains 12 requests and 9 attachments. The receiving view shows all 12 request identifiers, but only 8 attachments open. One approval appears without the identity of its approver.

The missing attachment count is 9 minus 8, or 1. Matching all 12 request identifiers does not cancel either defect. Nor does this exercise establish a general failure rate. Its numbers are invented to demonstrate separate acceptance checks.

Now change the requirement on paper. Suppose an old decision must remain readable but must never trigger a new notification. Add that behaviour to the acceptance sheet. A record being visible and a record behaving correctly answer different questions.

For an actual rehearsal, keep the source reference, expected result, observed result and reviewer together. Have the authorised team determine suitable checks for permissions, history and linked files. Do not assume every export format carries those features.

What happens to work created during the move?

An exit plan also needs a rule for the transition period. Ask where new requests belong while the change is under way, how corrections are recorded and who reconciles the result. Do not let users invent competing answers.

AWS's migration cutover guidance distinguishes rollback before new data arrives from rollback after the destination receives transactions. It calls for decision checkpoints, data handling and a person authorised to choose the response. Its examples concern AWS migrations. The relevant planning question here is whether returning to the old service would also preserve work created after the switch.

Ask the technical owner to demonstrate the proposed recovery in an approved environment. Record untested conditions. A calendar entry saying “roll back if needed” leaves the important part unanswered.

Do not translate this question into improvised database changes. The implementation belongs with the responsible technical team and its approved change process.

When can the old supplier delete the data?

Contract termination, successful transfer and authorised deletion are separate decisions. Record each explicitly with the people responsible.

For UK controller-processor arrangements, the ICO's contract guidance describes terms for returning or deleting personal data at the controller's choice. It also addresses legally required storage and safeguarded backup retention. The page is marked under review. Ask qualified counsel and the data-protection lead to confirm the current requirements for the actual arrangement. This is not a universal instruction to delete every copy immediately.

Our exit record should identify the authorised instruction, its scope and the evidence of completion. Keep unresolved retention questions visible. Do not treat an account-cancellation email as proof that every required disposal or retention action occurred.

What belongs in the approval record?

Bring the decision back to the business task.

For the fictional request system, the conclusion is that the identifier check passed but the attachment and approval requirements did not. The next action is to find out whether the export, transformation or receiving configuration caused the gaps. Assign that investigation before selecting a departure date.

Keep the proposed exit costs in a separate, dated estimate. Identify supplier assistance, internal work, replacement setup and any period of overlapping service. Get actual terms and estimates from their owners. Do not turn this example into a price benchmark or assume a quoted fee covers all of the work.

An approver should be able to see the accepted scope, unresolved exceptions, authority to proceed and evidence supporting the timing. If a critical condition changes, reopen the affected decision. A test of an earlier configuration is not evidence that a later one behaves identically.

The useful result can be a move, a smaller change or a decision to stay. What matters is knowing which part is demonstrated and which part still depends on an assumption. That is the discipline behind how we work. If the dependency is holding back a larger operating decision, start with that decision.

Sources

• GOV.UK: Managing technical lock-in in the cloud.
• NCSC: Mapping your supply chain.
• FTC: Start with Security.
• AWS: Cutover stage.
• ICO: What needs to be included in the contract?.