5 Legacy System Modernization Strategies That Bring ROI

Legacy software remains the engine under many companies’ hoods, but that decision comes at a premium. 

About three-quarters have 70% of their IT spending locked in supporting aging software. Naturally, this restricts new development initiatives as resources are tied up in maintenance, which is a feat of its own. Even a small product update requires extensive testing across tightly connected legacy components. 

Yet replacing the system carries its own risks. Years of embedded business logic make a full rewrite expensive, especially when daily critical operations depend on it. So meddling with this could pose risks to business continuity. 

That said, legacy system modernization doesn’t have to be an all-at-once approach. You can modernize incrementally, tackling the components causing the most friction while limiting disruption to daily operations.

In this post, we look at five legacy system modernization strategies that do just that, with examples from companies like Shopify, Uber, Pinterest, and Netflix.

Overview of the Legacy System Modernization Strategies

To choose the optimal legacy system modernization approach, we recommend starting with the end goal:

Determine which business aspect you want to improve first, e.g., lower maintenance costs or speed up new feature release. Then prioritize concerned systems by business value and risk. Modernize each only as far as the expected returns justify.  The architecture should follow those decisions.

For each of the legacy system modernization approaches described in this section, we explain exactly when it works best and what outcomes you can expect. 

Modular Monoliths

Your path to the cloud doesn’t have to be an instant transformation to microservices or domain-oriented services. Oftentimes, a better legacy system modernization approach is evolving to a modular monolith. 

A modular monolith architecture reorganizes a legacy application into distinct business modules with defined interfaces, while retaining its existing deployment model. Your system still deploys as one unit. But there are fewer dependencies between individual components and more room for compartmentalized modernization. 

As mentioned in our microservices architecture patterns post, this functional separation allows you to develop, test, scale, and evolve components with greater independence. So you gain the following advantages: 

• Simpler impact assessment. Clear module boundaries make dependencies easier to trace before updating business logic.

• Streamlined operations. A single deployment avoids the extra infrastructure and network communication required by separate microservices.

• Targeted investment. You can prioritize business-critical component modernization while preserving useful existing functionality.

• Flexibility for later extraction. Well-defined modules provide a starting point for microservices when independent scaling or deployment becomes necessary.

Shopify decided to go with a modular monolith when modernizing its monolith Rails application. With over 2.8 million lines of code and 500,000 commits, each new change could trigger failures in seemingly unrelated areas. So the company chose to reorganize its codebase around business domains, retaining one application while progressively separating component responsibilities.

The Shopify team can now also update individual components that drive the most business value without risking business continuity.  For example, they finally managed to replace Shopify’s legacy tax engine, which undermined the product experience. Previously, its dependencies had made replacement prohibitively difficult; after the team isolated them, it could introduce a new tax calculation system within the existing application. 

More recently, the team also completed a mobile app migration from React Native to native to improve CX and add new product features. Plus, they tested their new frameworks for AI-assisted software development, which were too risky to implement with a monolith application.  

Similarly, Edvantis has helped BigCommerce update their core platform stack through targeted component modernization. Following an acquisition, the company needed to improve an inherited application while continuing to maintain existing software and deliver new functionality.

We migrated core product components to a modern technology stack, including customer and product management functionality, alongside work on analytics. New development continued in parallel. Our teams also built an application that replaced third-party products with native features, connecting the modernization effort to greater control over product functionality.

Replatforming

Replatforming — moving an application to a new runtime or cloud environment with targeted changes (such as database, OS, or middleware) to gain cloud benefits — is hardly a new legacy software modernization strategy per se. 

But since it can result in a lower risk/reward ratio than rewriting business logic, it still deserves attention in 2026.

In this case, you preserve the application behavior and focus instead on replacing unsupported technology and improving runtime efficiency. So there’s less functionality that has to be rebuilt, with substantial gains in system performance and scalability.  

This was the rationale behind our work with Freenet Group. The telecom’s legacy applications ran on Java 6 and JBoss application servers, which no longer met business requirements. We migrated 16 legacy services in 12 months to Java 11 and Spring Boot, preserving all critical business logic while updating the underlying code and libraries. Integration tests helped verify that existing functionality continued working as the company moved towards a microservices architecture.

Uber’s legacy system modernization case study, in turn, illustrates how replatforming can improve the operating economics of a data analytics system. The company recently replaced batch ingestion to its data lake with an Apache Flink streaming platform. For migrated datasets, data freshness improved from hours to minutes, while compute usage fell by 25%. 

Infrastructure updates can also improve performance for mainframe-based applications, which remain a common “chokehold” in finance and manufacturing sectors. 

Even the tiniest changes can be difficult to test and deploy safely in mainframe systems because of decades of custom code and tightly coupled integrations. To boot, lack of mainframe expertise increases technical debt management costs and complicates newer technology integration. 

Mainframe modernization helps improve application performance and simplify integration with newer systems. JPMorgan Chase recently moved its  Card mainframe to a new data center, reporting approximately 20% faster response times for major customer-facing applications. Beyond performance gains, companies are also upgrading mainframes or connecting them to cloud services to support AI workloads. 

About 88% of respondents in Kyndryl’s 2025 survey had implemented or planned to implement generative AI tools in their mainframe environments. The technical advantage of doing so is proximity to business data. With compatible hardware and software, organizations can run AI inference alongside sensitive records, reducing the need to copy data into separate environments before models can use it. This can reduce transfer delays and simplify control over data access. For example, IBM’s z17 platform and z/OS 3.2 were designed to support this approach, including traditional and generative AI workloads.

API Enablement 

If you’re seeking to modernize just some apps in your portfolio, rather than a larger system, exposing their core functions through APIs can be the way to go.

The app stays in place while APIs expose selected functions and data through documented interfaces. So third parties can request payments or check inventory using your existing business logic, without needing to understand the underlying code.

Conversely, you’ll need to define the operations each API supports and the formats for requests and responses. An adapter translates these requests into calls the legacy application can process. An API gateway can then enforce access controls and limit incoming traffic. Monitoring helps teams track usage and failures.

When new API interfaces are designed for reuse, your company benefits from: 

• Faster integration. New applications can connect through documented APIs, reducing custom integration work.

• Wider access to existing capabilities. Internal teams and authorized partners can incorporate established functionality into new workflows.

• Extra distribution channels. Selected API services can become part of another company’s product and unlock new revenue streams. 

• More targeted modernization. Teams can extend useful applications while deferring replacement of the underlying systems.

Dutch ING specifically approached API enablement with external reuse in mind. As part of its open banking strategy, it began separating back-office functions into reusable services that could eventually support customers and partners beyond its own applications.

For example, they launched a transaction screening API, which allowed payment service providers to incorporate the bank’s screening capabilities into their own systems and customer workflows. An otherwise internal capability could now support external products (and generate extra revenue for the bank). 

Spanish BBVA applied a similar strategy in its Open Banking program: Years of investment in internal APIs connecting applications to its back-end services. Those interfaces already supported the bank’s operations. 

To make its capabilities available through partner channels, BBVA introduced tooling for API exposure and orchestration, combining new infrastructure with continued modernization of its core systems. With the new system in place, other companies could access BBVA’s account origination, identity verification, money movement, and card issuance through APIs, embedding banking services into products offered under their own brands. 

For example, the platform’s Move Money API brought several payment methods behind one interface, supporting uses such as marketplace payouts and disbursements to gig workers. Partners could add payment functionality within their existing customer workflows, while BBVA gained a way to distribute services beyond its own channels.

“As an incumbent, we possess a unique opportunity to leverage our existing suite of value-added internal services. While smaller competitors may initially focus on one or two services in a greenfield setting, as incumbents we should adopt a long-term strategy aimed at embedding a wide range of financial products and solutions. A logical approach involves blending new infrastructure with the modernization of our traditional core systems.”

Carmela Gómez, Global Head of Open Banking at BBVA.

 

API Façades

Building an API facade is a common method of improving product experience without rewriting the backend. 

Effectively, you create a new interface between the presentation layer and the underlying backend systems, which hides the differences in how those systems organize data or expose functionality. With this setup, web and mobile applications communicate with the façade, which routes requests to the appropriate backend services and combines their responses into a consistent format. 

API façades are a great “middle ground” for updating customer-facing apps without immediately modernizing the underlying legacy services. As back-end services are replaced, teams adjust the integration layer while keeping the apps’ API contract stable. So you gain: 

• Faster CX improvements. You can update digital channels before completing a core-system replacement to keep the momentum going. 

• Less duplicated integration work. Shared data definitions reduce the need for each application to interpret back-end responses differently.

• More controlled migration. Requests can move progressively from legacy components to replacement services.

• More efficient data retrieval. Where the façade supports aggregation and field selection, clients can avoid unnecessary calls and oversized responses.

Walmart encountered the cost of fragmented interfaces across its shopping experience. Different pages relied on separate orchestration services, each assembling information from back-end systems. Several retrieved the same product data but represented it differently, creating repeated integration work.

In 2020, the team described moving these REST-based orchestrators towards federated GraphQL. A central gateway coordinated requests across domain services, giving client applications a shared schema: a common definition of available data and its relationships.

The change simplified feature development. For example, the team responsible for wishlists could extend the shared product schema with a favorite-status field, reducing coordination across page-specific services. Walmart also reported approximately 60% smaller client payloads for equivalent functionality, although the gateway introduced around 20–40 milliseconds of network overhead in its environment.

More recently, Airbnb applied the same interface-decoupling principle through Viaduct, its GraphQL platform. Product engineers access data through one global schema, while the teams responsible for that data maintain the code that retrieves it. Viaduct also hosts team-owned business logic, making it a broader application platform. This arrangement reduces the need for consuming teams to understand individual back-end implementations.

Over time, Viaduct itself required modernization. With more than 1.5 million lines of hosted application code, Airbnb introduced a new execution engine supporting both its existing Classic API and a newer Modern API. Teams could migrate gradually while benefiting from engine improvements. The May 2026 Viaduct 1.0 release reported approximately 10 times higher throughput on large queries following execution-engine improvements. 

This Airbnb legacy system modernization case demonstrates how API façades can also help evolve infrastructure beneath an established interface, with application changes introduced at a manageable pace.

Event Interception and CDC 

An Event Interception / CDC modernization legacy system modernization strategy to connect new services to legacy data or workflows while minimizing risky changes to the source application.

The techniques connect old and new systems at different points:

• Event interception captures requests/messages passing between existing app components and routes selected traffic to a new service. This way, you can send copies for parallel processing at first. Then transfer responsibility once the replacement system is ready.

• Change data capture identifies database changes and makes them available to downstream systems. With log-based CDC, a connector reads committed changes from the database’s transaction log and publishes them for other applications to consume asynchronously.

Event interception suits gradual replacement when existing integration points provide a place to redirect processing. CDC is especially useful when an application lacks suitable APIs, but its database supports log access. So new systems receive updates while the original application continues running. 

Together, these provide a path for introducing new functionality without making every addition dependent on changes to the legacy application. CDC can also reduce repeated full-table copying by processing changes incrementally after an initial data load.

Take it from Pinterest, whose cost of keeping repeated copies as its data platform grew became unsustainable. Its older ingestion systems relied on batch jobs, with updates often taking more than 24 hours to reach downstream systems. Many tables changed by less than 5% daily, yet the pipelines repeatedly processed unchanged records, resulting in high spending. 

So the company developed a shared CDC platform to serve as a foundation for a next-gen data ingestion framework. Database changes flowed through Kafka into analytical storage, where incremental updates replaced repeated full-table processing. With this setup, downstream base-table freshness was reduced to 15 minutes to an hour, depending on configuration, alongside lower infrastructure consumption from processing only changed records.

Netflix faced a related challenge: keeping derived data stores, such as Elasticsearch, synchronized with authoritative databases such as MySQL. Initial loading and recovery complicated that task. Copying a large table could interrupt the stream of live updates, while approaches using table locks risked blocking application writes.

So the engineers developed DBLog to process database logs alongside small chunks of existing table data. Live updates continued flowing during the copy. Teams could initialize a new downstream store or repair missing data without acquiring table locks, with controls to pause or throttle copying when necessary. DBLog became the foundation for connectors used by Netflix’s Delta platform that supports production synchronization and event processing. 

The ROI of Legacy System Modernization

An effective legacy system modernization strategy frees up resources for business growth. By addressing the constraints that make software expensive to maintain and difficult to change, you obtain:

• More budget for innovation. Lower infrastructure and licensing costs free up funds for new product development. Reducing maintenance work also gives engineers more time to build new capabilities.

• Faster time-to-market. Clear component boundaries and reusable APIs reduce the coordination needed to release features or connect new partners.
• More value from existing assets. Preserving proven business logic limits how much functionality teams must rebuild and validate, concentrating investment where improvements matter most.

• Greater capacity for growth. Targeted infrastructure upgrades help systems handle rising demand, while staged migrations reduce the operational risk of introducing changes.

To put the above in monetary terms, modernizing legacy banking applications can reduce  “keep-the-lights-on” costs by 20%-30% and free extra capital for creating better digital user journeys or AI-driven internal products. Mainframe system modernization generates a reported ROI of 288-362%, depending on selected strategies, through better access to underlying data and lower maintenance costs. 

Samsung’s recent database migration makes an even more financially compelling case. The company moved from a legacy Oracle database with 1.1 billion registered users to Amazon Aurora across three regions, keeping source databases operational during migration. The reported results: 

• 44% lower monthly database operational costs, alongside additional savings on Oracle licensing and maintenance
• Latency below 60 milliseconds for 90% of requests, with greater capacity to accommodate growing traffic
• Minimal downtime during the transition, with teams detecting problems quickly to limit user impact
• Faster feature delivery, supported by greater automation

To achieve similar gains, you don’t have to go “disruptive”. As described in this post, you can introduce changes gradually and get incremental value, while existing systems continue to support business as usual. 

Through our legacy software modernization service, we help you identify the highest value-add opportunities incremental modernization can produce for your business. It combines in-depth system audits with hands-on engineering and proactive support during and post-rollout. 

Talk to our team about reducing legacy costs while keeping your business running.