Legacy System Modernization Without a Risky Migration

The concern around large-scale system replacement is well founded because concentrating data migration, integration, process change, and adoption into a single initiative leaves little room for error. Bain & Company reports that roughly 90% of ERP transformations fall short of their goals, and Gartner predicts that more than 70% of recently implemented ERP initiatives will fail to fully meet their original business objectives, with as many as 25% failing in ways that qualify as catastrophic. Those outcomes can make delaying modernization seem like the safer choice, even as aging systems become more expensive to maintain and more difficult to replace over time.

The concern around large-scale system replacement is well founded because concentrating data migration, integration, process change, and adoption into a single initiative leaves little room for error. Bain & Company reports that roughly 90% of ERP transformations fall short of their goals, and Gartner predicts that more than 70% of recently implemented ERP initiatives will fail to fully meet their original business objectives, with as many as 25% failing in ways that qualify as catastrophic. Those outcomes can make delaying modernization seem like the safer choice, even as aging systems become more expensive to maintain and more difficult to replace over timeHeading into 2027 planning, the smarter move is to stop framing modernization as a choice between an expensive, high-risk migration and continuing to work around aging systems. A sequenced approach creates a more practical path by identifying where change will have the greatest business impact, accounting for dependencies and risk across the environment, and breaking the work into manageable waves that can demonstrate value before additional investment is committed.

The risk of a full system cutover comes from requiring too many critical changes to succeed at the same time. Data migration, system integration, process redesign, security, testing, user adoption, and rollback plans all have to work together, which means a problem in one area can disrupt the entire program. This concentration of risk helps explain why large replacement efforts often underperform, particularly when the focus shifts toward completing the technical implementation rather than delivering the business outcomes that justified the investment.

The timeline and cost data reinforce how quickly the risk of a large-scale modernization effort can translate into measurable business consequences. In IBM’s study of more than 500 banking CIOs, 94% of core-banking modernization projects exceeded their planned timelines, and more than half of the CIOs reported higher-than-expected costs. Those overruns often emerge when an all-at-once approach exposes problems with data quality, system dependencies, integration requirements, and user adoption after the project is already underway.

Moving modernization forward in stages allows teams to validate each change in production before advancing to the next capability, keeping the impact of potential issues contained within a single wave rather than putting the broader initiative at risk. This approach gives teams an opportunity to learn and adjust as the work progresses, making the sequence of those investments, particularly what belongs in the first wave, an important part of the modernization strategy.

The instinct is often to start with either the easiest system or the most painful one, but neither is reliably the right place to begin. The better approach is to start from a measurable business outcome such as a shorter onboarding cycle, a faster monthly close, fewer outages, or a lower cost to serve, and then trace that outcome back to the specific systems, data domains, and interfaces that control it. Sequencing well means prioritizing modernization based on the results the business needs to improve rather than the age or technical limitations of a particular system.

The first wave should target an area with enough business value and complexity to prove the modernization approach without introducing unnecessary risk to critical operations. Thought works describes this as a “Goldilocks” choice, where the starting point is substantial enough to demonstrate results and build momentum, but contained enough for the team to learn and adjust before moving into more critical areas of the business.

Some of the most important early work produces little standalone return, and that is where sequencing judgment matters most. Investments in identity, API management, integration, observability, automated testing, and data governance rarely show up as a line-item benefit on their own. They earn their place by unlocking the outcomes that come after them. These foundational waves should be justified by the options they create rather than the immediate savings they generate, which requires a leadership team willing to fund enablement, not just visible features. Knowing what to change first only helps if the old and new systems can run side by side while the transition happens.

Sequencing depends on the ability to run modern and legacy components in parallel, and the most cited technique for doing that is the Strangler Fig pattern. The idea is to build a modern component alongside the existing system, route a slice of traffic to it through an integration or API layer, keep the legacy path available for rollback, and retire the old function only once the new one has proven itself in production. The pattern moves through three phases often described as transform, coexist, and eliminate, and its value is that no single step requires betting the business on an untested replacement.

Running legacy and modern systems in parallel only reduces risk when coexistence has a defined endpoint, and the older technology is ultimately retired. Many organizations add new components without fully decommissioning what they replace, leaving them to operate and pay for both systems while maintaining the integrations between them indefinitely. Each phase of modernization needs an explicit decommissioning condition, a clear owner, and a trigger for when the legacy function can be switched off. Without that discipline, incremental modernization can increase total cost rather than reduce it. 

The integration layer that makes coexistence possible carries the same risk. A connective layer stood up to let systems talk during a transition can quietly become permanent middleware debt if it's left ungoverned. Treating that layer as a product, with defined contracts, monitoring, clear ownership, and its own retirement plan, is what keeps a bridge from turning into a fixture. Our work integrating disconnected platforms consistently shows that the connective tissue between systems needs the same discipline as the systems themselves. This discipline matters because the cost of skipping it compounds over time.

Deferring modernization allows technical debt to accumulate, increasing the cost and complexity of every future system change, integration, and technology investment. McKinsey estimates that 10 to 20% of the technology budget intended for new products gets diverted to addressing it, and in later work put technical debt at roughly 40% of the typical IT balance sheet. When that much capacity is consumed to maintain and work around aging systems, there is simply less left to fund growth. The organization pays a surcharge on every initiative and often cannot see the invoice.

This debt is not a fringe problem confined to a few outdated tools. McKinsey reports that as much as 70% of the software used by Fortune 500 companies was developed 20 or more years ago, which means legacy is embedded in core operations rather than sitting at the edges. The systems running payroll, inventory, billing, and reporting are frequently the oldest ones in the building, and they are the hardest to touch precisely because so much depends on them.

The cost of delaying modernization grows as disconnected systems accumulate more manual workarounds, spreadsheets, and fragile point-to-point connections that eventually have to be untangled. The article on how aging systems raise the cost of maintaining business operations explores this dynamic in more detail, but the implication for modernization planning is clear. As those costs compound, modernization becomes less about funding new technology and more about recovering the time, capacity, and resources being consumed by the existing environment.

A practical example of this approach can be seen in KDG’s custom application work for The Arc, where a twenty-year-old payroll system and manual timesheet process created an opportunity to modernize without replacing the entire environment at once. Rather than beginning with a wholesale payroll migration, the work focused on building a connected application that modernized time capture and integrated with the systems and external vendors already supporting payroll.

This allowed a critical part of the process to improve while the existing payroll system remained in place, reducing the amount of operational change introduced at one time and creating a clearer path for future modernization. It demonstrates the value of sequencing around a specific business process first, proving that the new approach works within the existing environment before expanding the scope of change.

The right modernization strategy depends on the condition of the existing environment, the economics of coexistence, and the level of risk the business can reasonably carry. There are situations where a larger, more decisive replacement is the correct call. A system that cannot be safely partitioned into slices does not lend itself to gradual modernization. When the ongoing cost of running two systems in parallel would exceed the value of a smoother transition, coexistence stops making financial sense. A hard regulatory or vendor deadline can force a clean cutover on a fixed date, while a platform that creates unacceptable security or continuity exposure may need to be retired faster than an incremental plan would allow.

A full replacement should be based on the realities of the existing environment, business priorities, and risk rather than treated as the default path to modernization. While replacement may be necessary in some cases, a sequenced approach can often deliver meaningful progress sooner while limiting the amount of operational and financial risk introduced at one time. Understanding when each approach makes sense gives leadership a stronger basis for choosing how modernization should move forward.

We help organizations turn legacy modernization into a sequenced roadmap tied to measurable business outcomes. The work starts by mapping the current environment, identifying the systems, processes, data, and dependencies that affect those outcomes, and determining which changes should come first based on value and risk. From there, we structure modernization into fundable waves that allow legacy and modern systems to coexist where necessary, with clear plans for integration and eventual retirement. Each wave is designed to demonstrate measurable progress, reduce risk, and give leadership a clear basis for determining what comes next.