Use this plan when the current supplier is still trading and the move is your choice. Work through the phases in order and do not start one until the tasks in the one before are done.
In the “Who” column, You means your organisation, Outgoing means the supplier you are leaving and Incoming means the supplier taking over. Adapt the tasks to your system and your contract. Nothing here is legal advice.
1. Before you give notice
The aim is to hold everything you need before the current supplier knows you are leaving.
| Task | Who | Done when |
|---|---|---|
| Read the contract for the notice period, code ownership and exit assistance | You | You know the dates and what you can ask for, with advice taken where the wording is unclear |
| List the workflows the business depends on, and its busy periods | You | A written list names a person who can confirm each workflow |
| Obtain the current source code | You | A copy sits in a repository you control |
| Obtain a full backup of the database and files | You | The backup is stored outside the supplier’s control |
| List every account: hosting, domains, certificates, third-party services | You | A register shows who holds and who pays for each |
| Choose the incoming supplier | You | Terms are agreed, including an assessment of the system |
| Assess the system’s condition | Incoming | A written report exists and the code you hold has been built |
2. Agree the handover
The aim is a dated plan that all three parties have accepted.
| Task | Who | Done when |
|---|---|---|
| Give notice in writing | You | The outgoing supplier has acknowledged the end date |
| Settle outstanding invoices | You | No disputed amounts remain |
| Agree paid handover time | You, Outgoing | Hours, rate and end date are confirmed in writing |
| Set the timetable for phases 3 to 6 | All | Dates are agreed and avoid your busy periods |
| Name one contact on each side | All | Three names, with how to reach them |
| Pause non-urgent changes | You, Outgoing | Only fixes are released until the switch |
3. Transfer ownership and access
The aim is for everything to be in your organisation’s name, with the incoming supplier given access by you.
| Task | Who | Done when |
|---|---|---|
| Move the source repository to your organisation | Outgoing | You are the owner and Incoming has access |
| Move hosting, domains and certificates | Outgoing, You | Each account is owned and paid for by you |
| Move third-party service accounts | Outgoing, You | The register shows your organisation against each |
| Pass credentials through a secure channel | Outgoing | Incoming has logged in to each, and nothing was sent by email |
| Hand over documentation and the list of open faults | Outgoing | Incoming confirms receipt |
| Walk through the system and its routine tasks | Outgoing, Incoming | Scheduled jobs, renewals and manual steps are written down |
4. Prove the new supplier can run it
The aim is evidence. Until these three checks pass, the outgoing supplier should stay involved.
| Task | Who | Done when |
|---|---|---|
| Build the application from source | Incoming | The build matches the running system, with any gaps listed |
| Restore a backup into an isolated environment | Incoming | The restore works, and the time taken and age of the data are recorded |
| Release one small, low-risk change | Incoming | The change is live and the rollback steps are written down |
| Document the release process | Incoming | Another person could follow it |
| Record dependencies and their support dates | Incoming | An inventory covers frameworks, database, hosting and services |
| Confirm the critical workflows | You | The named people have checked each one after the release |
5. Run in parallel
The aim is for the incoming supplier to do the work while the outgoing supplier is still there to answer questions.
| Task | Who | Done when |
|---|---|---|
| Stay available for questions | Outgoing | Questions are answered within the agreed handover time |
| Handle new faults and requests | Incoming | Faults are fixed without help from Outgoing |
| Keep a log of open questions | Incoming | Every question has an answer or a named owner |
| Check monitoring, backups and scheduled jobs | Incoming | Each has run and been checked at least once |
| Agree the maintenance arrangement | You, Incoming | Scope, cover and cost are in writing |
| Decide whether to switch | You | Phase 4 is complete and no blocking question is open |
6. Switch and close
The aim is a clean end, with nothing left in the outgoing supplier’s hands.
| Task | Who | Done when |
|---|---|---|
| Pass responsibility on the agreed date | You | Both suppliers have confirmed in writing |
| Remove the outgoing supplier’s access | You, Incoming | Accounts are closed and shared passwords and keys are changed |
| Check nothing remains in the outgoing supplier’s name | You | The register has been reviewed line by line |
| Pay the final invoice | You | The account is closed |
| Tell users who to contact | You | Staff know how to report a problem |
| File the handover pack | Incoming | Documents are stored where you can reach them, with a review date |
| Agree the first improvement | You, Incoming | One scoped change has acceptance checks |
Risks to watch
- Giving notice before you hold the code, the data and the credentials.
- A handover timed across your busiest period.
- Code on the server that differs from the code in the repository.
- Accounts, licences or domains registered to an individual at the outgoing supplier.
- Routine tasks nobody wrote down, such as renewals or month-end jobs run by hand.
- Ending the outgoing supplier’s involvement before build, restore and release are proven.
- Credentials sent by email or written into this plan.
How we use this plan
CodeFirst runs takeovers in this order, and our takeover service page explains the work behind each phase. For the checks to make on the system itself, see the software takeover checklist.