The scenario this article is for
You're reading this for one of three reasons. Your software vendor stopped answering the phone last week and you're trying to work out how bad the situation is. Or the vendor is still there, but a single retirement or resignation away from leaving you stranded. Or you've seen this happen to another business in your industry and you don't want to be next.
The pattern is more common than people realise. A small development firm builds a custom system in the late 1990s or early 2000s. It runs your operation — orders, billing, accreditation, scheduling, inventory, something fundamental — for fifteen or twenty years. Then the principal developer retires, dies, sells out to a larger firm that drops the product, or simply closes shop without warning. The software keeps running, because software does. But no one is left who understands it. The first time something breaks, you discover that "no one knows how to fix it anymore" is not a phrase, it is a financial exposure.
This article is the playbook. It assumes you are non-technical, or technical-adjacent but not a software developer yourself. The audience is the business owner, the operations director, the CFO who is now responsible for a piece of software they did not commission. Everything below describes what to do, in plain English, without prejudging whether your software needs to be repaired, modernised, or replaced.
If you are already in the middle of this and you want a written second opinion, book a free 30-minute consultation. Within that call, we will tell you which of the four states described in Section 3 you are actually in, and what your real options are. The conversation is free and produces no obligation.
1. The first 48 hours: incident triage before anyone writes code
The first 48 hours after you realise your vendor is gone determine how much of your operation you keep. Before anyone touches the code, three things have to happen.
Stop authorising changes you cannot reverse. Every push to production, every database script, every configuration tweak from this point onwards has to be logged in writing. If your former vendor still has access to your servers — and many do, because no one ever revoked it — revoke it the same day you discover the situation, not the same week. Change the production database password. Rotate any API keys you can find. Move source-control read access to someone you trust inside the business. If you don't know where source control lives, finding that becomes the first concrete action.
Inventory what you can still reach. Make a one-page list: production servers, staging servers, the source-control repository, the database, the build server, the deployment pipeline, the third-party services your software calls (payment, email, accreditation registers, etc.), the domain registrar account, the SSL certificate. Mark each one with two flags — "I can log in to this myself" and "Only the former vendor could log in." The gaps in column two are your real exposure. Some of those gaps are recoverable through password resets to addresses you control; others require contacting the vendor's hosting provider or registrar with proof of ownership. Either way, document the list. You will need it for the assessment that follows.
Freeze the change window. Tell every internal stakeholder: no new feature requests until further notice. The temptation, once you find a new developer, is to use them to ship the backlog the old vendor never finished. That instinct is wrong. The first job is stabilisation; the second is documentation; only the third is new work. Skip the first two and you will be looking for a new developer again inside six months.
If you are reading this on day one, those three checks are what you do today. They are deliberately non-technical — anyone can do them with help from an IT generalist. The technical assessment comes next.
2. The myth of the urgent rewrite
Before going further, address the question you have already been asked, or are about to be asked, by every developer you contact in week two: "Do you want us to just rewrite it from scratch?"
The honest answer is almost always no.
A rewrite, on paper, is attractive. The old system is opaque, no one understands it, the original developers are gone — let's replace it with something modern that we control. In practice, full rewrites of operational legacy software fail at a striking rate. They take two to three times longer than estimated. They cost what was budgeted plus the cost of the old system continuing to run during the transition. And they miss business logic — small rules, edge cases, exception handling — that was encoded in the old system over years of customer feedback and corner-case handling. Logic that no one wrote down, and that the new developers never fully understood because no one ever told them it existed.
The pattern we see, in case after case, is that 80–90% of a legacy codebase is working. It may be ugly, old, hard to read, but it is doing its job. The actual problem is concentrated in a smaller part — the part that is slow, or insecure, or impossible to extend, or breaking right now. A surgical rescue identifies that 10–20% and replaces only that, leaving the working 80–90% alone.
This is the difference between rescue and rewrite. A rescue is faster, cheaper, and lower-risk. A rewrite is the option of last resort, reserved for codebases that are genuinely beyond repair. The Mighty Advancement Legacy System Rescue service is built specifically around this distinction.
In week two, when someone tells you "you really should just start over," ask them how they reached that conclusion without having read your codebase. The honest answer is they haven't.
3. Code archaeology: how to tell what you actually have
A surprising number of business owners discover, days into a vendor disappearance, that they own the running software but not the source code. Sometimes the source-control repository was hosted under the vendor's account. Sometimes it never existed — the vendor edited files directly on the production server. Sometimes a repository exists but is months out of date and the live binaries don't match anything in it. These are not unusual situations. They are the default state of a fifteen-year-old codebase that no one has reviewed.
Before you commission any rescue work, find out which of these four states you are in:
State 1 — You have source code that matches production. This is the best case. A new developer can read it, fix bugs in it, and modernise it from this baseline. The work is straightforward, the cost is predictable, and the timeline is short.
State 2 — You have source code that no longer matches production. Common when the vendor patched live code without committing the change. Recoverable, but the new developer's first job is reconciling the two — usually by decompiling the production binaries and diffing them against the repository. The work takes longer than State 1 and slightly increases the risk of regressions, but it is fully recoverable.
State 3 — You have running production binaries and no source code. Recoverable for most stacks. .NET assemblies, Java JARs, and most Windows desktop applications can be decompiled to a reasonable approximation of their original source. The result is uglier than written-by-hand code, but it works as a starting point. FoxPro and Classic ASP are even more straightforward because they're text files on the server — there's nothing to decompile, you just need access to the production filesystem.
State 4 — You have neither source nor running production. This is the worst case, and it happens less often than business owners fear. If it does, focus on data recovery first (the database is usually intact), and treat the application layer as a rewrite — but a rewrite informed by your live data and your existing users' workflows, not by a blank specification document.
A good rescue engagement begins with a written report telling you precisely which of those four states you're in, with evidence. If a prospective new developer wants to start building before answering that question, get a second opinion.
4. How to interview a replacement developer or agency
The same patterns that produced your last vendor will, given the chance, produce your next one. Replacing a single disappeared developer with another single developer just resets the clock on the same risk. Replacing them with a generalist agency that won't read your existing code resets the clock and adds a $200,000 rewrite quote on top. The questions below are the ones that filter for someone who will actually solve your problem, not someone who will sell you a different one.
Ask: "Will you read the existing code before recommending anything?" The honest answer is yes, it will take days, and they will give you a written report at the end. Anyone who tells you they can quote the work from a 30-minute call has not understood the situation. If your codebase is in a stack they say they "don't touch any more" — FoxPro, VB6, Classic ASP, ASMX, WebForms, WinForms — find someone who still does. The "don't touch any more" answer almost always means they intend to recommend rewriting, regardless of whether that's the right answer for you.
Ask: "What's the smallest thing you could fix in our system in the first two weeks?" A real rescue specialist can name something concrete after spending a couple of days reading the code — a security hole, a slow page, a broken report, a failing scheduled job. A generalist who plans to rewrite will say it depends on the scope of the rewrite. The first answer means they're prepared to work inside what you have. The second means they're not.
Ask: "What does your handover look like?" If the answer is "we'll just keep maintaining it," walk. The whole problem you're solving is that you became dependent on a single vendor. Your replacement vendor needs to write things down — architecture documents, deployment runbooks, a list of every external integration with credentials and contact details — and they need to train someone on your side, even if that someone is you. Otherwise you are buying the same vendor-lock-in product, painted a different colour.
Ask: "What happens if you disappear?" A serious answer addresses two things: where the documentation lives (in your repository, not theirs), and what your transition path is to a third firm. If the question makes them uncomfortable, that is the answer.
Use those four questions on every vendor you talk to. The right one will answer all four directly, in concrete terms, without flinching. The wrong ones will pivot to talking about their proprietary platform, their accelerator, or how everything will be fine once you sign.
5. The technologies that get abandoned, and why they shouldn't scare you
If your software is built on any of the following, you have probably been told it is "too old to support":
- .NET Framework (any version, 1.x through 4.8), including ASP.NET WebForms, ASMX web services, and older Web API patterns
- Classic ASP (ASP 3.0) with VBScript or JScript, usually on IIS
- VB6 desktop applications, often connected to Access or SQL Server via ADO
- FoxPro and Visual FoxPro — DBF tables, CDX indexes, FPT memos
- Microsoft Access with complex VBA macros, linked tables, legacy report formats
- dBase and Clipper systems with DBF-based data stores
None of these are dead. They are out of fashion, which is a different thing. The cost of working on them is finding someone who still reads the language fluently — and that population is smaller every year, which is precisely why the developers who do are worth talking to. They are also why the rescue-vs-rewrite math is what it is. A FoxPro system that has run a manufacturing business for 22 years is not improved by being thrown away. It is improved by being read, documented, and selectively modernised. The same is true of VB6, of Classic ASP, of WebForms.
If your stack is on the list above, the answer is not "you have to migrate to something new because no one supports the old thing anymore." The answer is "find people who still do." Mighty Advancement is one of them; there are others. The technical assessment in Section 7 is built around the stacks above.
6. Worked example: a healthcare accreditation rescue
The scenario this article describes — vendor dissolves, no handover, mission-critical software left running with no one who understands it — is not hypothetical. We saw it in 2025 at a healthcare accreditation and verification organisation whose entire development firm disappeared overnight, with no documentation transfer.
Within weeks, the consequences were concrete. Accreditation application workflows had stopped processing correctly. Certificate generation was producing documents that regulators rejected. A document-management integration was failing silently — the system appeared to be working, but nothing was being saved. Regulatory penalties were on the table. Medical providers who needed this body's verification to continue practising had renewals stalled.
The rescue followed the pattern in this article. We spent the first two days reading the codebase — ASP.NET WebForms in front, SQL Server in back, with a jQuery-heavy UI and SQL Server Reporting Services for the certificates. We documented what we found, then triaged: the certificate-generation defect first because it had compliance consequences, then the silent integration failure, then the application workflow. We did not propose a rewrite. There was nothing wrong with the architecture that warranted one — the system was running, it had been running, and the failures were concentrated in specific code paths that needed reading, not replacing.
The outcome: 1,000 staff work-hours recovered (the time the team had been spending on manual workarounds), every pending accreditation closed, regulatory penalties avoided. The system is still on its original stack. What changed is that it now has documentation, a written runbook, and a maintenance plan that does not depend on any single person.
The full account is here: Medical Accreditation System Rescue.
The reason we include this case in detail is that it is a textbook example of why the rescue-first approach beats the rewrite-first instinct. A full ASP.NET WebForms rewrite, on the timeline an agency would have proposed, would not have completed in time to save the pending accreditations. The clients of the accreditation body would not have survived the wait. Rescuing what existed — reading it, fixing what was broken, documenting the rest — was what was achievable inside the window that actually mattered.
7. What a real technical assessment looks like
If you take one thing from this article: the way to get out of the vendor-disappearance situation is not to hire the first developer who calls back, and it is not to commission a rewrite. It is to get a written technical assessment of your system from someone who has read the code.
A real assessment runs two to three days and produces a written report. The report covers:
- Current state — what your system is built on, what state the source code is in (one of the four in Section 3), what's running, what's broken, what's at risk
- Priority list — what to fix first, why, and approximately how long each fix will take
- Rescue vs. rewrite recommendation — for each component, an honest call on whether to repair or replace, with the reasoning shown
- Effort and cost estimates — realistic numbers, not optimistic ones
- Handover plan — what gets documented, who gets trained, and what your dependency on the rescue vendor looks like in six and twelve months
The report has standalone value. If you decide not to proceed with the firm that produced it, you keep the report. Most of our clients have never had a clear written picture of their own system before this point. That alone often pays for the engagement.
Book a free 30-minute consultation if you'd like to start with a call rather than a paid engagement. We use that call to understand whether your situation needs a rescue, a modernisation, an emergency intervention, or something else entirely. The call is free, produces no obligation, and you walk away with a clearer picture either way.
8. What good looks like 90 days later
It is worth describing the destination, not just the steps.
Ninety days after a successful rescue, the situation looks like this. The software still runs — and now you have the source code, in a repository you control, with a written architecture document explaining what each part does. The handful of critical bugs that prompted the rescue are fixed. There is a runbook describing how to deploy a change, how to restore from backup, and who to contact if things go wrong. Someone on your side has been trained, or at minimum given a reading list, so you are not entirely dependent on the rescue firm. And there is a written list of the medium-priority work that wasn't done in the first sprint — a backlog of "useful but not urgent" items you can tackle in a second engagement, in-house, or with a different firm.
You are not vendor-locked. You can call a third-party developer in a year's time, hand them the documentation, and have them productive in days, not weeks. You have a clear-eyed view of what your system is worth and how much it would cost to modernise further if you ever want to.
That is the realistic destination of a competent rescue engagement. It is not glamorous. It does not involve a rewrite, a new platform, or anyone telling you how innovative they are. It involves reading, documenting, repairing, and handing over — work that less than half the development industry will agree to do, and that is the reason a relatively small number of firms specialise in this kind of engagement.
If your situation matches anything in this article — or you suspect it might soon — the next step is the same regardless of severity: book a free 30-minute consultation. On the call, we will listen first, then tell you what we think you actually need. The conversation is free. The clarity you walk away with is worth the half-hour.