Taking over software from another agency: a checklist
Taking over software from another agency or freelancer: accounts, source code, documentation, your contract position, the first review and fix vs rewrite.
Taking over software from another agency or freelancer starts with what you hold, not with the code: the accounts, the repository, the data and the documents. Only once those are in your name does a review make sense, and only after the review should anyone decide whether to fix or rewrite. For the owner whose developer has left, gone quiet or become too expensive.
Quick answer
- Secure the accounts first: domain, hosting, repository, app stores, payment and e-mail services.
- Get the source code with its full history, not a zip file.
- Collect whatever documentation exists and write down what is missing.
- Reread what your contract says about rights and handover.
- Commission a fixed-scope review before any new feature.
- Decide fix, upgrade or rewrite on written findings, not on the new team’s taste.
1. Access and accounts: the first week
Accounts outlive relationships. List every one the system depends on and who holds it today.
| What | Where it usually sits | What to do |
|---|---|---|
| Domain | Registrar account, sometimes in the developer’s name | Check the holder, move it to the company |
| Hosting or cloud | The developer’s account, paid by your card or theirs | Move to a company account, then add the new team |
| Repository | The developer’s personal GitHub, GitLab or Bitbucket | Transfer to a company organisation, with history |
| App Store and Google Play | Whoever published the app | Use the stores’ official app transfer |
| Payment, e-mail, maps, analytics | API keys scattered in the code | List every key, rotate them after the handover |
| Passwords | E-mail threads, a text file | Move them into a company password manager |
Two details catch Croatian companies out. For a .hr domain, CARNET allows a change of domain holder only with proof of legal succession, such as a merger or an inheritance decision. Without it, a free .hr domain has to be deleted and registered again for the new holder, and a holder change on a paid domain is charged by the registrar. If the domain that runs your shop was registered to the freelancer, plan that step carefully.
Mobile apps move between developer accounts through Apple’s and Google’s own transfer procedures, keeping their users and reviews. Apple states that the code itself has to be handed over separately by the previous owner.
While the previous supplier still answers, send everything you need as one written list with a date.
2. Source code and repository
Ask for the repository with its full commit history, transferred to your organisation, not an archive sent by e-mail. The history is often the only documentation there is.
Then check that the code in the repository is the code running in production: deploy it to an empty server. If it does not build, you do not have the code yet. Ask also for database access, a recent backup, the environment settings stored outside the code, and any scheduled jobs that run on the server.
3. Documentation: write down what is missing
Four things matter: how a new version is deployed, where the keys live, which outside services the system talks to, and what runs on a schedule. Whatever the previous team cannot provide becomes the first task of the review, so the system never again depends on one person.
4. Your contract position
Whether another company may modify the code depends on what your contract says about the transfer of rights. We cover that in who owns the custom software you paid for; reread your contract against it before you switch. If the system holds personal data, the new supplier also needs a written data processing agreement - see GDPR and custom software.
Note: this article is informational and is not legal advice. For a dispute with a previous supplier or unclear rights, talk to a lawyer.
5. The review: findings before features
Before anything new is built, commission a fixed-scope review with a written result: what the system is made of, the state of the code, outdated libraries, exposed keys, whether backups exist and actually restore, and how hard further development will be. Urgent risks are fixed first.
That is how our software takeover works: a free first call, a fixed-scope review agreed in writing, accounts moved into your name, stabilisation, and only then new work.
6. Fix, upgrade or rewrite
A rewrite feels clean and is almost always the most expensive option, because the old system has to keep running until the new one is ready.
- Fix and keep developing when the code is understandable and its framework is still supported.
- Rewrite one piece at a time when one module causes most of the failures.
- Rewrite fully only when fixing would cost more over the next few years than building again.
The longer version of that decision is in legacy software: migrate or build new. Sometimes the previous supplier was fine and the scope was the problem; a fair review says so.
Once the system is stable, someone has to own it month to month: updates, backups, fixes, small changes. That is our monthly maintenance and development partnership, or hourly work if changes are rare.
Frequently Asked Questions
Can we take over software if the previous developer will not cooperate? Partly. Accounts you pay for can usually be recovered through the providers’ official procedures; code that exists only on their laptop cannot.
How long does a takeover take? Moving accounts takes days to a few weeks, depending on the providers; the review has a date agreed before it starts.
Should we tell the previous agency we are leaving? Yes, in writing, with the list of what you need and a deadline. Most handovers go smoothly when the request is clear.
What if we have no source code at all? Then the review assesses what can be rebuilt from the running system and its data.
Related Articles
- Who owns the custom software you paid for?
- Freelancer or small team for custom software development?
- Hosting and running costs after a custom application build
Has your developer left you on your own?
Tell us what you have and what worries you. The first call is free, and the review is agreed in writing before we start.
Reach out at [email protected] or via the form on our homepage.