I once convinced a room full of executives that we could replace a twenty year old order management system over a single holiday weekend. I had diagrams, a phased data migration plan, and a very confident slide deck. The old COBOL system was ugly and slow, and I figured we could just rewrite it in something modern, test it thoroughly, and flip the switch. We spent eleven months building the replacement. The cutover lasted about six hours before we rolled everything back.
The problem wasn't the code. It was the thousand small business rules that lived only in the old system's triggers and in the heads of three people who had been there since the nineties. Discounts that applied only on Tuesdays for certain customer tiers. Inventory holds that activated when a specific warehouse printer went offline. Nobody had written these down. Our new system didn't know they existed until orders started failing.
That failure changed how I approach modernization. The first thing I do now is spend at least a week just watching people use the legacy system. Not reading documentation, not interviewing managers, but sitting next to the order entry folks and the warehouse staff. You see the actual workflows, the workarounds, the shortcuts that keep the business running. I missed all of that because I was focused on the technology.
The strategy that ended up working for us was the strangler fig approach. Instead of replacing the whole system at once, you pick one small, self contained piece of functionality and build a new service around it. For us, that was customer address validation. We built a small modern API that took an address, normalized it, and returned a clean version. Then we pointed the legacy system at that API. It took six weeks, not eleven months. If it failed, only address validation failed, nothing else. We could compare the old and new outputs side by side for a month.
Over the next two years, we slowly strangled the old system this way. The shipping label module went next, then the credit check service, then pricing. Each piece had its own rollback plan and its own side by side monitoring. We kept a feature flag on everything so we could route traffic back to the legacy code if something looked off. It felt slower than the big bang, but the business never noticed a single outage.
One mistake I made during that transition was underestimating the human side. There was a woman named Diane in the back office who had run the old green screen system for fifteen years. She knew every bug and every workaround. When we started replacing her tools, she got defensive and stopped sharing information. I had to rebuild that trust by asking her to test each new module before we rolled it out. Once she felt like a partner instead of a dinosaur, she became our best source of truth about edge cases.
Modernization is not really about the technology. It's about reducing risk, preserving institutional knowledge, and respecting the people who kept the old thing alive. You don't need a big cutover weekend. You need a series of small, boring releases that nobody notices. That's the goal. If nobody on the floor remembers when you changed the credit check service, you did it right.
Maybe the real lesson is that a legacy system is not a problem to be solved. It's a record of every compromise and shortcut the business has made over twenty years. You can't replace that in one weekend. You have to honor it, one small replacement at a time.