The legacy IT system modernization market reached $16.58 billion in 2025 and is projected to grow to $50.32 billion by 2032, a compound annual growth rate of 17.2%. Behind that spending sits a problem most large enterprises recognize but few have solved. The systems that run daily operations were built decades ago; the engineers who built them have retired or moved on, and every modernization plan eventually collides with the same question: how do you replace infrastructure that cannot be switched off? The conventional answers, rewriting applications or building custom connectors one system at a time, have produced a long record of stalled programs and abandoned budgets.
Mundakkapatta Dileep Kainary, an Application Architect at IBM, has spent more than 22 years working on that question, designing enterprise integration platforms for large-scale telecom operations. He is a co-inventor on a U.S. patent for an intelligent interceptor architecture used in SaaS cloud migration, an invention he later carried into production at enterprise scale. His answer to how legacy estates get modernized is counterintuitive: the fastest way to modernize a legacy system is to avoid touching it at all.
Maintenance is consuming the budget meant for change
Organizations spend between 60% and 80% of their IT budgets on maintaining existing systems, leaving as little as one fifth for new capabilities. The arithmetic gets worse with age. Older platforms demand specialized skills that grow scarcer every year, and the cost of each change rises as documentation thins and institutional knowledge walks out the door. The result is a self-reinforcing trap: the more an organization spends keeping old systems alive, the less it has available to replace them.
Mundakkapatta saw this pattern up close while architecting integration for a major U.S. telecommunications carrier, where more than 60 legacy applications had accumulated across decades of operations. Some ran on protocols such as CORBA and DSAP that vendors no longer support, which made any modification to those systems a genuine operational risk. Several had no active owner at all. Before a line of integration code was written, he mapped every application, its protocol, its data contracts, and its failure modes, building a complete inventory of an estate that no single team fully understood. That inventory became the foundation for everything that followed.
“The instinct on every modernization program is to start rewriting,” Mundakkapatta says. “We did the opposite. We treated the legacy estate as fixed and asked what architecture could connect all of it without changing any of it. Once you accept that constraint, the design space gets much clearer.”
Telecom carries the heaviest legacy load
Worldwide telecom spending is projected to reach $1.375 trillion in 2025, which is 24% of the entire global ICT market. Carriers run some of the oldest continuously operating software in any industry, and their service assurance platforms, the systems that detect and resolve network problems, cannot tolerate downtime while being replaced. A bank can schedule a maintenance window. A carrier whose network monitoring goes dark is flying blind, and the customers on that network notice within minutes.
Working within that constraint, Mundakkapatta led the design of an interceptor-based integration platform that connects a modern SaaS service management system with the carrier’s legacy applications across 8 distinct protocols, from REST and Kafka to message queues and managed file transfer. The patented architecture places a single reusable layer between old and new. Each legacy application joins the platform through one URL or IP pointer change, with no code or schema modification on the legacy side. What had been a many-to-many integration problem collapsed into a one-to-many problem, and the integration logic stayed outside the SaaS platform itself, which kept that platform clean, upgradeable, and replaceable if the carrier ever chooses a different vendor.
“Every per-system connector you build is a liability you maintain forever,” he explains. “One interceptor layer, with drop-in containers for each protocol, meant a new legacy system became a configuration exercise instead of a 6-month project. The application teams never had to relearn each protocol, because the protocol problem was solved once.”
Configuration replaced custom code
Most integration programs fail on repetition. Each new connection gets its own custom development effort, its own testing cycle, and its own maintenance burden, so costs scale linearly with every system added. At enterprise scale, that line crosses the budget ceiling long before the work is done. The alternative is to make integration declarative, where the mappings between systems are defined as configuration rather than written as code, and where a shared library of adapters, transformers, and error handlers does the heavy lifting for every new connection.
Mundakkapatta built the platform’s transformation layer on exactly that principle, with multi-level declarative mappings covering operations, attributes, and individual values, and a governance process that reviewed every new integration against the patented pattern to prevent architectural drift. His work on intelligent systems architecture has also led to his selection as a speaker at ICAISCST 2026. Under the declarative model, onboarding a new legacy system dropped from months to weeks, and per-integration cost fell by well over half.
“Code is where integration projects go to stall,” he notes. “When a mapping is data instead of logic, a business analyst can review it, a tester can validate it, and nobody has to schedule a release to fix it. We pushed everything we could out of code and into configuration, and the delivery calendar changed shape almost immediately.”
Migration happened without a day-one cutover
Large enterprises rarely fail at modernization because the target platform is wrong. They fail at the transition, when a big-bang cutover meets the operational reality of systems that must run 24 hours a day, 7 days a week. The programs that finish are the ones that move incrementally, keep the old path alive alongside the new one, and preserve a rollback option at every step. That discipline costs more in planning and less in everything else.
The interceptor platform routes tickets intelligently between the new SaaS system and the legacy ticketing environment, so workloads moved over one workflow at a time rather than one system at a time. Built on event-driven architecture with Kafka as its backbone, the platform decouples legacy producers from cloud consumers and handles replay and back-pressure when downstream systems struggle, which matters in an operation that never closes. It now supports tens of thousands of agents, dispatchers, and operations center staff, has processed millions of tickets in production, and was designed with monitoring, audit trails, and error tracing as requirements from the first design review rather than additions bolted on later.
“Service assurance can never go dark, so we ran old and new in parallel and cut over per workflow,” Mundakkapatta observes. “Every step had a way back. That is what made the migration boring, and boring is the goal. Nobody writes case studies about the cutover weekend that went exactly as planned, but that is the weekend you want.”
An integration backbone built for what comes next
The economics of the interceptor pattern compound over time. Each additional system integrated through the shared layer costs less than the one before it, while the per-connector model gets more expensive as the estate grows and the oldest connectors demand the most care. For carriers with hundreds of legacy applications still in service, that difference decides whether modernization roadmaps survive contact with budget season. The pattern also changes who can do the work, since configuration-driven onboarding opens integration to teams that never touch the platform’s core.
Mundakkapatta sees the same architecture carrying the next wave of change. The integration layer that connects legacy systems to SaaS platforms today is the natural insertion point for agentic AI, where autonomous agents read events from the same bus, diagnose problems, and trigger remediation without a human in the loop. The hard prerequisite for autonomous operations, a single consistent stream of operational events, already exists wherever the interceptor runs. His current work focuses on exactly that progression, from integration that moves tickets to integration that resolves them.
“The interceptor was never just about migration. It gave us one place where every operational event in the enterprise flows through,” he reflects. “Once you have that, the question stops being how to connect systems and becomes how much of the work those systems can now do on their own. That second question is the one I expect to spend the next decade on.”
