# Software Archaeology: Modernising Code Older Than Me > When you modernise a system older than you are, everyone's first instinct is to open the code. Mine isn't. How I dig a business out of its data and its people instead, and why the code is the last place I look. - Author: Salim Ben Hassine (https://salimbenhassine.com/about) - Published: 2026-08-18 - Topics: Legacy Modernisation, Architecture, Engineering - URL: https://salimbenhassine.com/posts/software-archaeology Some of the systems I work on are older than I am. They were running a large company's business while I was learning to walk, and they're still doing it today, more reliably than most things built last year. My job is to replace them without anyone noticing. Which makes me a kind of archaeologist, except I'm not allowed to put anything in a museum. Everything I dig up has to keep working. --- ## Everybody wants to open the code Put a team of developers in front of a forty-year-old system and watch what happens. Within an hour someone has opened the source code, someone else is counting lines, and a third person is explaining that the whole thing could be rewritten in a modern language "in a few months". I understand the instinct. We're developers, code is what we read. But for modernisation, the code is usually the worst place to start. Decades of code are decades of decisions, workarounds and patches, and you can't tell them apart from the outside. Reading it line by line, you learn how somebody once understood the business, in a hurry, under pressure, probably in 1994. Translate that into a modern language and you've carried every dead feature, every old bug and every forgotten workaround into the new system, now with better syntax. I'm not alone in this. A recent piece on [a data-first pattern for legacy modernisation](https://dzone.com/articles/a-data-first-pattern-for-legacy-modernization) makes the same argument, and others call [translating legacy code a modernisation trap](https://www.retailbankerinternational.com/comment/why-translating-legacy-code-is-modernisation-trap/). What you're replacing is what the business needs the code to do. So I start somewhere else. --- ## Layer one: the data Code gets rewritten, patched and reorganised. Data outlives all of it. The tables and records of an old system are usually the most honest description of the business you'll ever get, because the business has been writing to them every day for decades. **Map the tables to the business.** What is a record in this table, in business words? A customer, a contract, a claim, a delivery? Which statuses can it have, and what does each one mean to the people who work with it? How do the entities relate? A good map of the data model gets you further than a hundred pages of documentation, mostly because the documentation describes a system that stopped existing years ago. **Follow the data flows.** Where does the data come from, where does it go, and when? Which jobs move it, which files leave the building at night, which other system depends on a table nobody mentioned in the kickoff? Follow one important piece of data from the moment it's created until it's archived, and you'll understand more about how the business really runs than anyone in the steering committee. And you'll find the surprises: the interface nobody knew about, the field that was officially retired years ago and is still filled every night, the flow that only runs at month end and therefore never shows up in a demo. The data tells you *what* the business does. It doesn't tell you *why*. For that, you need the people. --- ## Layer two: the people Every old system is surrounded by people who know far more than any document. Business users who work with it every day, process owners, stakeholders who were there when the rules were made. They're the real documentation. Most of them have just never been asked. **Workshops.** I bring what I found in the data and walk through it with them. "This status, what does it mean for you? Why does this happen before that? Who gets this file?" Show people their own data and the stories come out by themselves, including the ones nobody thought were worth mentioning. **Process walk-throughs.** I sit with users and watch how they actually work, which is rarely how the process is described. This is where you find the workarounds: the spreadsheet next to the system, the manual correction every Friday, the screen everyone uses for something it was never built for. Every workaround is a requirement the old system never met, and the new one will have to. **Rules in writing, confirmed.** Every business rule I derive from data and conversations gets written down and confirmed by someone who owns that part of the business, before anyone builds it. "We think it works like this" isn't good enough when the system moves real money for real clients. The written rule is also the best gift you can leave the next team, so they don't have to dig through the same layers again. --- ## The fence problem Sooner or later you find something nobody can explain. A status nobody uses, a flow that seems to go nowhere, a special case for one client from long ago. The temptation is to delete it. There's a famous principle against that, [Chesterton's fence](https://medium.com/@BrandonBryson/assessing-legacy-code-using-chestertons-fence-38b299aa472f): if you find a fence in the middle of a field and don't know why it's there, don't tear it down until you find out. In legacy systems, that fence is usually load-bearing. Somebody negotiated it, a contract depends on it, and the client in question will notice within one billing cycle. But the principle has a dark side, and it can freeze a whole project. "We don't know why it's there" can become a reason to keep everything forever, and then your shiny new system is the old one with a new paint job. The way out is to give every fence a deadline: we find out why it's there, from the data or from the business, by a date. If nobody can explain it and no data uses it by then, it's documented as dropped, signed off by the business, and it doesn't come along. Keep what you understand. Drop what you've proven is dead. Never drop something just because it's ugly. --- ## What the dig teaches you The old system isn't the specification. The business is. The code only tells you how someone understood the business at one point in time, and the data tells you what really happened since. So start with the data, bring it to the people, write down what they confirm, and treat everything else as a hypothesis. Somewhere, someday, someone will modernise the system you're building today, staring at your tables and wondering who you were. Be nice to them. Leave a data model that makes sense and rules that are written down.