In short
- First secure access: code, servers, domains, databases, app store and service accounts.
- A code and architecture review shows the risks before the new team starts changing the system.
- Take over gradually: maintenance and small fixes first, new features later.
- Missing documentation is common - it is rebuilt during the takeover.
- Do not start by rewriting everything from scratch - it is rarely the cheapest route.
Step 1: secure access
Before changing anything, make sure you have:
- the source code in the version running in production, with its change history,
- admin access to servers, databases and backups,
- domains and certificates,
- app store and third-party service accounts (payments, email, SMS, maps),
- passwords and keys handed over securely, then changed.
Step 2: code and architecture review
The new team should first understand what it is taking over: how the system is built, the state of the code, the dependencies and their versions, whether there are tests and how deployment works. The review produces a list of risks and a plan of what to fix first.
Step 3: take over gradually
- Maintenance: the new team learns the system through tickets and small fixes.
- Clean-up: dependency updates, automated deployment, basic tests in the riskiest places.
- Development: new features once the team knows the system and has safeguards against regressions.
The product keeps running throughout - users should notice the vendor change only through faster responses.
Rewrite from scratch or keep developing?
Rewriting from scratch is tempting when the code is in poor shape, but it is rarely the cheapest route: all the rules and exceptions added over the years have to be rebuilt, while the old system still needs maintaining. It is usually better to replace parts gradually, starting with the most problematic ones.
How to avoid this in the future
A repository on the company's account, admin access on your side, copyright settled in the contract and documentation updated during the project. Then changing vendors is a matter of organisation, not of rescuing the system.