How to hand over a website to a new partner cleanly
The hand-over from the receiving side: what a new partner needs, in what order, and how to make the first month a takeover rather than an archaeology project.
The short answer
A hand-over to a new partner is clean when the new partner receives five things in the right order while the old partner is still available: access, code, documentation, data and context. Access first, because it lets everything else be verified: domain, DNS, hosting, repository, services, analytics, search console, email sending, all in your accounts, with the new partner added and the old one still present. Then the code with its history, the documentation that exists, exports of data and content, and an hour with whoever knows the site’s history. The new partner verifies each by doing it, clone, build, deploy to a preview, restore a backup, submit a form, before the old partner’s access ends. Context is the part most often lost, and an hour of it saves a month of archaeology.
The five things, in order
| Order | What | Why in this position | How the new partner verifies |
|---|---|---|---|
| 1. Access | Every account in your name; new partner added; old partner still present | Nothing else can be checked without it | Logs in to each; confirms roles; notes anything not in your name |
| 2. Code | Repository with history, transferred to your account if not already | The site cannot be run or changed without it | Clones, builds, deploys to a preview; compares with production |
| 3. Documentation | Setup document, runbook, integrations, decisions, whatever exists | Turns the code into a system someone can operate | Follows it; lists every gap |
| 4. Data | Exports of content, database, media; backup locations and how to restore | The business’s assets, separate from the code | Restores a backup to a fresh environment; opens the exports |
| 5. Context | An hour with the old partner or whoever knows: why things are so, what was tried, what customers ask, what is fragile | The knowledge that never made it into documents | Writes it down; adds it to the setup document |
Running it from your side
- Before notice, quietly confirm what is in your name and secure it; select the new partner.
- At notice, share the hand-over list with both partners and the dates.
- Add the new partner to every account you control; request transfers for anything you do not.
- Have the code transferred to your repository account, with history.
- Collect documentation and exports into your own storage.
- Arrange the context hour, with the new partner asking the questions.
- The new partner verifies everything and reports gaps while the old partner can still answer.
- Close the old partner’s access only after verification, and rotate credentials.
Done properly, the switch itself is the shortest part. Our own move between hosting projects in September 2026 took four seconds of actual cutover; everything before it was preparation and documentation.
What the new partner does with it
Runs the onboarding audit on what was received: ownership confirmed, backup restored, deploy path proven, forms tested, security and speed measured, the setup document rewritten from what was verified and what the context hour revealed. The first quarter’s list comes from that audit. A clean hand-over means the audit finds a known state; a poor one means it finds surprises, and the surprises set the agenda.
What this means for you
Hand over in order, access, code, documentation, data, context, while the old partner is still available, and have the new partner verify each by doing it before the old access closes. Secure what is yours before notice, and make the context hour non-negotiable. A hand-over run this way gives the new partner a known state and a first quarter of improvements instead of a first quarter of discovery.
Frequently asked questions
What should the new partner receive on day one?
Access to every account in your name: registrar, DNS, hosting, repository, services, analytics, search console, email sending. Then the code and its history, the documentation that exists, exports of data and content, and a conversation with whoever knows the site's history. The order matters: access lets the new partner verify the rest.
What if the old partner is not cooperating?
Rely on what is in your name and on the contract's exit terms, in writing with dates. The new partner works from what you can provide: the live site can be crawled, exports taken from any admin you can reach, the domain and hosting secured if they are yours. Where ownership was never in your name, the recovery processes exist and are slow, and the new partner runs them while stabilising what can be stabilised.
How long should the overlap be?
Long enough for the new partner to verify everything by doing it, typically a few weeks, with the old partner available for questions for a defined period after. Both having access indefinitely is a risk; neither having verified access is a worse one. Define the overlap, verify inside it, then close the old access.