What Your Oldest System Knows That Nobody Wrote Down
A team I heard about once switched off a server that sat in a corner of the office. Nobody could say what it did. It had been quiet for years, and the logic was simple enough: if nobody knows, nobody will miss it.
Three weeks later, on the last day of the month, customer invoices stopped going out.
It turned out that box ran one small script, once a month, that nobody had touched since the person who wrote it left. That script was quietly holding up a piece of the business.
Every legacy platform has a server like that. Transformation projects succeed or fail based on whether you find it before or after you switch something off.
Start by listening
Most teams open a modernization project by picking a target. Kubernetes, microservices, some shiny cloud service. That is the wrong first move.
The first move is to find out what the old system actually does, which is often different from what the documentation says. Read the logs. Look at the scheduled jobs. Watch real traffic for a full business cycle, including month end, year end and whatever weird day your industry has. Sit with the people who use it and ask what they do when it breaks, because the workarounds tell you where the real behavior lives.
Then ask the question that changes everything: what happens on the 31st?
Modernize the architecture in slices
Rewriting everything at once is the plan that looks cleanest on a slide and fails most often in practice. Two years in, you are running two systems, the old one keeps changing, and the new one is always catching up.
The better pattern is called the strangler approach. You put a thin layer in front of the old platform, then move one capability at a time behind it. Quotes move first, say, then billing, then reporting. The old system shrinks until one day you notice nobody calls it anymore.
The tricky part is choosing the slices. Cut along business capabilities, not technical layers. "The database" is not a slice. "How we price an order" is. And for your first slice, pick something that hurts but is not scary. You want a win that teaches the team how this works before you touch the part that pays the salaries.
Cloud migration is a question about data
Moving servers is the easy half. You can lift the whole application into a cloud environment in a few weeks, and sometimes that is exactly the right first step, because it gets you out of a data center contract and gives you room to breathe.
But the application is not where the weight is. The data is. Twenty years of it, in shapes nobody planned, with reports and integrations quietly depending on odd column names.
So plan the data move first, even if you execute it last. Ask how you will keep old and new in sync while both are live. Ask how you would move back if something goes wrong on day three. Choose the order of moves that keeps that door open the longest.
Integration is where the surprises live
Your legacy platform probably talks to more things than anyone remembers. A partner who still gets a file by SFTP every night. A warehouse system that expects a specific date format. A finance tool reading straight from a database table it was never supposed to touch.
Before you move anything, list every conversation the old system has with the outside world, in both directions. Then build a translation layer so the new pieces can speak to those old contracts without inheriting their quirks. Over time you can retire the awkward formats one partner at a time, on your schedule and not in a panic.
Events help here too. When the old system announces "an order was placed" and anything can listen, you can add new services without editing something fragile.
Test against reality, not against opinions
Here is a testing idea that sounds almost too simple. Record what the old system does with real requests. Then replay those same requests against the new one and compare the answers.
Every difference is either a bug in the new system or a bug the old system has been hiding for years. Both are worth knowing about. Teams doing this often find that the old platform has been rounding a number in a strange way, and a whole department has been relying on it.
Tests written from the specification catch what the specification knows. Tests built from real traffic catch what the business actually does.
You can push this further with shadow mode. The new system receives live traffic and does its work, but nobody sees the result. You just watch it be right, or wrong, for a few weeks before anyone depends on it.
Deploy so that being wrong is cheap
Big cutover weekends are exciting and mostly unnecessary. If you did the earlier steps well, the final move can be almost boring.
Use feature flags so you can send one percent of traffic to the new path, then five, then twenty. Start with an internal team or a friendly customer. Watch the numbers that matter to the business, not just error rates. Are orders per hour normal? Is payment success steady?
Rehearse the rollback until it feels dull, and do that before launch, not during it. Pick a quiet Tuesday. Nobody has ever regretted a quiet Tuesday.
The part no tool solves
Behind every legacy system there is usually one person who understands it. Sometimes two. They have seen every outage and know why that odd line of code exists.
Bring them in early, and treat their knowledge as the most valuable input the project has. Give them a real role in the new design. If they feel the project is about replacing them, they will not tell you about the monthly script.
One question
Before you plan a single migration step, ask your team this: what does our oldest system do that nobody has ever written down?
Somebody will go quiet, then say "actually, there is this one thing." Follow that thread. It is usually the best map of the project you will get.
BroskiesHub Team
The Team
Insights and perspectives from the BroskiesHub engineering and product team.
