Exit and transition planning: what the decision maker looks at
Exit and transition planning turns into a controlled procedure once a contract is due to end or terminate early. The decision maker checks four things: what data and access exist, who holds them, what the timeline allows, and where the point of no return sits. Everything else in the process follows from these four checks.
What changes once exit is on the table
Before a notice is served, the relationship runs on the terms both sides signed. Once exit is triggered, the clock starts on obligations that were dormant: data return, access revocation, staff handover, and — where the vendor holds source code or configuration — the release of what is needed to keep the system running. The practical risk is not the exit itself. It is the gap between the day access is cut and the day the replacement is ready to receive what was handed over.
This gap grows when nobody has mapped what actually needs to move. A contract can be short on detail here, and the decision maker's first task is to close that gap on paper before it opens in practice.
What to do
- Instruct the account holder to pull every active agreement touching the vendor, including side letters and change orders, before any notice is sent.
- Ask the technical lead to list systems, data stores and integrations the vendor touches, ranked by how hard each is to replace.
- Task the decision maker with fixing the point of no return — the date after which reversal becomes impractical rather than just costly.
- Send the notice through the channel and to the recipient the contract names, and log the date it was delivered.
- Set a transition timetable with the vendor, naming who confirms each handover step is complete.
- Confirm data return and deletion in writing before final payment is released, not after.
Who decides, and by when
| Stage | Who decides | Typical timeframe |
|---|---|---|
| Whether to trigger exit | The commercial decision maker on the client side, usually with legal sign-off | Set by internal escalation, not by the contract |
| Form and delivery of notice | The party serving notice, following the contract's notice clause | Immediate once the decision is made |
| Transition plan and milestones | Agreed jointly, chaired by whoever the contract names as transition lead | Usually fixed within days of notice |
| Confirmation of completion | The receiving party, by written acceptance | End of the agreed transition window |
Forks
If the vendor holds data through a subprocessor rather than directly, the approval chain for handover runs one level further out. That chain is covered separately in Subprocessor approval process: what the decision maker looks at, and it should be checked before notice is sent, not after.
If part of the arrangement involves tokenised rights, a separate representation obligation attaches to those assets, and it runs on its own deadline described in Representation requirements in tokenised rights and the deadline. Treat it as a parallel track, not as part of the general transition timetable.
If the vendor disputes the trigger for exit, the transition timetable is put on hold until the dispute mechanism named in the contract has run its course. Planning continues in parallel, but nothing is executed until the dispute is resolved or a court or tribunal orders otherwise.
Retention while the transition runs
During the handover window, what gets kept, what gets extracted, and what a copy of the file looks like once the matter closes is handled the same way across every procedure on this site. That step is described in Retention: the report, the extracts and our copy step.
Sources and limit
This page describes the sequence of decisions and the roles that make them. It does not set out how a contract should be worded, and it does not state country-specific deadlines, because this is a procedure page and no statute or regulation is cited on it.
What a finished file looks like once the review is complete is shown in Sample counterparty report, as delivered and what to prepare, alongside what a client should assemble before the review starts.
Where the counterparty is registered in Estonia, what can be established from the public record and what cannot is set out separately in Document in Estonia and the evidence.
Verified
This page was checked against current internal procedure and last reviewed before publication. No article, regulation or national statute is cited, in line with how procedure pages on this site are written: the decision maker needs the sequence and the deadline, not a reference number to verify separately.
FAQ
How long does exit and transition planning take in practice?
Length depends on how many systems and data stores the vendor touches and how cooperative the handover is. A single-system transition with a cooperative vendor can close within a few weeks of notice. A multi-system transition with a subprocessor in the chain typically runs longer, and the point of no return should be fixed early rather than discovered late.
Which documents are needed to start?
The current contract with all amendments, any side letters or change orders, a list of systems and data the vendor touches, and the contract's notice clause. Without these four, the decision maker cannot set a realistic timetable or confirm who has authority to sign off each step.
What happens if the other side does not respond?
Silence does not stop the clock the contract set for notice or transition. Escalation follows the contract's own mechanism first — usually a named contact or a dispute clause — before any external step is considered. Document every attempt to reach the other side, with dates, because that record matters if the matter later moves to a forum.