4 Approaches to Legacy System Modernisation (And How to Choose the Right One)

If you are reading this, you are probably wrestling with a legacy system that your business depends on but your team increasingly struggles with. The question is not whether the system needs modernisation — it is how to go about it.

Too many businesses default to one of two extremes: rip-and-replace everything, or do nothing at all. Both are expensive in different ways. A full replacement carries enormous risk, with Gartner reporting that more than 55% of ERP replacement projects fail to meet their objectives, and Panorama Consulting putting the figure closer to 60% for large-scale implementations. Doing nothing, meanwhile, lets the productivity drain continue unchecked — your team works around the system rather than through it, data integrity erodes, and the gap between what your system can do and what your business needs only widens.

There is a middle ground. In fact, there are four distinct approaches to modernising a legacy system, and the right one depends entirely on your specific situation: what the system does, who uses it, what is actually causing the pain, and what your business can afford in terms of cost, time, and disruption. The approach that worked for a manufacturer with a modern ERP and a broken interface will be completely wrong for a company running a 30-year-old custom application written in a language nobody remembers.

This guide lays out all four approaches with enough technical depth for a decision-maker to evaluate each one fairly. It explains when each approach works, when it does not, and gives you a practical decision framework for choosing the right path forward.

Not All Legacy Systems Are the Same

Before we examine the approaches, it is worth acknowledging something important: the term “legacy system” covers a vast range of software, and the right modernisation strategy depends on which category your system falls into. A 20-year-old mainframe handling financial transactions for a bank is a very different proposition from a five-year-old SaaS platform that your team simply does not like using.

A legacy system might be:

• A well-functioning ERP that your team finds unintuitive and slow, leading to workarounds and lost productivity
• A custom-built application written in a language nobody in your team remembers, with no documentation and a single person who “knows how it works”
• An off-the-shelf product that is no longer supported by the vendor, meaning every bug is permanent and every security vulnerability is a risk
• A critical database buried behind a terminal interface with no API, no web access, and no way to connect modern tools to it
• A system of record that other tools need to talk to but cannot, forcing manual data entry and reconciliation between systems
• A monolithic application that handles too many business functions in one tightly coupled codebase, making any change slow and risky

Each scenario demands a different approach. The danger of a one-size-fits-all strategy is that you either over-invest (replacing something that only needs a better interface) or under-invest (patching around a system that needs fundamental change). Getting the diagnosis right is the most important step — and it is surprisingly common for businesses to spend months evaluating replacement platforms before realising that the interface was the only thing wrong with the current system.

Let us look at the four approaches available, starting with the one that applies to the widest range of situations.

Approach 1: Wrap and Extend (Interface Layer)

The wrap-and-extend approach builds a modern frontend over your existing legacy system, connecting through whatever interface the legacy system provides — an API, a database connector, or even screen-scraping in extreme cases. The legacy system remains untouched. A new application layer sits on top, giving users a modern experience while the old system continues to handle the underlying logic and data.

This is the approach Sysgraft specialises in, and it is the right choice in more situations than most businesses realise. It is particularly effective when the legacy system is a well-established ERP, accounting platform, or custom application that the business relies on for core operations.

Architecture overview

A new web application layer (typically built with React, Next.js, and TypeScript) connects to the legacy system through an API adapter. The adapter handles authentication, request/response translation, caching, and any idempotency logic needed for write operations. Users interact with a modern, role-specific frontend. The legacy system continues to run as the system of record, completely unaware that a new interface exists. The adapter layer acts as a buffer: if the legacy system changes, only the adapter needs updating.

Critically, this approach decouples the user experience from the underlying technology. Your team gets a modern interface designed around how they actually work. The legacy system continues handling transactions, business logic, and data storage as it always has. Neither side knows the other has changed.

Legacy System (ERP / Database / Mainframe)
         │
         │  REST API / ODBC / Custom Connector
         │
         ▼
API Adapter Layer
  · Authentication / authorisation
  · Request/response translation
  · Caching layer (Redis)
  · Idempotency for writes
         │
         ▼
Modern Frontend Application
  · React / Next.js / TypeScript
  · Role-specific dashboards
  · Real-time data, search, automation

When to use it

The wrap-and-extend approach is the best choice when:

• The legacy system works — the data model and business logic are sound, but the interface is frustrating
• Users are complaining — the system works for the IT department, but the people who use it every day find it slow, confusing, or both
• You want zero disruption — the legacy system continues running untouched, meaning no data migration, no downtime, and no retraining on core processes
• You need results quickly — an interface layer can be built in weeks, not months or years

Benefits

• No data migration required — the legacy system remains the single source of truth
• Lowest risk of all approaches — the legacy system is not modified, and users can fall back to the original interface at any time
• Fast delivery — 4–12 weeks for most projects, not months or years
• Users get a modern experience immediately, typically with significant productivity improvements from day one
• Opens integration possibilities — the interface layer can expose data to other systems via its own APIs
• The legacy system can still be replaced later if needed — the interface layer decouples the frontend from the backend, so when you eventually replace the backend, only the API adapter needs updating
• No retraining on core processes — the underlying business logic and workflows remain the same

Limitations

• Does not fix problems in the underlying legacy data model or business logic — if the data model itself is broken, a new interface will not fix it
• Requires the legacy system to have some kind of accessible interface (API, database access, screen-scraping, etc.)
• Adds a layer of complexity to the overall architecture — you now have a frontend system that depends on a backend system
• The legacy system still needs to be maintained and supported — it does not go away
• API rate limits and performance constraints in the legacy system may affect the interface layer’s responsiveness

Approach 2: API Enablement

API enablement is a more targeted version of wrap and extend that focuses purely on data and function access rather than user experience. Instead of building a full frontend, you expose the legacy system’s data and business functions as a set of REST APIs that other systems can consume. The legacy system becomes a service provider within a larger ecosystem of modern applications, analytics tools, and automation pipelines.

How it works

An API gateway or middleware layer sits between the legacy system and consuming applications. This gateway translates the legacy system’s native interface — which might be a flat-file export, a database query, a proprietary protocol, or even a screen-scraping connector — into modern RESTful endpoints. The gateway handles authentication (typically OAuth 2.0), rate limiting, request validation, response formatting (usually JSON), and API documentation (OpenAPI/Swagger).

Consuming applications — a customer portal, a business intelligence tool, a mobile app, an ecommerce platform, or a third-party integration — talk to the API gateway using standard HTTPS calls. They never need to know that the underlying system is a 30-year-old mainframe or a closed-source ERP. The gateway abstracts all that complexity away.

This approach is particularly valuable in organisations that have already invested in a modern application ecosystem but cannot connect it to the legacy system. The APIs become the bridge that allows the old and new worlds to coexist.

When to use it

API enablement is the right choice when:

• Integration is the primary need — you need other systems to read from or write to the legacy application
• The frontend is not the problem — users are fine with the existing interface, but the system is a data island that cannot talk to other tools
• You are building a broader platform — you are moving towards a service-oriented architecture and the legacy system needs to participate
• You have multiple consumers — several different applications need access to the same legacy data

Benefits

• Unlocks data that was previously locked inside the legacy system for analytics, reporting, and automation
• Enables integration with modern tools such as Power BI, Tableau, CRM platforms, and ecommerce systems
• Relatively low-cost compared to building a full interface layer — you are creating APIs, not a frontend application
• Does not change the user-facing legacy system, so there is no retraining or resistance from existing users
• REST APIs are standard, well-understood, and easy for any development team to consume
• Creates a foundation for future modernisation — once the APIs exist, a new frontend can be built on top of them later

Limitations

• Does not improve the user experience — the legacy interface remains exactly the same for existing users
• Only valuable if something actually consumes the APIs — building APIs nobody uses is wasted effort
• Requires the legacy system to expose data in a way that can be mapped to meaningful API endpoints
• May need ongoing maintenance if the legacy system changes, particularly if you are relying on undocumented internal interfaces
• Does not solve underlying performance or reliability issues with the legacy application
• API gateways add a layer of infrastructure that must be secured, monitored, and maintained

Approach 3: Strangler Fig Pattern

The Strangler Fig pattern takes its name from the tropical plant that grows around a host tree, gradually enveloping and replacing it over many years. In software terms, you build new microservices or applications that take over specific functions from the legacy system, one at a time. The legacy system is gradually “strangled” as each function is migrated to the new platform, until nothing remains of the original system.

Martin Fowler and the ThoughtWorks team popularised this pattern in the early 2000s, and it remains one of the most reliable approaches for replacing large, monolithic systems. It is the opposite of a “big bang” replacement, and that is precisely its strength: by breaking the replacement into small, independently deliverable pieces, you dramatically reduce the risk of any single failure bringing the business to a halt.

How it works

You identify specific functions within the legacy system and build modern replacements for them, one at a time. Each replacement is typically built as an independent microservice with its own data store. A routing or proxy layer sits between users and the systems, directing traffic to either the legacy system or the new service depending on which function is being called. As each function is replaced, the routing layer is updated and the corresponding legacy code is decommissioned.

The order of replacement matters. Most teams start with functions that are relatively isolated from the rest of the system (making them lower risk to replace) and that offer clear business value once replaced. Over months or years, the entire system is replaced without a big-bang migration. The legacy system shrinks gradually until nothing remains.

               Routing Layer
              /              \
             ▼                ▼
    Legacy System        New Services
  · Order management    · Inventory (Migrated)
  · Invoicing           · Customer portal (Migrated)
  · Stock control       · Reporting (Migrated)
  · Reporting           · Order management (In progress)

When to use it

The Strangler Fig pattern is the best choice when:

• You eventually want to replace the legacy system entirely, but cannot afford the risk of a big-bang migration where everything goes live at once
• The system is large and tightly coupled — it manages many business functions that cannot all be replaced at once without unacceptable risk
• You have the time and budget — strangulation typically takes 12–36 months, which requires sustained investment and organisational commitment
• You need continuous operation — the business cannot tolerate any downtime during the transition, which rules out a big-bang replacement
• You want to prove value early — each replaced function delivers immediate benefit, reducing the overall risk of the programme and building confidence for subsequent migrations
• The legacy system is stable enough to continue running alongside new services for an extended period

Benefits

• Lowest risk path to full replacement
• Continuous operation throughout the transition
• Each migration delivers incremental value
• Lessons learned from early migrations inform later ones
• Allows you to prioritise the functions that deliver the most benefit first

Limitations

• Long timeline — 12–36 months is typical
• Requires a routing or proxy layer to manage traffic between old and new
• The legacy system and new services must run in parallel, increasing operational complexity
• Data synchronisation between old and new systems can be challenging
• Not suitable when the legacy system is so fragile that it cannot continue running during the transition

Approach 4: Database-Level Interface

This is the most cautious approach, and it should be used sparingly and with full awareness of the risks. When a legacy system has no API, no accessible extension mechanism, and no practical way to wrap it, you may need to access the underlying database directly. This is almost always limited to read-only operations — writing directly to a legacy database is almost never advisable.

We include it here because it is a real technique used in practice, and for some businesses it is genuinely the only viable option in the short term. But it carries significant risks that must be understood and managed carefully.

How it works

A lightweight service connects directly to the legacy system’s database (SQL Server, Oracle, DB2, PostgreSQL, or whatever the underlying store may be). This service executes read-only queries against the database tables and exposes the results through a REST API or directly into a modern frontend application. The service never writes to the database — it only reads data that already exists. Any write operations must still go through the legacy system’s own user interface.

The key constraint is that you are reading the database exactly as the legacy application left it. You get raw data without the benefit of the application’s business logic, calculated fields, security rules, or contextual interpretation. This is fine for reporting and dashboards where you can apply your own transformations, but it is not suitable for operational workflows that depend on the application’s internal logic.

When to use it

Database-level access is the right choice when:

• The legacy system has no API whatsoever and no other extension mechanism exists
• The vendor is defunct or unresponsive, so there is no path to adding an API through official channels
• The system cannot be extended — no plugin architecture, no customisation layer, no SDK, no supported integration surface
• A full replacement is planned but not yet affordable or ready — this approach buys time while a longer-term solution is developed
• You need read-only data for reporting, dashboards, or analysis, and you have a clear understanding of the risks involved
• The database schema is documented and stable, and you have database expertise on your team

Benefits

• Works even when every other approach is impossible — it is the option of last resort
• Relatively simple to implement technically — direct SQL queries are well understood
• Can be a temporary bridge while a longer-term strategy is developed, buying months or years of time
• Low cost of implementation compared to other approaches
• Can deliver quick wins for reporting and analytics that are otherwise impossible

Limitations

• Read-only — you cannot safely write back through the database without bypassing business logic and validation
• Bypasses the application layer entirely, meaning you lose business logic, validation, security rules, and audit trails
• High risk if the database schema changes unexpectedly (e.g. a vendor update or version upgrade could break your integration silently)
• No guarantee that the database schema is documented, stable, or intended for external consumption
• Your integration is tightly coupled to the database schema, making it fragile — even a column rename breaks it
• May violate licensing terms with the software vendor, potentially exposing you to legal or compliance risk
• Not a long-term solution — it is a bridge, not a destination, and should always have a planned replacement date

Decision Framework: 6 Questions to Determine the Right Approach

Choosing the right approach depends on your specific circumstances. Here are six questions to work through with your team and technology partners. Answering these honestly will narrow your options to one or two viable approaches.

Question 1: Is the legacy system still fit for purpose?

This is the most important question of all. If the system can still do what the business needs — the data model is sound, the business logic is correct, and it processes transactions reliably — then you should keep it and improve the interface around it. That points to Wrap and Extend (Approach 1). If the system itself is fundamentally broken — the data model is obsolete, the business logic is wrong, it cannot handle your current transaction volumes, or it lacks features the business now requires — then you should plan for replacement, likely via Strangler Fig (Approach 3).

Question 2: Where is the pain coming from?

Is the pain in the user interface (slow, ugly, confusing, no mobile support) or in the inability to integrate with other systems (data silos, manual exports, duplication)? Interface pain points to Wrap and Extend. Integration pain points to API Enablement (Approach 2). If both are problems, consider starting with Wrap and Extend — which typically includes API capabilities as part of the build — or a phased approach where you tackle integration first and interface improvements second.

Question 3: Can the legacy system be extended?

Does it have an API, a plugin architecture, customisation layers, or an accessible database? If yes, Wrap and Extend or API Enablement are viable. If the answer is genuinely no — the vendor is gone, the system is completely closed, and there is no interface of any kind — then your options narrow. You may need to consider Database-Level Access (Approach 4) as a short-term bridge, or Strangler Fig (Approach 3) as a long-term strategy. If you are not sure what interfaces your system supports, a technical discovery sprint will answer this question quickly.

Question 4: What is your timeline and budget?

Different approaches deliver at very different speeds. Wrap and Extend typically delivers a working interface in 4–12 weeks. API Enablement can be live in 2–6 weeks. Strangler Fig takes 12–36 months depending on the size and complexity of the system. Database-Level Access can be built in days or weeks but is not a long-term solution. Be honest about your timeline — a 24-month strangulation may be technically elegant, but if your team is at breaking point and revenue is suffering, a faster approach might deliver more value even if it is less architecturally pure.

Question 5: What is your risk appetite?

Wrap and Extend carries the lowest risk because the legacy system is untouched — there is no data migration, no business logic changes, and users can always fall back to the original interface. Strangler Fig carries moderate risk because you are gradually replacing live systems, and the old and new systems must coexist during the transition. Database-Level Access carries the highest technical risk because you are bypassing the application layer, losing business logic and audit trails in the process. If your business cannot tolerate downtime, data loss, or operational disruption, choose the lowest-risk approach that meets your needs.

Question 6: What does the long-term roadmap look like?

Think about where you want to be in five years. If you plan to eventually replace the legacy system entirely, choose an approach that does not paint you into a corner. Wrap and Extend leaves the path to replacement open because the interface layer decouples the frontend from the backend — when you eventually replace the backend, only the API adapter needs updating. Strangler Fig is the replacement path, so it is the right choice if full replacement is the destination. API Enablement and Database-Level Access are intermediate steps, not final destinations — use them only if you have a clear plan for what comes next.

Comparison Table: All 4 Approaches

The table below compares the four approaches across eleven factors that matter when making a technology decision. Use it as a quick reference when discussing options with your team or evaluating proposals from technology partners.

Factor	Wrap & Extend	API Enablement	Strangler Fig	DB-Level Interface
Risk level	Very low	Low	Moderate	High
Timeline	4–12 weeks	2–6 weeks	12–36 months	1–4 weeks
Relative cost	Low–medium	Low	High	Very low
Data migration?	None	None	Gradual	None (read-only)
User impact	Modern frontend	No UX change	Gradual improvement	Depends on use
Integration value	High	High	Medium	Low–medium
Write-back support	Yes	Yes	Yes (in new services)	No (read-only only)
Legacy unchanged?	Yes	Yes	Gradually replaced	Yes
Requires API?	Yes (or DB access)	Yes (or DB access)	Not necessarily	No (DB access only)
Longevity	Medium–long	Medium	Permanent (end state)	Short (bridge only)
Vendor lock-in	Reduced	Reduced	Eliminated	Increased