Ending a contract: checklist for a clean handover
The twenty steps to end a web or software relationship without losing access, data, rankings or goodwill, in the order to do them.
The short answer
Ending a web or software relationship cleanly is a sequence, and most of it happens before notice is given. Before notice, confirm quietly what you already control, secure what you can, and line up the successor, so that the hand-over is a formality rather than a negotiation. At notice, follow the contract precisely and in writing. During hand-over, verify everything rather than trusting it: log in, clone, restore, test, while the old supplier still has access to help. After, rotate credentials, remove access, confirm deletion of your data and document the new state. Twenty steps in four phases, below, in the order to do them.
The checklist
| Phase | Steps |
|---|---|
| Before notice | 1. Read the exit clause: notice period, hand-over terms, cooperation, data. 2. Inventory every asset and account: domain, DNS, hosting, repository, services, analytics, email sending, app stores; note whose name each is in. 3. Secure what is yours: two-factor, recovery details, remove unknown users. 4. For anything in the supplier’s name, plan the transfer request. 5. Select the successor and brief them on the inventory. 6. Take your own backups: content export, database export, media, repository clone if reachable. |
| At notice | 7. Give notice in writing exactly as the clause requires, with the date. 8. List the hand-over items and dates from the contract in the same message. 9. Request transfers of anything in the supplier’s name, in writing. 10. Agree the cooperation period and its scope. |
| During hand-over | 11. Repository transferred to your account with full history; successor clones and builds it. 12. Documentation received; successor reads it and lists gaps. 13. Domain, DNS, hosting and services confirmed in your accounts; successor added; supplier still present. 14. Credentials moved to your password manager; nothing held only by the supplier. 15. Data exported and checked; backups restored by the successor to a fresh environment. 16. A change deployed by the successor through the pipeline to prove the path. 17. Redirects, analytics, email sending and integrations verified working. |
| After | 18. Rotate every credential the supplier held; remove their access everywhere. 19. Confirm in writing that the supplier has deleted your data and retained nothing. 20. Update the setup document to the new state and store it where the business can reach it. |
The order matters
- Control first: secure what is yours before anyone knows you are leaving.
- Successor second: someone ready to receive and verify.
- Notice third: in writing, with the checklist attached.
- Verify fourth: every item proven, not promised, while access remains.
- Rotate and close last: only after everything is verified.
Keeping it professional
A clear checklist helps a supplier behave well at exit: they know what is expected and when, and the successor’s questions are scoped. Written communication, fixed dates, and a defined cooperation period keep the tone practical. The successor should be in the conversation from notice onward, receiving directly, so nothing passes through you twice.
What this means for you
Prepare before notice, give notice by the book with the checklist attached, verify everything during hand-over while the old supplier still has access, and rotate, remove and document afterwards. Twenty steps, in order, turn an exit into a project with a checklist rather than a dispute with a deadline. And the first six steps are worth doing today regardless.
Frequently asked questions
When should we start preparing to end a contract?
Before giving notice, quietly: read the exit clause, inventory what is in your name and what is not, secure the domain and accounts you can, and line up the successor. The strongest position at notice is one where the hand-over is a formality because you already hold what matters. Discovering gaps after notice is how exits become negotiations.
What if the supplier becomes uncooperative?
Rely on what you already control and on the contract: the domain, accounts and repository you secured before notice, the hand-over terms in the exit clause, and written requests with dates. Escalate calmly and in writing. Where ownership was never in your name, a formal complaint is possible under SIDN's regulations for a .nl domain or the UDRP for a .com, and either takes months; the lesson for next time is to hold the assets from the start.
Should we keep the old supplier on for a transition?
A short, defined cooperation period after hand-over, for questions from the successor, is normal and worth paying for if it is not included. An open-ended overlap where both suppliers have access and neither is clearly responsible is not. Define the period, the scope and the end date.
Sources
- ICANN: Registrar Transfer Dispute Resolution Policy (accessed 2026-09-14)
- ICANN: Uniform Domain Name Dispute Resolution Policy (accessed 2026-09-14)
- WIPO: Dispute Resolution Regulations for .nl Domain Names (accessed 2026-09-14)