Software takeover: taking back control of existing software

What is software takeover?

Taking over code means becoming responsible for software you did not write. The software is already running and supporting your business: this is not about starting from scratch, but about regaining the ability to run it, fix it and evolve it without risk. A takeover starts with access and a stocktake, continues with securing production, then moves on to changes delivered in small batches.

The term covers several services that are often confused. The table below sets them apart: a software takeover can lead to one or more of them, depending on what the audit reveals.

When should you call in a software takeover company?

The most common case: the vendor, agency or freelance developer who built the software is no longer around. The agency has closed, the freelancer no longer answers, the technical co-founder has left, or the relationship simply ended. The software still works, but no one knows how to deploy it any more, or what breaks if you touch what.

A takeover is also justified without a vendor leaving, when technical debt is paralysing the product: each change costs more than the last, the same defects keep coming back, a security update has been put off for months because it risks breaking everything. These signs justify a software takeover, not necessarily a rebuild. The first need is to separate immediate risks from irritants that can wait.

• Vendor, agency or freelancer gone, failing or unreachable
• Changes blocked by the fear of breaking production
• Defects that return after every update
• Unmaintained dependencies or versions, known security flaws left unpatched
• Backups, hosting and deployment that no one can describe
• SaaS that has become hard to evolve: code refactoring needed
• Software inherited after acquiring a company or a business
• An application built very quickly (no-code tool, AI-generated code) that needs to be made reliable

Choosing a software takeover agency: the right questions

A software takeover agency must read your code before quoting for anything. Offering to rewrite everything is the quickest answer to give, and the most expensive one to pay for. A good takeover partner tells you what they have seen, what they still do not know, and what each option costs. They should also avoid creating the very dependency you are trying to escape.

Here are the questions to ask any software takeover company, us included. Our guide Freelancer or development agency? helps you compare the two types of provider.

• Is the audit sold separately, with a fixed scope, and a report that stays yours even if you continue elsewhere?
• Does the takeover partner clearly state what they were not able to check?
• Will the resulting code sit in your repository, with accounts (hosting, domains, app stores) in your name?
• Is there a licence, an exit fee or mandatory maintenance? With us: no.
• Who reads the code and who will maintain it afterwards? The same team, ideally.
• How does the service stay available while the work is under way?

The pre-takeover code audit: what we look at

The audit examines the code and everything that makes it run. It separates what can be kept from what deserves rewriting, with the reasons why. Technical debt is broken down into batches, costed in days and ordered by risk and business value. You receive a usable plan even if you have the follow-up work done elsewhere.

An audit does not remove all uncertainty: some parts only become understandable by watching the software in use. Scoping therefore includes a day on site with users, comparing expected behaviour, real data and what the code actually does today. This comparison avoids labelling an unusual business rule a “bug”, or keeping a fault simply because it has existed for a long time.

• The repository: history, branches, what is actually in production
• Build and deployment: can the software be rebuilt and shipped today, without the former vendor?
• Dependencies: versions, abandoned components, known vulnerabilities
• Architecture: how the parts call each other, where the business rules live
• Data: database schema, quality, duplicates, volumes
• Backups: do they exist, and has a restore ever actually succeeded?
• Security: access management, passwords and technical keys, personal data
• Tests and monitoring: what warns of an outage, what guards against a regression
• Running costs: hosting, third-party services, current subscriptions

The steps of a software takeover and their timescales

A takeover always follows the same order: you do not evolve software you cannot yet redeploy. Timescales mainly depend on what you can provide at the start. The audit's duration is given before it begins, on a fixed scope; the schedule for the following work is set from what it found, batch by batch.

1. First conversation: you describe the software, how it is used and what you no longer dare to touch
2. Recovering access: repository, hosting, database, domains, third-party accounts
3. Code audit and a day on site with users, followed by a written report
4. Securing the system: backups checked with a real restore, urgent fixes, monitoring
5. Refactoring, fixes and changes in batches, each one tested and documented
6. Ongoing maintenance (TMA): long-term maintenance and changes, or handover to your team

Checklist: what to recover before the takeover

A takeover goes smoothly when these items are gathered from the start. If any are missing, recovering them becomes the first task of the stocktake, before any development. Ask the former vendor for them in writing, and check whose name each account is under: an account held in the vendor's name is a risk, even if it works today. Our guide Taking over code from a vendor sets out the steps to follow.

Refactoring a SaaS codebase: evolving without breaking everything

Code refactoring means reorganising part of the software to make it easier to evolve, without changing what users expect from it. On a SaaS, each customer's data, subscriptions and access must also be protected throughout the operation: a mistake does not affect one user, it affects all your customers at once.

We work in readable batches. Before touching any part, we put tests in place on critical journeys (login, billing, key data entry) so we know immediately if something has changed. Version upgrades happen one at a time, starting with those that expose production. Each batch is delivered, checked, then documented before the next one.

This work only has value if it addresses an identified risk or need: a part of the code that slows down every change, a dependency that is no longer maintained, a fragile process. We build and run our own SaaS, Trackary, and know these constraints from the inside. For a SaaS to be built or extended, see also B2B SaaS development.

• Sign that refactoring is worthwhile: a small change touches files everywhere
• Sign that refactoring is worthwhile: no one dares update the framework
• Sign that refactoring is worthwhile: the same calculation is coded in several places, with different results
• What it must not do: change behaviour without you having decided to

Progressive takeover or complete redesign?

Redesigning existing software does not start by switching off what still works. We first look at backups, restores, urgent fixes and monitoring, then we stabilise the incidents that genuinely hinder teams. If a rewrite is unavoidable, it is preferably done piece by piece, with a prepared switchover and a service that keeps running throughout the transition.

Rewriting everything looks simpler on a diagram, but it means rediscovering exceptions built up through real use, and shifting data and habits all at once. Conversely, keeping every old element at all costs can stall the product. The decision is made part by part across the system: keep, fix, isolate or replace.

After the takeover: ongoing maintenance and further changes

TMA (ongoing application maintenance) is the contract that follows a takeover: fixing defects, security and version updates, monitoring backups, and functional changes as needs arise. A serious maintenance contract starts with a takeover: no one should commit to fix times for software they have not read.

The maintenance scope is separate from the takeover and chosen according to your needs: nothing obliges you to take it with us. If you prefer to bring the software back in-house, the documentation produced during the takeover and a handover period with your team are part of the plan. A maintenance contract that left you dependent on a single provider would simply reproduce the problem that brought you here.

• Corrective maintenance: reported defects are analysed and fixed
• Preventive maintenance: updates, checked backups, monitoring
• Evolutive maintenance: new features, delivered in batches
• Reversibility: up-to-date documentation and a handover possible at any time

How much does a software takeover cost?

A software takeover is priced on request, after an audit. The cost depends on actual access to the code and environments, the volume of data, the state of backups, incidents to deal with and the desired scope of changes. The audit must be kept separate from the work it leads to: without a diagnosis, a redesign quote only gives a misleading impression of precision. Scoping is billed separately and its outcome is yours. Our guide How much does custom software cost? explains the pricing factors, and How much does a SaaS cost? covers the running costs of online software.

For the work we carry out, the code lands in your repository from the first commit and third-party accounts stay in your name. No licence, no exit fee, no mandatory maintenance. This freedom matters especially in a takeover: the original problem is often a dependency on a vendor that has become hard to break.

Why entrust your software takeover to The Level Code

THE LEVEL CODE is a software development studio based in Lille (The Level Code SASU, chaired by Romain Nivelle). We build business software, web and mobile applications and SaaS products, and we run our own software in production, Trackary. For us, taking over software means applying to your code the same standards we apply to our own: backups actually restored, repeatable deployments, history kept intact.

We work in Lille, across the Lille metropolitan area and throughout France: the scoping day takes place on site, the audit and the work itself remotely. If the code cannot be recovered or its technology falls outside our skills, we tell you at the audit stage, not in month three. For the detail of how we work, see the Method page.