Changing a software supplier should be a controlled business decision, not a test of whether someone can recover a forgotten account. A practical vendor exit plan answers a concrete question: can an authorised replacement team keep the agreed service running with the data, permissions, documentation and components that can actually be transferred?
The best time to ask is before procurement or renewal. By the time a relationship has become difficult, undocumented dependencies and unclear responsibilities can make an otherwise reasonable transition expensive. This guide focuses on operational handover evidence. It does not determine intellectual property rights or interpret a contract; those matters require the relevant agreements and appropriate legal review.
Start with acceptable dependency, not zero dependency
A specialised product or managed service can remove substantial operational work. Rebuilding every capability solely to make a system portable may create more complexity than it removes. The risk worth investigating is an important dependency whose replacement effort, limitations or owner nobody understands.
The UK government's guidance on managing technical lock-in treats cloud dependency as a balance between the value of a service and the ability to move away from it. That is a useful technical perspective, not a statement about the law governing your software agreement. An organisation can reasonably accept dependency when it understands the benefit and maintains a proportionate contingency plan.
Prioritise business processes. Losing a rarely used reporting feature is different from losing the ability to accept orders. Define which activities must continue, which records must remain accessible and which interruptions require a management decision. A list of technologies alone cannot answer those questions.
Match the handover test to the purchasing model
Custom software with agreed source delivery
Where the agreement includes source delivery, a repository is only part of the package. The receiving team also needs to identify the deployed release, resolve its dependencies and follow a documented build and deployment process. Sample configuration should explain required settings without exposing production secrets.
Do not assume that receiving custom source code transfers every third-party licence. List commercial components and external services separately, including the items that require a new subscription, approval or replacement. Verify contractual permissions before treating an asset as transferable.
Subscription products
A subscription service may not include source code delivery at all. Its exit test should instead examine usable exports, attachments, integration documentation and the practical extraction window. Distinguish information that can be moved from workflows that must be recreated in the replacement product.
Mixed solutions
A custom application might depend on a commercial reporting engine, external messaging and managed storage. Classify each dependency rather than accepting a blanket promise that everything will be handed over. Include the expected evidence in your software RFP checklist, so proposals respond to the same transition scenario.
Turn the asset list into an acceptance register
For each asset, record its current custodian, authorised recipient, delivery format and acceptance test. “Documentation available” is not an acceptance result. “The receiving team deployed the specified release using the supplied instructions” is much stronger evidence.
Typical groups include:
- Business records, required history, attachments and explanations of their relationships.
- Source and release information where included in the agreement.
- Organisational accounts, domains, external services and renewal responsibilities.
- Integrations, scheduled tasks and alert destinations.
- Operating instructions, common failure procedures and known limitations.
- Third-party components and unresolved transfer conditions.
Keep secrets out of the register. Record where credentials are managed and who can authorise access, not the credentials themselves. Assign acceptance to people who understand each area: a project manager cannot independently verify all financial meanings, infrastructure behaviour and business rules.
The register should also expose exclusions. An explicitly recorded, accepted limitation is safer than an apparently complete package with an undiscovered missing component. Give each unresolved item an owner and a next action.
Prove that exported data remains meaningful
A spreadsheet of customers may omit open transactions, attachments, status history and relationships to agreements. A usable export needs enough context for a receiving system or team to understand the information. Ask for field definitions, identifiers, units, date conventions and state meanings.
Test representative journeys. Can an open request still be traced to the right customer? Does its attachment open? Can an older reference be used to find the corresponding record? Do monetary values retain their meaning after conversion? Matching row counts is helpful, but it cannot establish all of this.
Use appropriately authorised test data during exploration, and limit access to sensitive information. Once the method is understood, validate the actual transfer scope under controlled conditions. The data migration validation guide covers that deeper work. Here, the objective is to establish whether a credible handover is possible, rather than execute a full migration prematurely.
Transfer account control without creating an outage
An application can be technically sound while its domain or notification account depends on one person's private login. Identify organisational control and recovery arrangements before the handover. Know who can grant access, renew the service and recover an account when a team member is unavailable.
Prefer named accounts and role-appropriate permissions to a shared folder of passwords. Agree a secure access-transfer process and a plan for replacing keys. However, do not revoke the outgoing team's access before the receiving team has completed the required checks and the transition responsibilities are clear.
After acceptance, remove unnecessary access and rotate relevant secrets in a coordinated sequence. Recheck the integrations that consume them. A shared key changed without a consumer inventory can interrupt the service even when the application itself has been transferred successfully.
Use an independent handover rehearsal
An architecture presentation is useful, but it does not prove operational independence. Set a small exercise in a separate environment. The receiving team should run a specified release, make a harmless configuration change, produce a sample report and locate diagnostic information using the delivered instructions.
The outgoing team can answer questions, but should not perform the whole exercise for the recipient. Whenever undocumented knowledge becomes necessary, record the gap. This is not a failed demonstration: finding those gaps is the purpose of the rehearsal. Update the instructions and repeat the affected step.
For industrial applications, keep rehearsal separate from live equipment control. Demonstrating an isolated dashboard or approval workflow does not authorise connecting to machinery. Production changes must still follow the site's operational and safety approval process.
A hypothetical service-management handover
Consider a company moving application maintenance to a new team. The old supplier delivers the repository and a database export. During a rehearsal, the replacement team discovers that attachments live in separate storage, notifications use an unlisted account and a response-time report depends on an undocumented scheduled task. This is an illustrative scenario, not a claim about a customer project.
File-based acceptance would miss these dependencies. Journey-based acceptance asks the recipient to follow one request from creation to closure: open the attachment, send a test notification to an authorised destination and produce the resulting report. Dependencies become visible where the business process consumes them.
The outcome need not be an immediate supplier change. Management might retain the current provider while correcting account ownership and documentation gaps. Exit readiness creates a practical option; it does not make exercising that option compulsory.
Estimate transition work in comparable units
Ask for separate estimates for extraction, data preparation, documentation, knowledge transfer, environment setup, licensing, limited parallel operation and post-transition support. Each estimate should state assumptions and exclusions. A single fixed number without an inspection may conceal substantial uncertainty.
Include internal capacity. Business representatives must check records and behaviour, and the technical owner must make decisions. A short supplier schedule is not credible if the people needed for acceptance are unavailable.
Compare proposals against the same service boundary. Moving data to a different product is not equivalent to transferring responsibility for an existing application. Specify the critical journeys, acceptable interruption, required history and acceptance owner before comparing price. Avoid treating uncertain discovery work as if it were already fully understood.
Establish gates before transferring responsibility
Use a sequence of explicit decisions. First, confirm the asset inventory and non-transferable items. Next, complete the independent rehearsal. Then obtain data and operational acceptance from the relevant business and technical representatives.
Before the final switch, agree who can stop the transition, what the return path is and how records created during the transition will be handled. Running two systems without identifying the authoritative write destination can create conflicting records. Make the source of truth explicit at every stage.
Close the handover with evidence: delivered items, test results, accepted exceptions and access status. Assign remaining defects and define the support boundary. No checklist can guarantee a risk-free transition, but these records make the decision more defensible and the responsibilities clearer.
Ask for evidence before your next renewal
A useful supplier response explains export scope, knowledge transfer, external dependencies and a feasible acceptance exercise. It does not need to promise zero lock-in. It should make limitations visible and show how they can be tested.
If you are commissioning a new system or reviewing an existing one, start a custom software assessment with EasySaz around one critical process and its known dependencies. Define what an independent receiving team must demonstrate before discussing a wholesale replacement. Good exit readiness is not the absence of dependency; it is the ability to explain, test and manage a change in responsibility.