Working together · 8 min read

Taking over a software project from another agency, without a rewrite

Published 23 October 2026 · By Sam Fourie, Niddo

You can move a live product to a new team without rewriting it, and usually you should. Secure the code, the accounts and the data in your own name first. Then have the new team reproduce the system and audit it on a copy of production before it changes anything. Fix what is dangerous, then what is slow, then start building again, each step a fixed-price phase you approve on its own.

Signs it is time to switch

Releases slip and nobody can say why, or by how much.
Every change breaks something unrelated, so small requests take weeks.
The people who built it have left, and the current team is learning the system on your invoices.
Nobody can run the product on a laptop; every fix is made and tested on the live server.
The framework or language version has reached end of life and security updates have stopped.
Invoices grow while the product does not, and you cannot see what the hours bought.

One of these is a conversation with your current team. Three or more, for more than a quarter, is usually a structural problem, and a new team with a clear method is cheaper than another year of it.

Secure these before you say anything

The takeover is only as safe as your control of the assets. Check each of these while the relationship is still cordial, and move anything that is not in your name:

The source code: owner access to the repository (GitHub, GitLab or Bitbucket) in your organisation's account, with the full history, not a zip file.
Hosting and cloud accounts (AWS, Vercel, Google Cloud, a VPS provider) in your company's name, with you as owner and on the billing.
The domain, the DNS and the email-sending setup, in a registrar account you control.
The database: a recent backup you can open yourself, and confirmation that backups run.
Every third-party service the product depends on: payments, email delivery, maps, analytics, identity checks, app-store accounts. Owner access, not a shared login.
Secrets and environment variables, handed over through a password manager, never by email or chat.
Your contract. Most agreements assign the intellectual property to you on payment, but read the clause, because a few do not, and it is far easier to settle before the relationship ends.

If the repository or the hosting sits in the agency's account, that is the first thing to fix, whatever else you decide. Ownership is what makes every other option possible.

How a good takeover runs

Phase	What happens	What you get
1. Reproduce	The new team gets the system running on a laptop, against a copy of the production database, with email and payments safely sandboxed.	Proof that the product can be rebuilt from what you own, and a list of what was missing
2. Audit	Every slow page, error source, dependency and risk measured on real data, not guessed.	A written audit with numbers, ranked by risk and by user impact
3. Stabilise	Small, low-risk fixes with an immediate effect: server limits, missing indexes, the errors that flood the log, exposed tooling.	Fewer incidents and a calmer system, usually within weeks
4. Improve	The slow pages rebuilt and the changes users have been waiting for, released to a test environment for approval first.	Visible progress, phase by phase
5. Run	Monitoring, updates and a steady release rhythm.	A product you can plan around again

The order matters. A new team that starts adding features before it can reproduce and measure the system is guessing, and a team that proposes a rewrite before it has read the code is selling you its preferred stack.

What the audit should tell you

Whether the system can be rebuilt from the repository alone, or whether parts of it (the database schema, configuration, scheduled jobs) exist only on the server.
Page by page performance: database queries per request, bytes sent to the browser, response times under realistic data.
Where the errors come from, how often, and what they cost users.
Security exposure, ranked and reported to you privately rather than in a public ticket.
The age of the framework, language and dependencies, and the upgrade path for each.
Test coverage, deployment process and backups, as they really are.
What users have been asking for, and what each request would take.

Rewrite or keep it?

Keep it, most of the time. A product that works for its users holds years of fixed edge cases and business rules that nobody wrote down, and a rewrite has to rediscover every one of them while the old system keeps running and keeps needing fixes. Rewrites also stop visible progress for months, which is the opposite of what a takeover is for.

Keep and improve when	Consider a rewrite when
The product does its job and users know it	The platform is dead with no realistic upgrade path and real security exposure
The data model is broadly sound, even if the queries are not	The data model is wrong for where the business is going, not just slow
Upgrades can happen in steps	The system is small enough that rebuilding it is cheaper than understanding it
You need progress this quarter	You can afford months without visible change

Even when a rewrite is right, it usually happens piece by piece behind the running system rather than as one big switch-over.

A worked example: KlarOK

KlarOK is the compliance platform Swedish car workshops use to reach Godkänd Bilverkstad certification. It was built by other teams from 2019 and had changed hands before we took it over in 2026. The audit found 210 database tables with a single migration in the repository, because the schema existed only on the production server; 870 database queries on the busiest page and 615 on the dashboard; a server that handled five page requests at a time; hundreds of errors a day, nearly all from one function; and no local environment or test suite.

We reproduced it first, on a laptop with a copy of production, then measured every slow page down to the query. The findings became four fixed-price phases the client approves one at a time: stabilise, deliver the changes users had been waiting for, rebuild the slow pages (acceptance test: the busiest pages under two seconds with fewer than fifty queries), then add view profiles. Nothing is being rewritten, and nobody has to relearn the product they use every day. It runs on Laravel and PHP, which is not our default stack; keeping it was cheaper for the client than replacing it.

What a takeover costs

Price the first step on its own. Reproducing and auditing a typical product is one to three weeks of work and should be quoted as one fixed figure, with the audit document yours to keep whoever does the rest. Every phase after that is priced from what the audit found, so you are never committing to a number for work nobody has measured. Be wary of a team that quotes a full takeover, or a rewrite, before it has seen the code running.

Handing over from the old agency

Ask for a handover call and written notes: how deployment works, what runs on a schedule, which integrations exist and who to call about each.
Agree a short overlap, paid if necessary, so questions in the first weeks get answered.
Transfer credentials through a password manager, then rotate them once the new team has access.
Keep it professional. You may need the previous team's memory, and the market is small.

How Niddo takes over

We start with a fixed-price reproduction and audit, show you the numbers, and propose phases you can approve, reorder or postpone. We keep your stack unless the audit gives a strong reason not to, and we work while the product stays live. If you are thinking about moving a product, tell us what you have and we will tell you honestly whether it should move at all.

Questions