A safe vendor exit preserves the organisation's ability to operate while control moves from the outgoing arrangement to the target one. The work should begin before notice is served and should be driven by evidence rather than assumptions about ownership, data export or supplier cooperation.
Step 1: define what “control” means
For the relevant system, control may include:
- continued access for authorised users;
- complete and usable business data;
- administrative and recovery access;
- source code and rights where applicable;
- cloud, domain and integration accounts;
- operational knowledge and documentation;
- the ability to appoint a replacement supplier;
- a tested route to restore service.
Step 2: review the contract and timing
Record notice periods, auto-renewal dates, minimum terms, termination triggers, transition assistance, data-return provisions, charges and deletion timelines. Contract wording may not cover every practical dependency, so compare it with the real operating model.
Obtain specialist advice where rights, insolvency, disputed fees or personal data create material risk.
Step 3: create an asset and dependency map
| Area | Questions |
|---|---|
| Data | What exists, in which formats, with which relationships and history? |
| Technology | Which repositories, environments, databases and services are required? |
| Accounts | Who owns the tenant, billing, domain and administrator recovery? |
| Integrations | Which systems send or receive data, and how will they be rerouted? |
| People | Who holds undocumented knowledge or performs manual work? |
| Rights | What may the organisation continue to use, modify or transfer? |
Step 4: prove the exit material early
Request sample exports, repository access and documentation before the final transition. Test:
- whether exports include identifiers, relationships and attachments;
- whether another team can build or understand custom software;
- whether administrator access is genuinely independent of the vendor;
- whether licences and subscriptions can transfer;
- whether backups can be restored.
Do not wait until the last contract day to discover that an export is incomplete.
Step 5: prepare the target operating model
The replacement may be another SaaS product, a new supplier or an internal team. Define who will own:
- support and incident response;
- security administration;
- deployments and change approval;
- provider and licence management;
- data quality and retention;
- user communication and training.
Step 6: run controlled migration and parallel checks
Use test migrations before the final cutover. Reconcile totals, relationships, permissions, documents and key reports. Where practical, run representative processes in both arrangements for a limited period and compare results.
Define the final decision point, acceptable open issues and rollback criteria.
Step 7: change access in the right order
Prematurely revoking supplier access can interrupt service; delaying it can leave an unmanaged security risk. Use a timed access plan:
- establish business-controlled administration;
- transfer and test recovery methods;
- identify automation using supplier credentials;
- create replacement identities;
- rotate secrets and remove obsolete access after validation;
- retain an audit record of changes.
Step 8: close the old service deliberately
Confirm final invoicing, data return or deletion, retained records, account closure and the end of support obligations. Monitor for failed integrations, unexpected renewals and users still relying on the old system.
Common loss-of-control points
- The domain or cloud account is in a supplier employee's name.
- The data export omits attachments, audit history or relationships.
- The source repository does not match production.
- Commercial component licences cannot transfer.
- Notice is served before a replacement is ready.
- The outgoing vendor alone can reset administrator access.
Trace one critical transaction
Choose one critical business transaction and trace every system, person, account and data item required to complete it. Repeat for reporting and recovery. The resulting map becomes the minimum control checklist for the exit.