GUIDE · MAINTENANCE · SWITCHING VENDORS
Moving to a new development vendor: what to receive, verify and hand over
The checklist that prevents "we don't have access to that" two months after the switch.
Onezero LabsUpdated 11 min read
| Stage | What you do | What you have at the end |
|---|---|---|
| 1. Inventory | List every asset, its registered owner and who holds access | An asset table with a status on every row |
| 2. Verification | Build from the code on a clean environment, restore from backup, compare to production | A list of gaps between what runs and what you hold |
| 3. Ownership transfer | Move accounts and domains into your name and rotate passwords | No asset depends on the previous vendor |
| 4. Staged transition | Define the order of operations, an owner per stage and stop conditions | A written plan you can roll back from |
| 5. Acceptance | Check against acceptance conditions defined up front and document | A signed handover record and a diagnosis for the next decision |
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 organization, 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; licenses 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 licenses. Which libraries and versions are in use, which are no longer maintained, and which licenses 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 productAnd 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 systemsFAQ
Frequently asked questions
Usually yes, if the assets are registered in your name — code, cloud accounts, domain and stores. If some are registered to the previous vendor, the transition starts with ownership transfer, and sometimes that requires invoking the contract. That is why the first column of the asset table is always "whose name is it in".
Start from the code and infrastructure themselves: a clean build, mapping the services the system calls, and reading the repository history. The first documentation is written during the transition — it is one of the diagnosis deliverables, not a precondition for it.
Not necessarily, but no one can promise in advance that there will be no disruption — it depends on the product and on what the checks uncover. What you can do: plan every stage so it can be rolled back, and make sensitive changes (key rotation, domain transfer) at an agreed time with a rollback plan.
There is no number that is right for every product. The duration depends on the number of assets, the previous vendor's availability and what the clean build and backup restore uncover. What can be fixed in advance is the order of stages and the conditions for moving between them — not the date.
No. Commitments to response times and availability belong in the maintenance agreement that takes effect after the handover, once the vendor knows the system and knows what they are committing to. During the transition you define an owner per stage and stop conditions — that is the relevant commitment.
Keep reading
- ServiceVibe Coding RescueAI-generated code that doesn't work? We step in, fix it, ship it.
- ServiceLegacy System UpgradesFrom old PHP, jQuery, or VB – to modern, without breaking everything.
- GuideWhat does app maintenance include, and how do you budget for it?Launch is not the end of the spend — it is the start of a different one. This guide breaks it into four types and explains what exactly a maintenance agreement buys.
Let's talk
Got a project to scope?
One conversation. You leave knowing what the first version needs to contain and what it will take to build it.
Straight. To the point. On time.