Assessment checklist ~10 min read By The Compiler Whisperer · October 2026

10 Signs Your In-House Application Is Ready to Retire

You can usually tell your in-house system is in trouble by one sentence: the thing that used to be a small tool is now the reason a whole team exists. The invoicing app that started as a weekend project now has its own on-call rota. The order entry form in Access now needs two people to know where the real data is. The batch job that "has always worked" is the one nobody dares touch.

"Retire" here does not mean you have already decided to throw it away. It means the cost of continuing to hold it in its current shape has crossed the point where doing nothing is itself a decision with consequences. This checklist is a way to find that crossing, sign by sign, so you are choosing with a count in front of you instead of a feeling in your chest. Score it honestly: most systems you are about to retire will light up at least four of the ten.

How to use this checklist

For each sign, mark it YES if it is true of your system today, NO if it is not, and WATCH if it is starting to. A useful rule of thumb, before I hand you any thresholds: any single one of signs 1–3 on its own is reason enough to start, because those three are the failure modes that cost the most when they finally land. Four or more across the list means you should be planning a move now, not reacting to it. Zero or one is the honest "it's fine for another while" answer — and that is a legitimate conclusion, not a failure to find a problem.

Sign 1: Only one person can touch it, and they know it

The tell is not that the code is complex. It is that a specific human is the bridge between the system and everyone else. Ask for a change and the answer is "we'd need that person." That person is not a colleague anymore; they are a load-bearing wall, and the building has a quiet, ongoing dependency on them staying. This is the most expensive sign because it compounds: the longer the single owner stays, the deeper the knowledge goes, and the fewer people there are in the industry who could take over at all — because the stack is the kind nobody is hiring for any more.

If this is true, the fix is not to fire the person or to write the whole system from scratch. It is to make the knowledge stop living only in a head: document the one or two load-bearing paths as they get touched, and move the data out of wherever it is trapped. The single-owner problem is the reason "it still works" is such a fragile thing — it works only while the person and the machine both keep existing. This is the sign I have written a full piece on, because it is the one that does not announce itself and the one most teams are one departure away from learning the hard way: see The "Last Admin" Problem for the 90-day exit plan that breaks the dependency while the person is still here.

Sign 2: The data is in a place you cannot confidently restore

This one is the one I would never let anyone skip. If your critical data lives in a single file on a share, inside an Access database on a desktop, or in a structure where "backup" means a copy that has not been tested with a real restore, then the system can already be dead and you would not know for a day or two. The question to ask is not "do we have backups?" — everyone says yes to that. The question is: can you prove it, right now, by restoring it to a machine you have not used before? If the honest answer is "we haven't tried in a while," you are not protected, you are optimistic.

A sign-2 hit is the highest-value fix on the whole list and the cheapest. Getting the data into a managed database that snapshots, points-in-time, and can be restored without a project removes the single largest catastrophic risk in the system — and it does not require touching the application logic at all. Everything else on this checklist can wait a year. This one should not. See Backing Up Microsoft Access: What Actually Works for the concrete shape of a backup that can be proven.

Sign 3: A change takes weeks, and nobody knows why

Not "the change is complex" — you can usually tell that when a change is genuinely complex. The sign is when a change that should take an afternoon is taking a month, and the reason given is "you have to be careful" or "the rest of it depends on it." That is the smell of coupling that no one mapped and no one can map without risk, because the only way to know what a change touches is to try the change and see. When the cost of a small change is the same as the cost of a big one, you have effectively stopped being able to evolve the system — and a system you cannot change is a system you can only maintain until it breaks in a way maintenance cannot fix.

Sign 4: It only runs on hardware or software you cannot easily replace

A machine in the corner that runs Windows 2003. A build that needs a compiler that is no longer sold. A service account on a domain that is being retired next year. The signal is not that the dependency is old — old dependencies are normal. The signal is that the dependency is single and unreplicated: there is one instance of it, it exists in one place, and the plan for what happens when it dies is a phrase rather than a procedure. The moment "we would have to figure that out if it broke" becomes the answer to "what happens if this machine dies," you are running a system with a scheduled failure that you have simply not been assigned a date for.

Sign 5: Workarounds have become part of the product

There is a spreadsheet that reconciles the database because the database can't be trusted to agree with itself. There is a manual step at month-end that "everyone knows to do." There is an export that a person copies into a different tool because the app won't talk to the other one. Workarounds are normal — every real system has some. The sign is when the workaround is load-bearing: remove it and the business stops. At that point you are not running one system, you are running a system plus a collection of small human systems that keep it coherent, and the humans are the part that is least reliable and least documented and most replaceable by the rest of the company.

Count them. "How many of our real workflows live outside the app, in a person's head or in a spreadsheet?" is a genuinely useful number, because each one you count is a chunk of the actual business process that is not in the software — which means when you do modernize, you need to decide what to do about each of them, and the honest list is longer than the team remembers.

Sign 6: The stack is leaving the industry, and hiring for it is getting hard

The talent pool is a resource that shrinks on a schedule you did not set. If the system is built on a framework that is past end-of-life, a language that is no longer taught, or an operating system that no longer gets security updates, then the person you rely on in sign 1 has a shrinking bench behind them — and so do you, when you try to hire a second. This is not a moral problem with the technology; it is the same as the hardware problem in sign 4, one layer up. The fix is not to pretend the old stack is fine. It is to recognize that the cost of the stack is going up every year in the form of "harder to find the people," and that cost will eventually show up as a specific, expensive emergency.

Sign 7: You are no longer improving it, only maintaining it

Look at the last twelve months of work on the system. If it is all "fixed a bug," "patched a crash," "kept it running after the Windows update," and there is not a single entry that says "added the feature the sales team has asked for twice," then the system has stopped being a tool and become a liability you pay people to hold still. This is the honest signal that the investment case has flipped: you are spending real, current money to preserve a fixed, unchanging capability. The moment the ratio is 100% maintenance and 0% development, every dollar you spend on it buys you the same thing you had last month — and that is the definition of a cost that is no longer producing any value beyond survival.

Sign 8: Integration is the job, and it's getting more brittle

If a big chunk of your engineers' week is spent on the glue — moving data in and out, keeping the formats matching, patching the interface after the other system updates — then the system you thought was a tool is actually a node in a fragile network, and the node is the part you cannot fix because fixing it means touching the thing everyone depends on. The sign is the trend: it used to take an hour to reconcile two systems, now it takes a day, and the next person who touches it will find it has grown another dependency. Brittle integrations do not fail once; they fail in a chain, and the failure you are most likely to have is the one where two systems that have agreed with each other for years quietly stop agreeing, and nobody notices for a week.

Sign 9: Security and compliance are a "later" problem that keeps getting "later"

If the system stores personal or financial data and you cannot point to where it is, who can access it, and when it was last reviewed, that is a sign regardless of whether anything has broken. The reason is that the risk is not symmetric: the cost of the review is a bounded, one-time, visible cost. The cost of the finding — the data that was exposed, the customer that was breached, the audit that failed — is unbounded, and it is the kind of cost that arrives on someone else's timeline. "It hasn't happened yet" is not a control, it is a luck budget, and the budget is finite.

Sign 10: Retiring it is being postponed, and the postponement is getting more expensive

This is the meta-sign, and it is the one that turns a list of nine problems into a decision. You have been meaning to deal with the system for a while. Each year you postpone, one of the signs above has gotten worse — the stack has aged another year, the workaround list is longer, the single owner has more knowledge and more leverage, the dependency is more entangled. The sign is not that you haven't retired it. The sign is that the cost of retiring it in year one was lower than the cost of retiring it in year four, and you are now paying the difference every year for the privilege of deciding later. That "later" has a real price, and the price is going up.

What "ready to retire" actually means: three honest outcomes

Before the migration talk, an important reframe: ready to retire does not automatically mean rewrite it. For most small, in-house line-of-business systems, a full rewrite is the most expensive and most likely-to-fail option, and it is not the default answer. The checklist above tells you the system is in a state where doing nothing is becoming a choice with consequences. The response can be one of three things, and the right one depends on how many signs lit up and which ones:

The reason I put "replace with a product" in here is that it is the answer people skip, because it feels like admitting the in-house system was a mistake. It is not. If the core function of your system is the function of a product that already exists and is maintained by a company whose business is that function, then building and maintaining your own copy of it was always a cost you were paying for the privilege of having built it. Recognizing that is not a failure of the past; it is the cheapest of the three paths forward, and it is the one that frees the most engineering time.

The path, if the signs point to modernize

Whichever outcome you land on, the modernize path follows the same shape I described in The Hidden Cost of "It Still Works": it is a strangle, not a replace. The old system never stops being the source of truth for the paths you have not moved yet; the new side takes on one path at a time, each independently reversible; and nothing is decommissioned until the new side has survived a full bad month on its own. The ten signs above are the reasons to start that pattern. The pattern itself is the answer to the risk that makes retirement feel dangerous — which is that a big-bang cutover is the moment the whole business depends on the new system being right, and it rarely is, the first time.

Risks of acting on the checklist — and the ones of not

There is a real risk in modernizing a system that was, in the end, fine. You spend a year and six months moving paths to a new stack, and the new stack has its own set of small, boring problems, and you are now paying for two systems during the transition instead of one. That risk is real, and it is why the strangle pattern is the shape: it caps the downside of a wrong decision, because at every month you can stop, and stopping costs you nothing you did not already have. The old system is still there, still running, still the source of truth for everything you did not move.

The risk of not acting, when the signs are genuinely lit, is worse and it is the one that does not have a stop button. The single owner in sign 1 will eventually not be available, and the system will stop. The hardware in sign 4 will eventually die, and the system will stop. The stack in sign 6 will eventually stop being supported, and the system will stop with nothing new to move to, because by then the knowledge will be thinner and the dependency denser. The difference between the two risks is that the first one you can choose to pay a little of, on your schedule, and stop. The second one you pay in full, on the failure's schedule, and it is not optional.

Tools and the boring modern shape, if you choose modernize

The "modern" answer to a system like this is deliberately unglamorous, and the unglamorousness is the point. You do not need a platform, a framework, or a migration program. You need: a managed relational database that backs up and restores (PostgreSQL or SQL Server on a managed host is the boring, correct default — the point is that it is a real database with real recovery, not a file you copy); a small service in a language your hireable staff can read and maintain in ten years (Python, C#, or Node — the choice matters less than the maintenance); and a thin front-end for the forms and reports that used to live in Access or VB. That is the whole stack. It runs on any of the major clouds, or on a managed host that hides the cloud choice, and the reason to pick the boring option is not performance, it is that in ten years the person who inherits it will be able to read it.

If the system is Windows-based and the shape of the application is fine, the first step can be as small as moving it to a managed host with snapshots and offsite backups — the same operating system, the same shape, but with the failure modes turned boring: restart, restore, done. A managed host ↗ is a legitimate first move for exactly that reason: it removes the infrastructure-level risks (the machine, the backup, the single location) without requiring you to change a line of application code. Affiliate link — I may earn a commission if you sign up; you pay the same price either way. Whether you end up on a managed host or on one of the hyperscalers directly, the honest comparison is the same: you are paying for the failure modes to become routine, and that is a cost worth paying the moment sign 4 is lit.

Frequently asked questions

How many signs does it take before I should actually do something?
Any one of signs 1, 2, or 4 on its own is enough to start, because those three are the failure modes that cost the most when they finally arrive and the ones you cannot cheaply stop once they start. Three or more signs across the list means you should be planning now rather than reacting. One or two, none of those three, and the system stable — that is the honest "contain it for another year" answer, and it is a correct one.

Does this mean I have to rewrite the whole thing?
No, and I would push back hard on anyone who tells you it does. For most small in-house systems, the full rewrite is the most expensive and most failure-prone option. The sign-2 fix (get the data into a real database) removes the biggest catastrophic risk without touching the application at all, and the rest can follow one path at a time, on a schedule you control, with the old system running the whole way through. "Retire" means the current shape is past its cost-benefit crossing, not that you are throwing the code away this quarter.

We're a small team and we can't afford a project. What's the one thing to do?
The one thing is sign 2, and it is the cheapest thing on the list: prove you can restore your data to a machine you have not used before, and if you can't, move the data into a managed database that can. That single step removes the largest catastrophic risk in the whole system and it does not require a project, a cutover, or a new stack. Everything else on the checklist can wait. That step is the one that should not, because it is the difference between a bad week and a business-ending event.

What if the honest answer is that the system is fine?
Then you should have scored low, and you should do the contain path: document the load-bearing paths, confirm the backup is real, and put a real date on the next review. The reason I write these checklists as questions and not as verdicts is that "we looked at it, scored it, and it's fine for another year" is a legitimate engineering conclusion that is worth having in writing — because it converts a vague anxiety into a scheduled, cheap review, and it stops the system from being a permanent, unpriced worry that taxes the same people it is built from.

Summary

• "Ready to retire" means the cost of continuing in the current shape has crossed the point where doing nothing is a decision with consequences — not that you have decided to replace it.
• Score the ten signs honestly. Any one of 1 (single owner), 2 (unrestorable data), or 4 (unreplaceable dependency) is enough to start, because those are the failures that land loudly and expensively.
• Four or more signs means plan now; one or two with the system stable means contain it and review in a year — that is a correct answer, not a cop-out.
• The response is one of three: contain, modernize incrementally, or replace with a product. A full rewrite is the most expensive option and is not the default.
• The cheapest, highest-value step is almost always sign 2: prove you can restore the data, and move it into a managed database that can — this removes the largest catastrophic risk without touching the application at all.
• Modernize by strangling, not replacing: one path at a time, the old system live throughout, nothing decommissioned until the new side survives a full bad month. The ability to stop at any month is what makes it affordable for a small team.