What the transition is for — and where its boundaries are
Before the asset list, one question: why are you moving? The answer decides the scope of the work. There are three common reasons, and each leads to a different kind of transition.
- The previous vendor is no longer available. A freelancer who moved on, an agency that closed, an internal team that dispersed. Here the transition is mostly recovery: collect what exists and make sure it can run without whoever wrote it.
- The product works, but progress has stalled. Every feature takes longer, every fix breaks something. Here the transition includes a diagnosis: you need to know whether the problem is the code, the process or the communication before deciding what comes next.
- A business decision. Cost, location, wanting a bigger or smaller team. Here there is time, and an orderly handover with the previous vendor can be planned — the most comfortable case, and yet most of the checks get skipped because "everything works".
What is not part of the transition: architecture changes, technology replacement or new features. Those are decisions made after the transition, based on a written diagnosis — not during it. A vendor who proposes rewriting the system before taking it over is skipping the stage where you learn why it was built the way it was.
Code, data and infrastructure: the asset table
This is the central document of the transition. Each row has three fields to fill in: the registered owner (whose name the account is in), who actually holds access, and the status — transferred, pending, unknown. "Unknown" is a legitimate status at the start of the inventory and an unacceptable one at its end.
| Asset | What to check | Who should own it |
|---|---|---|
| Code repositories | All repositories (app, backend, admin, scripts); full history; unmerged branches; who can push changes | Your organisation, not a developer's personal account |
| Environments and servers | Dev, staging, production; cloud provider; who pays; admin access; anything running that isn't in the code | A cloud account in the company's name with your payment method |
| Databases and backups | Where the data lives; whether backups run automatically; when a restore was last tested; whether there is personal data that needs handling | You — including direct access that doesn't depend on the code |
| Domain, DNS and certificates | Domain registrar; DNS management; SSL certificates and their renewal; the system's email addresses | You, with the company's contact details at the registrar |
| App stores | Apple Developer and Google Play accounts; the registered publisher; signing keys; who receives rejection notices | The company as publisher; signing keys in your hands |
| Third-party services | Payments, email and SMS, maps, analytics, push notifications, file storage, AI; API keys; who pays; plan limits | A company account per service; keys rotated at transition |
| Secrets and configuration | Environment files, passwords, encryption keys; where they are stored; whether any of them live inside the code | The company's secrets manager; not in messages and not in code |
| Work tools | Task tracker, documentation, monitoring and error tracking, CI/CD, design files (Figma and similar) | You; an export of the history if the tool belongs to the vendor |
| Documents and contracts | The previous vendor's contract — IP and handover clauses; licences for libraries and third-party code; specification and design documents | You; code ownership written into the contract |
What to check before accepting responsibility
A new vendor who takes responsibility for a product without these checks is taking responsibility for something they don't know they can fix. Five checks, in order:
- Build from scratch. Clone the repository onto a clean machine and build the product from the documentation alone. Every step that requires "ask whoever wrote it" is a documented gap.
- Compare to production. Is the version you built identical to what users are running? If the code in production differs from the code in the repository, that is the single most important finding of the transition.
- Restore from backup. Take the latest backup and restore it into a test environment. A backup that has never been restored is an assumption, not a backup.
- Dependencies and licences. Which libraries and versions are in use, which are no longer maintained, and which licences apply. This is also where you check whether keys or passwords live inside the code.
- Existing documentation and tests. What is written, what is outdated, and which automated tests exist and pass. The absence of tests is not a reason to stop the transition — it is a reason to write them before the first change.
Planning a staged transition
A transition done in a single day is one you cannot roll back from. Instead — stages, each with an owner, one action and a stop condition: what has to happen for you to return to the previous stage rather than continue.
| Stage | Action | Owner | Stop condition |
|---|---|---|---|
| A. Read access | The new vendor gets read-only access to code, infrastructure and monitoring | You | None — this stage is safe |
| B. Acceptance checks | The five checks from the previous section; results written down | The new vendor | A gap that can't be closed without the previous vendor — stop and handle it first |
| C. Ownership transfer | Accounts and domains move into your name; passwords and keys are rotated | You, with both vendors | A service that stopped after a key rotation — restore the old key and find where it is configured |
| D. First change | A small, non-critical fix goes all the way through: code, test, deploy to production | The new vendor | The deployment fails or differs from the documented process — fix the process before the next change |
| E. Full responsibility | The previous vendor loses access; the new maintenance agreement takes effect | You | No stop — but you don't reach this stage before every row in the asset table reads 'transferred' |
How do you know the handover is complete?
A handover is complete when you can answer "yes" to each of the following — and point to the document that proves it. This is the handover record; both sides sign it.
- Every row in the asset table reads "transferred", with the new owner's name.
- The product builds from the repository on a clean environment, and the version matches production.
- A backup was restored successfully to a test environment, and the restore procedure is written down.
- At least one change has gone through the full deployment path by the new vendor.
- The previous vendor no longer has access to any asset, and every password and key they knew has been rotated.
- A written diagnosis exists: system map, ranked findings, and a recommendation for what comes next.
- A new maintenance agreement defines scope, severity levels and what is not included — in writing.
When to continue and when to upgrade
This decision is made after the handover, based on the diagnosis report — not before it. Four signals decide it:
| Signal | Points to continuing on what exists | Points to upgrading or rebuilding |
|---|---|---|
| Critical findings | Fixable locally without touching the structure | Stem from the structure itself and recur in every component |
| Dependencies | Maintained, or can be updated incrementally | The core relies on technology that is no longer updated |
| Cost of change | A small change stays small once the new team knows the code | Every change requires touching many parts and retesting everything |
| Business needs | The product does what the business needs; improvements are missing | The business has changed and the product assumes a process that no longer exists |
If your product was built with AI tools or by a team that is no longer available, and you need someone to go through this list with you — that is exactly what the diagnosis stage of our rescue and continuation service does. Rescue, takeover and continued development of an existing product
And if the diagnosis concludes that a structural change is needed — the page on upgrading existing systems describes how to plan it without breaking what works. Upgrading existing systems