How to connect existing business systems without replacing everything

What this looks like in real projects

Sainsbury’s: bridging older, vendor and new systems

In Cloudini’s original client testimonial, Fraser Pearce, Senior Engineering Manager at Sainsbury’s, described software that bridged interactions between older, less flexible systems, vendor solutions and newly built systems.

He reported that the software remained in active use five years after its creation, beyond its original interim scope. That is a historical client account, rather than a current availability measurement. It also illustrates an important planning consideration: an integration introduced as a temporary bridge may need to be maintained for longer than initially expected. Read the Sainsbury’s account.

Power to Live Foundation: connecting registration and patient management

Power to Live Foundation needed to improve its patient registration process. In the charity’s original testimonial, CEO Tien Kuei described how Hassan reviewed the process with the team and how Cloudini connected registration to the patient management software.

The account describes a focused integration around an existing workflow. It does not establish a percentage saving, a particular technology stack or the elimination of every manual task. Read the Power to Live Foundation account.

These are different engagements, but both provide examples of connecting systems around a practical business need.

Start with one workflow

Before selecting an integration platform or commissioning software, describe the journey that needs to work.

For example, a service business might want an accepted quotation to create a job record, with the completed job then becoming available for invoicing. That is a more useful starting point than a requirement to “connect everything”.

Write down:

• What starts the process?
• Which information must move?
• Which system receives it?
• What needs approval?
• How will someone know the transfer succeeded?

Include the exceptions. A cancelled job, incomplete customer record or changed price may matter as much as the normal sequence.

Choose a first workflow with a clear boundary and an outcome you can test.

Decide which system owns each piece of information

Connecting applications does not automatically make their records consistent.

You might decide that the CRM owns customer contact details, the operational application owns job status and the accounting system owns payment status. Those decisions need to be explicit.

Then agree how records will be matched. A customer’s name alone may be insufficient where names change or several customers share the same name. Define the identifiers and matching rules before transferring live data.

Also decide what happens when the systems disagree. Should one value take precedence, should the update be rejected, or should a person review it?

These are business decisions as well as technical ones.

Connect through a supported interface

Investigate the interfaces the existing systems actually provide.

A supported API may offer a suitable connection. In another application, a documented import or export process may be the practical starting point. Check permissions, vendor restrictions, data formats and operating limits before choosing an approach.

Where applications represent information differently, an adapter can translate between their formats and meanings. Microsoft documents this separation through its Anti-Corruption Layer pattern. The adapter is also another component to maintain, monitor and account for in performance planning. Microsoft’s architecture guidance.

Avoid assuming that direct database access is a shortcut. Review whether it would bypass application rules or create dependencies on a structure the supplier may change.

Plan for failures before launch

A connection needs an operating plan alongside its normal workflow.

Consider what happens when the receiving application is unavailable, a record is incomplete or the same request arrives twice.

For an invoicing integration, for example, retrying a transfer should not unintentionally create another invoice. Define how requests are identified, how completed work is recognised and how uncertain outcomes are reconciled.

Before release, agree:

• How failed or delayed transfers become visible.
• Who investigates them and controls retries.
• What information is recorded for troubleshooting.
• How access is restricted to the data and actions required.
• How the integration can be paused safely.

Test these situations in a suitable non-production environment. Where a transfer changes records in another system, a rollback plan must account for those changes; reverting software alone may not reverse them.

Replace components when the evidence supports it

Integration does not mean keeping every application indefinitely.

An unsupported system, an inaccessible interface or a component that cannot meet agreed security or operational requirements may need replacement. The decision should follow an assessment of its constraints and dependencies.

Where gradual replacement is appropriate, Microsoft’s Strangler Fig pattern describes moving functionality in stages while the existing system continues handling the parts that have not moved. Its suitability depends on the available integration points and how long the old system can remain in operation. Microsoft’s incremental migration guidance.

That approach requires planning for coexistence, validation and eventual retirement. Smaller stages still need release checks and clear responsibilities.

Bring a concrete problem to the first conversation

A useful integration brief can start with one sentence:

When this event happens in one system, this information needs to reach another system, and this person needs to know whether it worked.

Bring the systems involved, a description of the current process and examples of the exceptions. Use anonymised or fictional records for an initial discussion where sensitive information is involved.

From there, the work can be assessed: what can remain, what needs a connection and what genuinely needs replacing.

Cloudini’s Sainsbury’s and Power to Live Foundation accounts show two examples of integration work around existing systems. For your organisation, the starting point is the workflow and the constraints of the applications you already use.

Talk to Cloudini about your systems and integration requirements.