Changing development suppliers should transfer control and knowledge without turning the live application into leverage in a commercial dispute. A well-managed transition gives the incoming team enough verified information to support the system while protecting the business, users and both suppliers.
Set the transition objective
Decide whether the incoming supplier will:
- take over ongoing support only;
- complete an unfinished project;
- stabilise a failing system;
- modernise or rebuild the application;
- operate infrastructure as well as the application.
The handover depth and discovery budget depend on that objective.
Review rights and access first
Before technical work begins, establish the contractual position for source code, supplier components, licences, data and transition assistance. Then verify practical access to:
- repository and issue tracker;
- cloud and hosting;
- domain and DNS;
- databases and backups;
- deployment pipelines;
- monitoring and logs;
- third-party integrations;
- administrative application roles.
Use a structured handover pack
| Area | Expected content |
|---|---|
| System overview | Architecture, environments, data flows and critical dependencies. |
| Development | Repository, branches, build, tests, release process and backlog. |
| Operations | Monitoring, alerts, backups, support procedures and known incidents. |
| Data | Schema, migrations, retention, imports, exports and recovery. |
| Commercial | Licences, providers, renewals and service contacts. |
| Risks | Known defects, technical debt, security concerns and undocumented areas. |
Allow the incoming supplier to verify
A handover document should not be accepted without testing. The incoming team should:
- build a representative environment;
- identify the production release;
- trace a critical transaction;
- review backup and restoration evidence;
- observe or perform a controlled deployment;
- confirm monitoring and incident routes;
- record gaps and assumptions.
Manage the overlap period
Where possible, define a short overlap with named responsibilities. Avoid having both suppliers make uncontrolled changes. Set rules for:
- who approves and deploys releases;
- who responds to incidents;
- which system records decisions and issues;
- how questions are raised and answered;
- when access changes occur.
Handle a difficult relationship carefully
If the outgoing supplier relationship has broken down, keep requests specific and evidence-based. Use formal contractual routes where required. Preserve logs, code and communication records, but do not take actions that unlawfully interfere with supplier systems or create avoidable service failure.
Separate the incoming supplier's technical assessment from legal conclusions about ownership or breach.
Expect a discovery phase
An incoming team cannot responsibly estimate all future work before understanding the system. Agree a bounded discovery covering architecture, code quality, security, data, operations and immediate continuity risks. The output should distinguish:
- facts verified by evidence;
- assumptions requiring confirmation;
- urgent stabilisation work;
- longer-term improvement or replacement options.
Transition acceptance criteria
- Business-controlled administration is established.
- Incoming team can access and build the current code.
- Production release and deployment route are understood.
- Backups and recovery responsibilities are verified.
- Critical integrations and provider accounts are documented.
- Known risks and open work have owners.
- Outgoing access is removed in a controlled sequence.
Control changes during the transition
Keep a single change log and identify which supplier owns each release. Avoid simultaneous undocumented changes from both teams. If urgent production work is required, record the reason, approving owner, deployed version and information that must be added to the handover.
Agree commercial boundaries
Clarify which handover activities are included in the outgoing contract, which are chargeable and which discovery tasks belong to the incoming supplier. A clear boundary helps prevent duplicate billing and arguments about responsibility.
Do not ask the incoming supplier to certify legal ownership or contractual breach. Its role is to report the technical evidence and operational gaps it can verify.
Protect people and knowledge
Transitions can become personal when teams have worked on a system for years. Use structured questions, recorded sessions and written actions rather than blame. Preserve useful knowledge while still verifying it independently.
Verify the handover through action
Ask the incoming supplier to perform a supervised deployment to a non-production environment and trace one critical incident from alert to resolution. This tests the handover more effectively than a presentation or document checklist alone.