Integrating Systems Without Replacing Them

Operational processes rarely live in one system. A team may use one platform for finance, another for customer or supplier records, shared drives for documents, and spreadsheets for the work that falls between them.

Connecting established tools is often the more proportionate first step. A focused integration can improve the workflow sooner while allowing each system to keep doing the job it already does well.

Map the work between systems

Start with the operational journey before choosing the integration method. Identify where information originates, who acts on it, what changes during the process, and which system should hold the final result.

The gaps usually appear at handoffs:

• a document arrives before its related record exists;
• an identifier differs between two platforms;
• a status change needs a manual update elsewhere;
• an approval happens in email and is not visible to the wider team;
• reporting requires several exports to be combined.

These are good candidates for a tailored operational layer because they are cross-system problems rather than missing features in only one application.

The connection may use a modern API, but it might also depend on a scheduled CSV, SFTP exchange, or EDI message. The important controls remain the same: defined ownership, monitored delivery, and a visible path for failures.

Give each record a clear source of truth

Define which platform owns each important piece of information and how updates are allowed to flow. Each system should only change the fields it is responsible for.

For example, a finance system might remain authoritative for posted invoices, while an operational workflow owns the investigation and approval state before posting. The integration passes the approved result back without trying to duplicate the finance platform.

Clear ownership prevents loops, conflicting updates, and uncertainty about which value people should trust.

Design for mismatches

Real data does not always join cleanly. Names vary, identifiers are missing, records arrive out of order, and older systems may expose only part of the information a workflow needs.

The integration should make those mismatches visible. It should distinguish between a temporary delay, a value that can be mapped safely, and a conflict that needs a person to decide.

Design the exception path with the main data flow. Otherwise, a technically successful connection can still leave the operational team managing failures in spreadsheets and messages.

Coordinate the process in one place

A tailored interface can bring together the relevant context, present the next action, and write the result back through controlled integrations.

A working layer can coordinate the process between systems:

• queues for items requiring attention;
• forms for consistent decisions;
• document and transaction context;
• approvals and audit history;
• reporting across the full workflow.

The underlying platforms remain in place, while the operational experience becomes more coherent.

Prefer observable integrations

An integration needs to explain what happened when something fails. Record the source event, attempted action, response, retry state, and any human decision. Use language that an operational owner can understand rather than exposing only technical error messages.

Observability also helps teams distinguish a one-off technical problem from a recurring process issue. Repeated failures may indicate poor source data, an unclear ownership rule, or a partner process that needs attention.

Change in manageable steps

Cross-system work is easier to improve when it is divided into useful increments. Start with one meaningful handoff or exception queue. Prove the ownership rules, integrations, and user experience before expanding the operational layer.

This reduces risk and creates feedback from real work. It also avoids designing a large replacement programme around assumptions that have not yet been tested.

Know when replacement is the better decision

Replacement becomes the better decision when support has ended, security or access controls are inadequate, critical data cannot be retrieved reliably, or the platform prevents essential process change. Treat that as a separate operational case with its own scope and risk.

When the core systems remain useful, a focused operational layer can coordinate the work between them, preserve each source of truth, and create a manageable path for future change.