Software

System Integration

Making the systems you already own agree with each other

How this is usually engaged

We scope each connection individually, because "integrate with our ERP" can mean anything from a documented API to a nightly file with no schema. Discovery comes first and is chargeable, since determining what a closed system will actually permit is real work and cannot be estimated from a product name.

Start a project brief

Practice: Software Engineering
Sectors: 5 served
Process: 5 stages
Standard: Built and tested to WCAG 2.2 AA

Connecting applications, databases and third-party services so data moves reliably between them, with an agreed source of truth for every field and a defined answer for when something is unavailable.

01What this solves

The problem this addresses

Integration failures are rarely technical at heart. They happen because two systems both believe they own the customer record, because nobody defined what should happen when one of them is down for an hour, or because a nightly export has been silently failing since a password changed. The visible symptom is staff reconciling by hand and reports that disagree. The underlying cause is ownership of data never having been decided.

02Capabilities

What is included

Data mapping and ownership

Field-level mapping across systems with an agreed authoritative source for each, including the identity matching that decides when two records are the same entity.

Synchronisation design

Direction, trigger, frequency and conflict resolution per entity, with idempotent processing so retries and replays cannot duplicate records.

Legacy and file-based interfaces

Working with what a system genuinely offers — scheduled file drops, database views, SOAP endpoints or screen-level exports — when no modern API exists.

Middleware and queuing

A message layer between systems where volume or availability requires it, so one system being offline delays delivery rather than losing data.

Monitoring and reconciliation

Run history, failure alerting and scheduled reconciliation reports that compare record counts and key totals across systems so drift is found by the system rather than by a customer.

Migration between platforms

One-off moves from a system being retired, with validation, a dry run, a reconciliation report and an agreed cutover and rollback plan.

03Use cases

Where this work usually starts

Orders re-entered into a finance system

Sales records an order in one system and someone types it into another, with the mismatches surfacing at month end.

Retail

Two systems that both claim to be right

Customer or stock records edited in either place, no defined precedence, and staff who have learned which screen to believe.

Logistics & Transport

A retiring platform with years of data

A product reaching end of support, where the migration matters more than the replacement selection.

Healthcare

04Approach

How we approach it

We map the data first: which fields exist in which systems, which system is authoritative for each, and where the same concept is recorded under different names or identities. Only then do we design the movement — direction, trigger, frequency and transformation per field. Every integration is built to be observable, with a run history, alerting on failure, and idempotent handling so a retry after an outage cannot create duplicates. Reconciliation is part of the design, not something the finance team improvises.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

01
System discovery
What each system genuinely exposes, what its licence permits, and what the vendor will support.
02
Data mapping
Field-level mapping with an authoritative owner agreed for each, signed off by the teams who use the data.
03
Failure design
What happens when a system is down, a record is rejected or two changes conflict, decided before build.
04
Build and run in parallel
The integration runs alongside the manual process, with differences reviewed until they stop appearing.
05
Cutover and monitor
Manual entry stops, reconciliation reports are scheduled, and an owner is named for each connection.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

System and data mapFields, systems, authoritative owner and identity matching rules.
Integration specificationsPer connection: direction, trigger, transformation and failure behaviour.
Working integrations with monitoring and alerting
Reconciliation reporting
Operating runbookHow to check status, what each alert means, and how to replay a failed run safely.

07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

TypeScript
Node.js
Python

Data & Storage

PostgreSQL
Redis
Elasticsearch

Cloud Platforms

Microsoft Azure

DevOps & Operations

Docker

The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Integrations authenticate with dedicated service credentials scoped to the minimum required, stored in a managed secret store and rotated on a schedule. Data in transit is encrypted, and payloads containing personal data are logged by reference rather than in full so diagnostics do not become a second copy of your records. Where a supplier requires a network path into your environment, we use restricted, monitored access rather than broad connectivity.

Our full security and quality approach

09Questions

Asked before we start

Our vendor says our system cannot be integrated. Is that true?

Sometimes it is, and more often it means no documented API exists while a database view, scheduled export or supported file format does. Occasionally the licence forbids direct access, which is a commercial obstacle rather than a technical one. We establish what is genuinely possible during discovery and tell you plainly when the honest answer is that the system has to be replaced.

Which system should be the source of truth?

It is decided per field rather than per system, and it is a business decision we facilitate rather than make. Usually the system where the data is first created and where staff naturally correct it should own it. What does not work is two systems both accepting edits to the same field with no precedence, which is the root of most integration disputes we are asked to resolve.

Should we buy an integration platform instead?

If your systems are mainstream products with ready connectors and your logic is simple, a subscription platform is usually cheaper and faster than custom work, and we will recommend that. They become poor value when connectors do not exist, when transformation logic is genuinely complex, or when per-record pricing meets high volume. Either way, the data mapping work still has to be done.

How do you avoid duplicate or conflicting records?

Identity matching rules are agreed explicitly during mapping — which fields determine that two records are the same entity, and what happens when the match is ambiguous. Processing is idempotent, so a replayed run updates rather than duplicates. Ambiguous matches go to a review queue for a person to decide rather than being resolved by a guess.

START HERE

Talk to us about System Integration

The project brief takes about five minutes and gives us enough to have a useful first conversation about System Integration rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a project Send a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.