A business-critical application doesn’t usually stop working the day its developer stops answering emails. It carries on, quietly, until the first thing breaks – and then nobody knows who to call.
This happens more often than people expect. Agencies close, contractors move on to full-time roles, in-house developers leave, and the application they left behind keeps running the business. If that’s where you are, here’s what’s actually worth doing, roughly in order.
Work Out What You Actually Own
Before anything technical, establish what's in your name and what isn't. The source code, the hosting account, the domain registration, the database, any third-party services the application depends on – each of those sits in somebody's account somewhere.
This catches people out badly. It's common to find the domain registered to a former developer's personal account, or the server billed to an agency card. None of that is necessarily a problem, but it's a problem you want to find now rather than during an outage.
Tip: Make a list of every login involved in keeping the application running, and note who controls each one. The gaps in that list are usually the first thing worth chasing.
Find Out Where It Runs and What It's Built On
You don't need to understand the technology yourself. But somebody needs to establish what the application is written in, where it's hosted, how it gets deployed and what it connects to, because that determines who can sensibly work on it.
If the original developer is still contactable, even briefly, this is the single most valuable thing to get from them. A half-hour conversation about how the thing is put together saves considerably more time later than the same half-hour spent on anything else.
Tip: If you can get one document out of a departing developer, ask for the deployment steps – how a change actually gets from their machine to the live application. It's the detail most often lost and the hardest to reconstruct.
Separate What's Urgent From What's Just Untidy
When you inherit an application, everything about it can feel precarious. It usually isn't. There's normally a short list of things genuinely causing harm right now, and a much longer list of things that are simply not ideal.
Those need treating differently. A payment integration silently failing is today's problem. A framework two major versions behind is a real risk, but it's a planning problem, not an emergency – and conflating the two tends to produce panicked decisions.
Tip: Write down the problems in terms of who they affect and how often, not in technical terms. It makes the genuine priorities obvious to everyone, including whoever you bring in.
Be Wary of "We'll Just Rebuild It"
A developer looking at somebody else's code will often suggest starting again. Sometimes that's the right call. Frequently it reflects the fact that reading unfamiliar code is harder and less enjoyable than writing new code.
A rebuild also throws away something valuable that isn't in the codebase: years of small corrections for edge cases that only turned up in real use. That knowledge is embedded in the application you already have, and it rarely survives a rewrite intact.
Tip: If someone recommends a rebuild before they've properly reviewed what exists, ask what specifically can't be fixed in the current application. A good answer will be concrete.
Decide What Kind of Arrangement You Need
There's a difference between wanting one problem fixed and wanting somebody to be responsible for the application from now on. Both are reasonable, but they lead to different conversations and different kinds of working relationship.
It's worth being honest with yourself about which one you're after. Applications that businesses genuinely depend on tend to need someone keeping an eye on them, not just someone to ring when something falls over.
Tip: Ask prospective developers who would actually do the work. With a small application, talking directly to the developer working on it makes a noticeable difference to how quickly things get understood.
Final Thoughts
That’s a fair amount to take on, and if you’re reading this because it has just happened to you, almost none of it is really your job. You run a business that happens to depend on an application. Chasing down who owns the hosting account, or working out how a deployment happens, is not what your week should be going on.
So hand it over. When we take over an existing application, every step above becomes ours to carry out: establishing what exists and who controls it, working out how the application is built, hosted and deployed, and separating the problems that need attention this week from the ones that can be planned properly. You don’t have to arrive with any of it worked out.
You also get a straight answer on the repair-or-replace question – after we have looked at the application, not before. Where the foundations are sound we say so; where they aren’t, our legacy application upgrade approach sets out how we weigh improving what’s there against replacing it. Once the immediate work is done, ongoing support means somebody is watching the application from then on, so you are not back here in two years’ time.
You don’t need to know what your application is built on before getting in touch, and you won’t be handed to an account manager to find out. You’ll be talking to the senior developer who would actually do the work. Tell us what the application does and what’s going wrong – we’ll take it from there.
Page last updated: 14th September 2026
Inherited an applicationand no one to run it?
Tell us what the application does and what’s going wrong. We’ll talk through a sensible first step, whether that’s one fix or taking the whole thing on.
No need to know every technical detail before getting in touch.
Discuss your existing applicationFree, no-obligation conversation to start.
Tell us what you know.
- What the application does today
- Where it is causing problems
- What you need it to do next
We can work out the technical starting point together.