Making two systems agree on one record
interoperable
This is the hardest part of most large programmes and the part that decides whether the rest of it works. It is also the part that is quoted as a line item and discovered as a project.
Integrate at the document, not the database
Two systems rarely share a schema, a lifecycle or a vocabulary, and table-level replication couples two release cycles that have to stay independent. Mapping the documents both sides already treat as authoritative is slower to design and dramatically cheaper to live with — it is also what an auditor asks to see when the two disagree.
Publish the health of the integration
Integrations fail quietly. The usual first symptom is a user insisting the system is broken while a dashboard says it is fine. Health, integration status and a public status surface are first-class endpoints in what we build, so the people who depend on it can see its state without calling anyone.
The counterpart system is not yours to change
Most integration work happens against a platform you do not control, cannot take offline and may not get documentation for. That constrains everything: read-only where possible, idempotent writes, retries with backoff, and a replay path for the day the other side is down for six hours. Designed in, these are unremarkable. Retrofitted, they are an incident.
- Legacy and third-party platform integration
- Document and schema mapping between systems
- Cross-engine databridges, SQL Server to MySQL
- Versioned REST APIs with health and status surfaces
- 01A versioned REST API with health, status and integration surfaces
- 02Document and schema mapping, written down and tested both ways
- 03Idempotent writes, retry policy and a replay path for outages
- 04Credentials held where you can rotate them without us
Staff reconcile two systems by hand and the numbers disagree
A platform you depend on has no usable API and no owner who will change it
Nobody can say whether an integration is currently working
- 03
Systems Integration API
A production REST API bridging two authoritative systems that each held half of the same record, with public health and status surfaces.
- 01
Operations Command Center
A live executive command centre joining five production databases into a single operational picture.
- 06
Cross-Border Trade Platform
A bilingual trade platform and the mail system behind it — container capacity, sailing dates, shipment tracking and correspondence, all on infrastructure the company owns.
Can you integrate with a system that has no API?
Usually, and the route matters: a supported export, a database read replica, a file drop, or a screen-level automation of last resort. We tell you which one we are proposing, what breaks it, and what it will cost to maintain — the cheap route is often the expensive one by year two.
What about systems on different database engines?
Common, and fine. We have bridged across engines in production; the work is in the mapping and the failure modes, not the driver.
Do we have to take anything offline?
No. Integration work is designed to run beside what exists, read-only until the moment you decide otherwise, because the systems being joined are usually the ones that cannot stop.
Who keeps it working afterwards?
Your team, with runbooks written for an engineer who has never met us, or us under a support arrangement you can end. Both are on /capabilities/handover-support.
Start here
Bring us the problem nobody has solved.
A 30-minute technical briefing. We will tell you what we would build, roughly what it costs, and honestly whether we are the right people for it.
- ask@madsoftech.com
- Telephone
- +220 872841578
- Office
- Brusubi, The Gambia