Taking over an application that nobody maintains any more
Your team no longer has time, your developer has left, your provider no longer answers? Here is how to take back control.
A legacy application takeover means taking charge of an application nobody maintains any more: recovering the access, the code and the hosting, and putting them back in your name. It happens in three steps: scope, with a health check in two weeks; stabilize, by first fixing what pays back the most; rebuild, only when it becomes the cheapest option.
The signs
Six questions. If any of them has no answer, your application still runs, but nobody is really looking after it.
-
The key person
If the person who knows your tool leaves tomorrow, who fixes it, and how long does it take?
-
Re-keying
How many hours a week does your team spend copying data between your tool and everything else?
-
Lost requests
Out of a hundred requests that come in through your website, how many actually reach someone who handles them?
-
The last outage
The last time the tool crashed, who did you call, and how long did it last?
-
The missing code
Nobody knows where the code is. If you had to hand it to another developer tomorrow, who would know what to send?
-
Hosting that is not yours
The hosting is in the previous provider's name. What happens the day they stop paying the bill?
To take stock in ten questions, with your score straight away: the self‑assessment.
Your team is still there, but no longer has time for it? Your provider has stopped answering? Find your situation.
What a takeover covers
Taking over an application is not just reading its code. It means recovering everything that keeps it running, and putting it back in your name.
-
Access
The administrator accounts for the application, the server, the database and third-party services: who holds them, and who can still use them.
-
Source code
The complete code, in the version actually running in production, kept in a repository your company can access.
-
Hosting
The server or cloud service, with its account and its bill: in whose name, paid by whom, and what happens if the payments stop.
-
Domain names
The domain behind your website and your e‑mail: which registrar, in whose name, and when it is due for renewal.
-
Documentation
How the tool is installed, backed up and updated. Often none of it is written down: this is the moment to write it.
-
Security
Overdue updates, shared passwords, former staff accounts still active, backups that have never been tested.
Secure it this week
Most of these points take a few e‑mails, not a developer. They protect you whether or not you ever work with us.
- Administrator access. List every account: the application, the server, the database, e‑mail, third-party services. For each one, note who holds it. Every critical login should be known to at least two people in your company and kept in a shared password manager.
- Old accounts. Close the accounts of people who no longer work on the tool, starting with their personal logins. Passwords the application itself uses should be changed with someone who knows where they are configured, or the tool goes down.
- Source code. Ask where it lives (GitLab, GitHub, Bitbucket, the server, someone's laptop) and get access in your company's name. Check that it is the version actually running in production.
- Hosting. Who pays for the server, whose name is on the account, which card is charged? If it is in someone else's name, ask for administrator access at the very least, then for the account to be transferred.
- Domain name. Find the registrar, the registrant and the renewal date. The registrant should be your company. Put the date in your calendar a month ahead: an expired domain takes down the website and, often, the e‑mail. Note too who manages the DNS, the settings that point the website and the e‑mail to the right server.
- Backups. Do they exist, where are they stored, and when did anyone last try to restore one? A backup that has never been restored is a hope, not a backup. Keep a recent copy outside the hosting.
- Licences and subscriptions. Software licences, APIs, e‑mail sending, certificates: list what the tool depends on, who pays for it and in whose name. A subscription paid by someone else stops when they do.
- Mobile apps. The code and the App Store and Google Play developer accounts should be in your company's name, not a developer's.
- The contract. Find the contract, the signed quotes and the terms and conditions: who owns the code, and what was agreed for the end of the collaboration. If in doubt, ask a lawyer.
- One page. Put all of this on a single page, kept where someone other than you will find it.
Some boxes still empty? That is where a health check starts: we recover what is missing before touching anything.
How we take over
The three-step takeover: scope, stabilize, rebuild. Never blind, and never the rebuild first.
-
Scope
In two weeks, a health check of your tool: what it costs you, what will break first, what you can save.
The health check -
Stabilize
We first fix what pays back the most, at a fixed price, then we keep the tool alive.
Stabilize
First, the health check
Everything starts with the health check, in two weeks: one hour with management, one hour with the people who use the tool every day, and a reading of the code and the hosting. No source code? That is where we start: recovering it is part of the health check.
You receive a written report: what the tool costs you, what will break first, what you can save, and what happens if nothing changes in 12 months. It ends with three priced proposals: the urgent fix, the pay-back module, and the rebuild, estimated but not proposed.
And the previous provider?
Someone to work with, not someone to blame.
Whoever built the tool knows things no code will tell you: why a choice was made, which server does what, which job runs at night. If they left, it was usually for ordinary reasons: another job, another client, retirement, an account that became too small for their firm.
Whenever we can, we work with them. A short handover, prepared with precise questions, saves days of digging. And a courteous request gets further than a reproach: the access, the code, a backup, a little time to answer questions. Offering to pay for that time often helps.
No answer at all? Read what to do when your IT provider no longer answers.
Which situation is yours?
-
Your team no longer has time to maintain your tools, or your developer has left
Your team has no time left for the existing tools, or the person who knew them has left.
-
Your IT provider no longer answers
Your e‑mails go unanswered, and the application still runs.
-
Your application runs on outdated technology
No more security updates, and nobody wants to touch it.
-
An application built with AI that nobody understands any more
It was built quickly, and nobody knows how to change it.
Frequently asked questions
How long does an application takeover take?
The first step, the health check, takes two weeks. What follows depends on what it shows and on what you decide: nothing is compulsory after the health check, and every step is priced before it starts.
Our previous provider refuses to hand over the code. What can we do?
Do not cancel the hosting or the contract before you have the code, the data and the access. Send a written, precise request with a date, and keep a record; if nothing moves, a lawyer can tell you what your contract provides for. The health check then works from what you already have: your access, the server, the database, whatever is left of the code. The details: your IT provider no longer answers.
Do we have to rewrite everything to take over an application?
Not necessarily, and never first. We first fix what pays back the most, then we keep the tool alive: that is the second step, stabilize. A rebuild only comes the day keeping the tool alive costs more than replacing it.
How much does an application takeover cost?
The health check costs under €3,000 excl. VAT, a fixed price announced after a first 20-minute conversation. Each step after it also has its own fixed price, announced before we start. You then decide with the prices in front of you.