What to check before replacing an internal system
A checklist so you don't scrap (or save) an old system for the wrong reasons.
Before deciding to replace an internal system, it's worth checking five concrete things — in this order, because each one shapes the next.
What it actually does today. Not what the manual says, or what it was originally designed for, but what people actually use in practice. It's common to find entire features nobody has touched in years, and others that became critical without ever being designed for that.
Who depends on it, and how. A system three people use for a weekly task doesn't carry the same risk as one that runs the whole company's daily invoicing. The level of dependency defines how much care the transition needs, regardless of how old the code is.
How well it integrates with everything else. A system that today connects to other tools manually (export a spreadsheet, import it somewhere else) can keep working that way for a while. One that already has automatic integrations built is more expensive to replace than it looks, because it's not just the system — it's everything that depends on it.
How urgent the real problem is. Slow isn't the same as broken. A slow but reliable system can be optimized; one that silently generates data errors is a different, more urgent problem, regardless of speed.
Only once you have those four answers does it make sense to ask whether to replace everything, modernize in parts, or simply leave it as is for a while longer.