The End Of Software Archaeology: Why The Old Rules Of System Modernization No Longer Apply
Kostiantyn Gitko is the CEO of Devox Software, specializing in AI-native transformation and scaling complex systems for global enterprises.
gettyI never would have thought that my childhood dream of becoming an archaeologist would have so much in common with what I do today. Even at age five, I was fascinated by the idea that a dusty, bearded archaeologist armed with a pickax and a shovel could look at an empty field and somehow know that an entire ancient city might lie beneath it. I was ready to walk miles through the desert for that kind of adventure. Today, I have a beard, and I run an IT company.
In programming, I found that same sense of discovery in legacy-heavy codebases. In large systems, the real cost of legacy often comes from more than the old code itself.
The longer a system has been around, the more unwritten decisions pile up around its older modules: why someone chose a particular approach in the first place or what trade-offs were made to meet a deadline. Beyond that, over the years, developers made assumptions about what the system could and couldn’t do. Those assumptions made sense at the time, but many are no longer valid given today’s technology.
Unfortunately, that uncertainty creates problems that surface precisely when a company becomes successful, sometimes forcing it to pause marketing campaigns because its systems can’t keep up with demand. And the problem may have little to do with code quality. The code itself may have been perfectly good for its time; the real issue may lie in the legacy architecture, something I’ve seen firsthand many times.
Just as archaeologists examine artifacts in the context of the layers around them, we need to understand legacy systems in the context of how they’ve evolved over time. A 1998 system is rarely a “1998 system”: It may contain a 1998 core, a compliance rule added in 2007, a workaround introduced after a 2014 incident, a 2019 API and a 2026 AI integration. A strange-looking rule may trace back to a regulation from years earlier. Fundamentally, those layers also preserve the business’s history.
Interestingly, when it comes to modernization risk, age can be a red herring. A system can run reliably for 15 years while the business gradually adapts its processes to work around the system’s limitations. For instance, two modules may never call one another directly and still be tightly coupled through a shared table, or a three-year-old patch that tied five systems together turns out to be the dangerous one. That’s the trap.
So where do we start digging? For decades, legacy modernization meant mapping the system by hand: following calls from module to module to find out what a click sets in motion and where the data ends up. There was a lot to unearth. Field studies before AI found that developers spent 58% to 70% of their time trying to understand existing code and roughly 5% changing it. First dig, then map.
But now, with artificial intelligence, we can start with a map and dig into the areas we still don’t fully understand. In practice, AI usually builds on existing code-analysis tools that show which systems read and modify shared data, but the intelligent layer brings it all together into something closer to a map of the system. A well-engineered, secure AI setup can work through mountains of data and uncover hidden microconnections that algorithmic non-AI tools can miss because they only see what they’re built to find.
Together, these sources help produce a much more detailed dependency graph compared to traditional tools. An AI-enhanced dependency graph works like a street map of the system. It shows what relies on what and how far the impact of a change may spread, which also reveals where the architecture is vulnerable. A process tree takes this a step further, adding business context by showing how a component fits into day-to-day operations.
• What do we need to modernize first, and what can we leave alone? Do we need to invest in testing or anything else before we start?
• How much faster can we ship new features once we know what depends on what?
• Where will the system likely start to struggle as we grow?
• What depends on this component, and what else could break if we change it?
• How much time and money can we save by catching problems before we start?
If several critical processes depend on one component, start there, and, if it is needed, decouple it. Otherwise, you could spend millions rebuilding the system—and bring all its old problems with new technology. On the flip side, not every legacy system needs a rewrite. If the core works reliably, AI can help teams understand it, and modernization can add what’s missing. Keeping it may make better business sense.
Perhaps most importantly, AI can help senior engineers see where to dig and where to tread carefully. Where the code, runtime behavior and documentation don’t line up, they know to take a closer look. AI’s ability to analyze code and reconstruct its logic makes it possible to turn years of undocumented code into usable, careful documentation.
Finally, don’t put the map away after the initial analysis. My team keeps this map in sync with the code and the way the system actually runs, so we always have an up-to-date picture of how the technology supports the business.
Even the most experienced archaeologist can only uncover so much with a shovel. New technologies like ground-penetrating radar have extended that reach, helping researchers identify patterns and investigate areas they might otherwise overlook. AI offers a similar opportunity in enterprise IT.
Fascinatingly (and yes, I confess I still geek out over archaeology news), AI has already transformed actual archaeology, too: Robotic systems now process radar data to build 3D subsurface models without digging a single trench. What we are seeing in enterprise IT today is a remarkably similar story, with AI giving us new ways to understand even the most complex legacy systems.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
