This checklist is a starting point. Adapt it to the system and to what the business needs from it.
1. Know what the business depends on
List the workflows that must keep working, who uses them and what an interruption would cost. Name a person who can confirm that each workflow still behaves correctly. Age alone does not show which part of a system should change first.
Evidence to ask for: a short workflow inventory, the critical periods in the year and the agreed business priorities.
2. Establish ownership and access
Find out who controls the source code repositories, domains, cloud accounts, deployment pipelines, third-party subscriptions and data. Record the authorised administrators and how access is granted and removed. Transfer credentials through a secure channel, never in the project document.
Evidence to ask for: an ownership register, and a plan to remove the outgoing supplier’s access once the handover is complete.
3. Prove that the software can be built
Ask the incoming team to build the application from the repository and its documented dependencies. A source code archive is of little use if only one former developer’s laptop can produce a working release.
Evidence to ask for: a build that can be repeated, and a record of dependencies and anything missing.
4. Prove recovery before relying on it
Check what is backed up, who can restore it and whether the process has ever been exercised. Agree with the business how much data loss and how long a recovery would be acceptable. Do not assume a daily backup meets every need.
Evidence to ask for: a restore exercise in an isolated environment, with the results and outstanding issues.
5. Understand releases and rollback
Document the path from an approved change to production. Include database changes, configuration, external services and the conditions that would trigger a rollback. Confirm who can approve a release and who is available if it fails.
Evidence to ask for: a release checklist and a rehearsed recovery or rollback suited to the change.
6. Record important behaviour
Identify the calculations, permissions, integrations and business exceptions that users rely on. Add checks around the most consequential behaviour before changing it. Existing behaviour may include defects, so agree the expected outcomes and do not treat everything old as correct.
Evidence to ask for: representative examples, and tests for the workflows chosen as critical.
7. Map dependencies and support exposure
Record the frameworks, databases, hosting components and external integrations. Check their support status against each vendor’s current documentation. An unsupported component is a risk, not yet an incident, so set the order of remediation in context. Our end-of-support dates cover the common Microsoft platforms.
Evidence to ask for: a dependency inventory with sources, review dates and an owner for each unresolved risk.
8. Make running costs and responsibilities visible
Separate hosting, licences, third-party services, planned improvements and incident response. Agree cover, escalation, responsibilities and exclusions with the supplier. Do not assume a maintenance arrangement includes round-the-clock support.
Evidence to ask for: a cost breakdown and a written operating agreement.
9. Choose a small, useful first change
Pick an improvement with a clear business purpose and a result you can see. Compare maintaining the current component, changing it a step at a time and replacing it. Record why the chosen option is proportionate.
Evidence to ask for: a scoped first deliverable, acceptance checks and a release plan.
10. Keep the next handover possible
Update the documentation as the team learns. Keep business-owned access, build instructions, operational notes and decision records current. Agree how code, data and knowledge would be returned if the relationship ends.
Evidence to ask for: an accessible handover pack with an owner and a review date.
How we use it
This is the order we work in when we take over a system. If you are planning a change of supplier, the supplier transition plan sets out who does what, and when.