A software vendor exit plan explains how your business will keep operating if it changes a software supplier, development partner or hosting provider. It identifies what must transfer, who controls it, how the receiving team will prove it works and when the outgoing supplier can safely lose access.

The useful test is practical: could another competent team run the essential service using the assets, permissions and instructions you can actually obtain? A cancellation clause, a source-code ZIP or a promise to provide an export does not answer that question on its own.

This guide proposes a six-proof review for business leaders and technology owners. Use it before a renewal, during partner selection or when an existing relationship has become difficult to change. It is an operating framework, with an illustrative handover example, rather than a claim about a Vinove customer engagement.

Decide which relationship you might need to exit

“Change the vendor” can describe several different projects. Replacing a development agency may leave your application and hosting unchanged. Leaving a SaaS product usually means migrating workflows and data to another product. Moving cloud infrastructure can require changes to deployment, networking and managed services. Write down the boundary before estimating effort.

For each service, name the business activity it supports, the supplier being replaced and the assets that should remain. Specify whether the objective is a planned transition, emergency continuity or both. A planned exit can include cooperation from the current team; an emergency plan must account for that help being unavailable.

Some dependencies are worth accepting. The UK government's guidance on technical cloud lock-in explains that managed services can offer benefits that outweigh switching difficulty. The decision should weigh those benefits against the cost and practicality of moving. That is more useful than treating every provider-specific feature as a mistake.

If you are still deciding whether to commission a system at all, start with the build-versus-buy decision framework. Exit readiness is one input to that decision, alongside the value of the product and the capability needed to operate it.

Proof 1: The business can control the essential accounts

Create a register of the accounts that keep the service available: source repository, cloud subscription, domain registrar, DNS, certificates, deployment service, monitoring, messaging, analytics and any paid component or integration. Include the billing owner and recovery contact. An account can be technically accessible while its renewal still depends on a departed employee's card.

For each account, distinguish ownership, administrator access and day-to-day access. A supplier can remain the operator while the business holds a recoverable owner account. Where a service genuinely cannot be transferred, document the replacement procedure and its dependencies instead of marking the account “covered”.

Keep credentials in an appropriate managed secret store, not in the handover spreadsheet. The register should point to the access process, identify who approves it and record when recovery was last checked.

Acceptance evidence: a nominated internal owner can demonstrate recovery or authorised administration of every critical account. Exceptions have a named decision-maker, a practical remedy and a target date. Screenshots of someone else's administrator session are insufficient evidence of your own control.

Proof 2: The data is complete enough to use elsewhere

An export button proves that a file can be created. It does not prove that the file contains the relationships, attachments, history and definitions needed to continue the business process.

Choose representative records and follow them end to end. For a customer service tool, that might mean a customer, an open request, its attachments, assignment history and current status. For a finance workflow, it might mean a document, its approval state and the references needed to reconcile it. Define the sample according to your actual use of the system.

Test meaning as well as volume

Ask the receiving team to load the sample into an isolated test environment. Compare record counts and key totals where meaningful, then inspect the relationships and exceptions. A matching row count can still conceal lost attachment links or changed time-zone interpretation.

Record the export format, field definitions, identifier mapping, timezone assumptions and excluded items. Separate a first bulk export from the final changes that will occur while users continue working. Decide how those later changes will be captured and reconciled.

Acceptance evidence: the receiving team can locate and interpret the agreed sample without asking the outgoing vendor to explain every field. Known gaps are visible and accepted by the business process owner. Sensitive data remains subject to the business's existing access and handling controls during the exercise.

Proof 3: A receiving team can build and run the service

For custom software, request the version history, build instructions, dependency versions, configuration requirements, database migrations and deployment definition. Also identify scheduled jobs, background workers, file storage and external services. A web application may appear healthy while the nightly process that sends invoices has stopped.

GitHub's repository backup documentation distinguishes a mirror clone from other backup options and calls out separate handling for Git LFS objects. Its migration archives also have omissions and restoration limitations. Ask exactly what a proposed archive includes and how it will be restored; the word “backup” is not a sufficient specification.

Have someone outside the outgoing delivery team build the agreed version from the supplied materials. Use a controlled environment and approved test data. Record every undocumented step needed to make the build or deployment succeed, then fold those steps into the handover instructions.

For SaaS, replace this build test with a configuration and workflow reconstruction test. The buyer normally will not receive the vendor's application source code. The relevant question is whether the destination can reproduce the essential business workflow with the available data and configuration.

Acceptance evidence: the receiving team demonstrates the agreed release or replacement workflow, with its essential integrations and background processes. A successful homepage load is only one check.

Proof 4: Someone can operate it after the handover meeting

Operating knowledge is easy to overestimate when the existing team is available to answer questions. Make the receiving team practise the tasks it will inherit: diagnosing a failed job, responding to an alert, restoring a backup, renewing a service and rolling back a release.

Use short runbooks tied to actual situations. Each should state the symptom, initial checks, permitted action, escalation contact and evidence that the service has recovered. Record limits to the receiving team's authority so that a routine incident does not become an improvised production change.

NIST's contingency planning guide, SP 800-34 Revision 1, provides a foundation for assessing information systems and setting recovery priorities. It addresses US federal information systems; it should not be presented as a blanket legal requirement for every business. Here, it supports treating continuity as an explicit planning task.

Acceptance evidence: the receiving operator completes an agreed exercise while the outgoing team observes. Any intervention becomes a recorded gap to resolve. A recording of a walkthrough can support the runbook, but does not demonstrate that another operator can carry out the task.

Proof 5: The transition has a funded owner and a workable window

Put the operational plan beside the commercial agreement. Ask the responsible commercial and legal reviewers to confirm what assistance, access and transfer rights are actually agreed. Do not assume that a technical asset being useful means the business automatically has a right to receive it.

Build an estimate from activities rather than one migration figure. Include discovery of unknown dependencies, export and transformation, rebuilding environments, testing, knowledge transfer, temporary parallel operation and the final reconciliation. Identify which costs are confirmed and which remain assumptions.

Timing should start from the business process. A transition during financial close, a major campaign or a seasonal peak may create avoidable pressure. Agree the latest decision date that leaves room for a rehearsal and remediation before the intended cutover.

Acceptance evidence: one accountable transition owner has a task sequence, participating teams, cost assumptions, supplier obligations and a decision window. Outstanding commercial questions are visible before the team relies on the related technical action.

Proof 6: Cutover and access removal are separate decisions

Define the conditions for moving users or traffic, the evidence needed to continue and the conditions that require stopping. Name the person who makes that decision. Agree how updates will reach users and support staff, including what they should do if the transition pauses.

Plan rollback around data as well as application files. Once users enter new records in the destination, returning to the old system may create conflicting versions. Specify whether the old system becomes read-only, how late changes are reconciled and the point beyond which a reverse switch requires a separate recovery plan.

Remove supplier access only after the agreed handover checks and continuity arrangements are complete. Then inventory and revoke obsolete accounts, tokens and integration permissions through your normal access-management process. Confirm the handling of retained copies through the responsible business owners.

Acceptance evidence: there is a signed-off cutover record, reconciled data and a separate access-closure record. “The new supplier has logged in” does not close the old supplier's access.

A worked example: changing a customer portal partner

Consider an illustrative service business that wants a new team to maintain its customer portal. The application will remain on its current hosting platform. Customers need to submit requests and download documents throughout the transition.

The account review finds that the business owns the hosting subscription, but the deployment pipeline sits in the outgoing agency's account. The source repository is available, yet the instructions omit a scheduled document-processing job. An export contains customer rows but no attachment manifest.

A handover based only on source-code delivery would miss all three issues. The six-proof review turns them into specific acceptance tasks: recreate the pipeline in a business-controlled account, document and exercise the background job, and reconcile document references against the exported files.

The receiving team then deploys the application in a test environment, submits a request, processes its document and downloads the result. Operations checks monitoring and a recovery exercise. The commercial owner agrees the support window and the transition lead records cutover and rollback decisions.

This example does not establish a standard duration or cost. It shows why the unit of acceptance should be a working business journey. The same logic can inform the questions used when choosing a product engineering partner.

Turn the review into a decision record

Keep one short record per critical service. Use the following fields so that a later reviewer can distinguish evidence from confidence:

  • Service and boundary: what changes, what stays and which business journey must continue.
  • Owner: the person accountable for the exit decision and the receiving operator.
  • Six proofs: account control, usable data, runnable service, operating knowledge, funded transition and safe closure.
  • Evidence: a dated demonstration, tested artefact or confirmed agreement for each proof.
  • Gap: what remains unknown or failed, its consequence and who will resolve it.
  • Decision: proceed, proceed after named conditions, or defer, with the reason recorded.
  • Next review trigger: renewal, a major architectural change, a supplier change or the agreed periodic review.

Avoid an average readiness score that hides a critical failure. Five strong proofs do not compensate for being unable to obtain the customer data. Treat essential failures as explicit conditions for proceeding, while allowing minor documentation improvements to follow an agreed plan.

Start with one critical service and one representative journey. Ask the proposed receiving team to demonstrate it using the materials already available. The gaps revealed by that exercise will make the next budget and supplier conversation more concrete.

If you are planning a software handover or reviewing delivery readiness, contact Vinove with the service boundary, current dependencies and the decision you need to make.