How to Connect Legacy Systems Without Replacing Your Entire IT Stack

Why legacy modernization matters in Japan

Japan has been discussing the legacy-system challenge for years, but the issue remains highly relevant. In 2025, METI’s Legacy Systems Modernization Committee concluded that legacy systems continue to hinder the introduction of newer digital technologies and can reduce companies’ ability to respond to changing business conditions.

The committee did not treat modernization as merely a software-replacement exercise. Its recommendations included improving visibility into IT assets, strengthening IT governance, increasing the autonomy of information-system departments, improving collaboration with business divisions, and changing how companies cooperate with vendors. That is an important lesson. Legacy modernization is as much about architecture, governance, ownership and business processes as it is about the age of the technology.

First: what actually makes a system “legacy”?

The word legacy is often used as if it means “bad.” That is too simplistic. A system can be old and still be useful. The more important warning signs are things such as:

• it cannot communicate easily with newer systems;
• changes take too long or require rare specialist knowledge;
• business-critical logic is poorly understood;
• data is trapped inside departmental silos;
• manual workarounds have grown around the system;
• security or support risks are becoming unacceptable;
• the company cannot adapt processes without modifying the core application.

A system becomes a modernization problem when it constrains the business—not simply when it has existed for many years.

Three modernization choices: connect, modernize progressively, or replace

This decision should not be binary.

This is not a maturity ranking. A company that deliberately keeps a reliable ERP while modernizing everything around it may be making a better architectural decision than a company that replaces a core platform unnecessarily.

What “connect the legacy system” actually means

Modern integration is not simply copying data between two databases. A connection layer can perform several jobs:

• Expose selected legacy capabilities through APIs or connectors.
• Transform data from one format into another.
• Orchestrate business workflows across several applications.
• Control when information may be read or written.
• Monitor failures and exceptions.
• Present modern web or mobile interfaces without changing the core application.

Fluyenta’s integration capability, for example, supports cloud and on-premise connections, REST/SOAP APIs, data transformation and secure gateway-style connectivity for systems protected behind corporate networks. The architectural idea is more important than any one platform: The legacy system continues doing what it does well. A modern layer handles the interactions it was never designed to manage.

Diagram 1 — Modernization without a full replacement

A useful architecture looks like this:

The legacy application does not disappear. Its role becomes clearer. Users interact with a modern process, while integrations handle the underlying systems.

Pattern 1: Put an API or integration layer in front of the legacy system

If a legacy application already exposes an API, web service, database interface or other stable integration point, a modern workflow can communicate through it. For example:

1. 1New customer approved in CRM
2. 2orchestration workflow
3. 3data validation
4. 4legacy customer system API
5. 5confirmation returned

The user does not need to operate the legacy interface directly. The modern process interacts with the system on their behalf. If the legacy platform does not expose a modern REST API, other options may include SOAP services, controlled database interfaces, files, queues or vendor-supported connectors. The correct approach depends on the system. Avoid creating direct, undocumented database dependencies merely because they are quick.

Pattern 2: Place a workflow layer around the core system

Some of the most valuable modernization occurs before and after the legacy transaction. Imagine an ERP that handles purchase orders well but has a cumbersome approval process. Instead of heavily customizing the ERP:

1. 1Employee request
2. 2modern approval workflow
3. 3policy validation
4. 4human approval
5. 5approved transaction sent to ERP

Fluyenta describes this approach explicitly for SAP: approvals and validations can occur outside the SAP core, data can be synchronized with surrounding systems, and low-code applications can sit on top while leaving the core system largely untouched. This principle can apply beyond SAP. The goal is to avoid modifying a stable core application every time the business wants to change a surrounding process.

Pattern 3: Give users a modern interface without replacing the backend

One reason companies dislike legacy systems is often the user experience. The underlying transaction engine may work. The interface may not. A modern portal or web application can provide:

• better forms,
• mobile access,
• role-specific screens,
• search,
• status tracking,
• document uploads,
• or customer/supplier self-service,

while sending approved data to the existing backend. That can create significant user improvement without performing a full core-system migration.

Pattern 4: Synchronize data carefully

Connecting systems creates another question: Which system owns the truth? Suppose a customer exists in:

• CRM,
• ERP,
• service-management software,
• and a reporting database.

• Which system owns the legal customer name?
• Which owns the sales contact?
• Which owns payment status?
• Which system is allowed to overwrite another?

Without answering those questions, integration can make bad data move faster.

This table is only illustrative. Each company needs to define its own ownership model. The important part is having one.

Why common data definitions matter

System integration fails surprisingly often because two applications use the same word differently.

• “Customer” may mean a legal entity in ERP but an individual contact in CRM.
• “Approved” may mean commercially approved in one system and technically approved in another.
• “Project code” may have different formats between departments.

Japan’s Digital Agency addresses the broader interoperability problem through its Government Interoperability Framework, which provides reference data models intended to improve consistent data exchange and system interoperability across government information systems. While GIF is a government framework rather than a private-sector requirement, the architectural principle is broadly relevant: systems interoperate more effectively when the structure and meaning of exchanged data are defined consistently. Integration is therefore not just: System A can call System B. It is also: System A and System B agree on what the information means.

Diagram 2 — Bad integration versus governed integration

The second architecture does not mean every company needs one giant central platform. The principle is to control integrations intentionally rather than allowing every system to create unmanaged one-off connections to every other system.

The danger of integration spaghetti

Connecting legacy systems badly can make the architecture worse. Imagine ten applications. If every application integrates directly with every other application, a small change can affect many connections. Over time:

• nobody knows who owns an interface,
• credentials are duplicated,
• data transformations are repeated,
• business logic exists in multiple places,
• errors are difficult to trace,
• and replacing one application becomes even harder.

That is why an integration or orchestration layer should ideally centralize reusable connectivity and make dependencies visible. Fluyenta’s platform groups integration, workflow, data management, API management, monitoring and governance within a common controlled environment rather than treating each connection as an isolated script.

Pattern 5: Use events where real-time synchronization is unnecessary

Not every process requires constant real-time synchronization. Sometimes the right approach is:

1. 1event occurs
2. 2publish event
3. 3interested workflow responds

For example:

• Supplier approved.
• Equipment fault detected.
• Invoice posted.
• Employee created.
• Shipment dispatched.

The event can trigger whichever process needs to respond. This reduces tight coupling between applications. Other cases may work perfectly well with scheduled synchronization or batch files. “Real time” is not automatically better. The architecture should match the business requirement.

Pattern 6: Use a portal to protect the core system

External users create a specific modernization challenge. Giving suppliers or customers direct access to an old internal application may be undesirable or impossible. Instead:

1. 1Supplier
2. 2modern portal
3. 3workflow
4. 4validation
5. 5integration
6. 6legacy ERP

The supplier experiences a modern application. The internal ERP remains protected behind the business process. This pattern is particularly useful where outside organizations need to:

• submit data,
• upload documentation,
• receive requests,
• check status,
• or participate in approvals.

Pattern 7: Gradually move business logic out of the legacy system

One of the most useful long-term strategies is to stop adding unnecessary new business logic to the old core. Suppose a legacy application currently contains:

• customer records,
• pricing,
• approval rules,
• document processing,
• notifications,
• reporting,
• and supplier workflows.

Instead of migrating everything at once, the company may progressively move suitable functions outward.

Progressive modernization example

This resembles the broader architectural idea sometimes called progressive or incremental modernization: reduce dependency over time rather than forcing an immediate “big bang.” The important point is that integration can be a transition strategy, not necessarily the permanent final architecture.

A decision table: connect or replace?

No single answer should automatically make the decision. The table helps structure the discussion.

When connecting is the wrong answer

It is easy to become overly enthusiastic about preserving legacy systems. Sometimes replacement really is necessary. Warning signs can include:

• the vendor no longer supports the platform;
• critical security vulnerabilities cannot be remediated;
• required skills are disappearing;
• the architecture prevents necessary regulatory or business changes;
• the system cannot expose or accept data safely;
• maintenance costs continue rising;
• performance or reliability no longer meets business requirements;
• the organization no longer understands critical code or dependencies;
• or integrating around the system would cost more than replacing it.

In that case, an integration layer should not become a mechanism for indefinitely postponing a necessary migration.

Security must be designed into the connection

Every new integration creates an access path. That means modernization must consider:

• authentication,
• authorization,
• service accounts,
• network boundaries,
• secrets,
• API permissions,
• encryption,
• logging,
• audit trails,
• data minimization,
• and failure behavior.

A technically successful integration that exposes a legacy database too broadly is not successful modernization. Fluyenta’s public architecture combines integration with role-based access, governance, auditability, monitoring and controlled deployment rather than treating connectivity as an isolated capability.

What about systems that have no API?

This is common. The correct answer depends on the application. Possible approaches can include:

• vendor-supported web services,
• SOAP,
• controlled database access,
• message queues,
• secure file exchange,
• scheduled imports/exports,
• connectors,
• gateway agents,
• or, in carefully justified cases, UI-level automation.

The priority should be the most stable and supportable interface available. Avoid starting with brittle screen automation merely because it appears fast. If the vendor offers an official integration interface, that is usually a better place to investigate first.

Monitoring is not optional

Connecting two systems introduces failure states that did not previously exist.

• The CRM may be available while ERP is down.
• A token may expire.
• A data field may change.
• A record may be rejected.
• A message may be duplicated.

Therefore the architecture must answer:

• How do we know an integration failed?
• Who gets notified?
• Can it retry safely?
• How do we avoid duplicate transactions?
• Can we see what data moved?
• Can we replay the process?

The invisible integration layer needs operational ownership just as much as the visible application does.

Diagram 4 — What happens when an integration fails?

A practical modernization sequence

A company does not need to begin with technology selection. A better sequence is:

1. Identify the business process

   Which operation is currently constrained?

2. Map the systems involved

   What does each application actually do?

3. Define systems of record

   Which system owns each critical type of data?

4. Identify supported interfaces

   APIs, services, files, databases, connectors, events.

5. Separate core responsibility from surrounding workflow

   What should remain in the legacy system? What can move into the orchestration layer?

6. Build the smallest valuable integration

   Avoid solving the entire enterprise architecture in the first release.

7. Add monitoring and governance

   Treat the integration as production infrastructure.

8. Measure whether the process improved

   Did re-entry decrease? Did processing time improve? Did visibility improve? Are fewer manual workarounds required?

9. Decide the next modernization step

   Connect another process, move another capability outward—or begin replacement if evidence now supports it.

Example: modernizing a purchase process around ERP

Illustrative architecture scenario, not a completed Axton customer project.

Imagine a company has a reliable older ERP. The ERP handles:

• vendors,
• purchase orders,
• accounting,
• and financial records.

But purchase requests currently happen through Excel and email. The company does not necessarily need a new ERP. Instead:

1. 1Employee Request
2. 2Modern Web Form
3. 3Workflow Rules
4. 4Manager Approval
5. 5Finance / Procurement Approval
6. 6Integration
7. 7Existing ERP
8. 8PO / Record Created
9. 9Status Returned to Requester

The company improves the user experience and approval process while preserving the ERP’s trusted transaction engine. Fluyenta describes a similar architectural principle for SAP: automate and validate processes before they reach SAP, synchronize surrounding systems, and build low-code applications on top while leaving the core intact where appropriate.

Example: connecting a legacy production system to a modern portal

Illustrative architecture scenario, not a completed Axton customer project.

Another example: A manufacturer has a production database that cannot realistically be replaced quickly. Customers need better order-status visibility. Instead of giving customers access to the production application:

1. 1Legacy production system
2. 2controlled integration
3. 3orchestration/data layer
4. 4customer portal

The portal shows only the information the customer is permitted to see. The production system remains internally controlled. Eventually, if the production platform is replaced, the portal does not necessarily need to change significantly because it communicates through the integration layer instead of being tightly coupled to the old backend. That is one architectural advantage of decoupling.

Table: old approach versus connected architecture

The purpose is not to make the right-hand column sound universally superior. It illustrates a different architectural choice.

How Axton Group × Fluyenta approaches legacy modernization

Through its partnership with Fluyenta, Axton Group LTD Japan can help Japanese organizations examine modernization from the business process outward. The conversation should not begin with: “Which old system should we replace?” It should begin with: “Which business process is constrained by the current architecture, and why?” Axton can help with Japan-side discovery, stakeholder communication, process understanding and customer coordination. Fluyenta contributes enterprise workflow and integration technology backed by more than 20 years of enterprise process-automation experience.

Its current platform combines workflow automation, integration and connectivity, data management, APIs, governance, monitoring and related capabilities in a controlled enterprise environment. That makes it possible to examine modernization in stages.

The goal is not to preserve legacy systems forever

This point is important. “Do not replace everything immediately” is not the same as: “Never replace anything.”

• Integration can buy time.
• It can improve processes.
• It can reduce disruption.
• It can expose valuable capabilities safely.
• It can help the company understand dependencies before migration.

But every organization should eventually ask: Is this core platform still the right strategic foundation? If yes, keep it and continue improving the surrounding architecture. If no, use what you have learned from the integration and orchestration work to make the eventual migration safer.

Modernization should reduce dependency, not create more of it

A successful modernization program should gradually make the organization:

• less dependent on manual re-entry,
• less dependent on hidden interfaces,
• less dependent on individual employees knowing undocumented procedures,
• less dependent on tightly coupled point-to-point integrations,
• and less afraid to change one system because everything else might break.

That is a better measure of modernization than the age of the software. The end goal is not: “We replaced the legacy system.” The end goal is: “Our systems, data and business processes can change without the organization becoming trapped by its architecture.” Sometimes replacement is necessary to reach that goal. Sometimes it is not. Good modernization is knowing the difference.

Frequently Asked Questions