Exit and transition planning: stages and deadlines
Exit and transition planning maps how a technology contract ends without disrupting the service it supports. It sets out the stages, the documents each stage produces, and the deadlines that turn a smooth handover into a forced one. The plan is agreed before termination notice is served, not after.
What changes once notice is served
Serving notice starts a clock that the contract, not either party's convenience, controls. Obligations that were background clauses — data return, knowledge transfer, service continuity — become active deadlines with named owners. Disputes at this stage usually trace back to one cause: nobody agreed the schedule before the clock started. A plan drafted after notice is a negotiation under pressure. A plan drafted before notice is a checklist.
Stages and deadlines
Exit runs through six stages regardless of the underlying system. Each stage produces a document that the next stage depends on. Skipping a document does not skip the stage — it moves the risk downstream.
| Stage | Output document | Typical trigger | Who acts |
|---|---|---|---|
| Notice and scoping | Notice letter, scope memo | Contractual notice period starts | Contract owner |
| Inventory | Asset and data inventory | Within the first weeks of notice | Technical lead, both sides |
| Knowledge transfer | Transfer log, runbooks | Runs in parallel with inventory | Outgoing team |
| Testing and acceptance | Acceptance certificate | Before cutover date | Receiving party |
| Cutover | Cutover record | Fixed calendar date | Both parties jointly |
| Post-transition support | Support ticket log | Fixed window after cutover | Outgoing party |
The point of no return sits between testing and cutover. Once the receiving party signs the acceptance certificate, reverting to the old arrangement stops being a practical option. Everything before that signature is reversible with effort; everything after it is a new operating reality.
Steps to take
- Trigger the exit clause in writing and record the date the notice period actually starts.
- Assemble a joint inventory of systems, data stores, and access credentials before drafting any schedule.
- Where personal data is involved, run a Legitimate interest assessment overview and the deadline before deciding what is retained and what is deleted.
- Draft the transition schedule with a named owner and a deadline for each stage in the table above.
- Fix the cutover date on the calendar early; treat it as immovable unless both sides agree in writing.
- Confirm the length and scope of the post-transition support window before cutover, not after.
Who decides and where disputes go
Day-to-day decisions sit with the contract owner and technical lead named at the notice stage. Disagreements over scope or timing escalate to whichever forum the contract names for disputes — a steering committee, a named executive, or an external process. The schedule should state, for each stage, who signs off and how many days they have to respond. Silence at this stage is the single most common cause of delay.
Forks in the plan
If the receiving party is an internal team, knowledge transfer can run informally and the schedule can compress. If the receiving party is an external vendor, every handover step needs a written acceptance, because the vendor has no institutional memory to fall back on.
If the system in transition touches tokenised assets, a different question can surface mid-plan: who holds the rights once the ledger forks. That question is not answered by the exit schedule itself — see Fork tokenised rights explained step by step for how it is resolved separately.
What this page does not cover
This page does not set out how termination itself is triggered, what compensation follows an early exit, or how a specific escrow release works. It covers the mechanics of moving from one operator to another once the decision to exit has already been made.
Sources and limit
The stages above reflect standard contract mechanics for technology and outsourcing agreements, not a single statutory procedure — exit clauses are drafted, not legislated, and the schedule in any real contract can vary. Before relying on a specific deadline, check the contract's own exit clause against the current state of the relationship. A Counterparty report before renewing a contract and its limits checks whether the other party's own filings still match what the contract assumes. A Document report when dates do not match the register checks whether the dates in the exit schedule itself still hold against the public record.
How the file is structured
A file built for exit planning keeps four folders: the notice and the clause it relies on, the inventory as it stood on the trigger date, the transition schedule with sign-offs, and the acceptance and cutover records. Each folder is dated, not versioned by memory. When a dispute arises months later, the file — not recollection — settles it.
Cost factors and response times
What an exit plan costs to prepare depends on how many systems are involved, how many jurisdictions the data touches, whether the notice period has already started, and whether the other side is cooperating or contesting. A single-system exit with a cooperative counterparty is a different piece of work from a multi-jurisdiction estate under dispute.
A partner responds to a first enquiry within minutes during business hours. A fee estimate for the plan itself follows within one business day.
Related publications
See also: Subprocessor approval process technology contract, which shares the same stage-and-deadline structure for a narrower question.
Frequently asked questions
How long does exit and transition planning take in practice?
A single system with a cooperative counterparty typically clears the six stages in eight to twelve weeks. A multi-jurisdiction estate, or a contested exit, regularly runs several months longer, mainly because knowledge transfer and acceptance testing cannot be compressed safely.
Which documents are needed to start?
The original contract with its exit clause, the notice already served or drafted, and a first-pass inventory of the systems and data in scope. Without the inventory, the schedule has nothing concrete to attach deadlines to.
What happens if the other side does not respond?
The schedule should already name an escalation route and a default deadline for sign-off. If the contract is silent, non-response is treated as a delay to record in writing, then escalated through whichever forum the contract designates for disputes.
If an exit is already under way
Two situations often accompany a live exit: When source code escrow is demanded and its limits, and When the contract term outlives the product explained. Both cover the moment before the schedule above can even be drafted.