Integration and data migration that survives production
Two systems that were never designed to talk to each other now have to agree, continuously, while both keep changing. That is the work. It is unglamorous, it is where the money is lost when it goes wrong, and it is what I have spent ten years doing.
The promise is not that I will connect your systems. It is that your integration survives a replay, a spike, and an outage.
Where it actually goes wrong
Almost every integration demo works. The failure mode shows up months later: a webhook is delivered twice and a record is double-counted, a downstream API is briefly slow and the queue backs up into a timeout cascade, a migration runs and nobody can prove afterwards that the two sides match.
None of those are exotic. They are the default outcome of an integration built for the happy path — and they are expensive precisely because they surface as a data problem long after the code shipped.
What you get
- Idempotent ingestion
- Keyed on the provider's own event ID, so the second and third delivery of the same event are inert rather than destructive.
- Back-pressure that holds
- Queue-based decoupling with retry scopes and dead-letter queues, so a slow downstream degrades throughput instead of losing data.
- Reconciliation and backfill
- A way to answer 'do these two systems actually agree?' with a query rather than an opinion, and a way to repair them when they do not.
- Migration you can verify
- Cutover plans with a reversible path and a count that ties out on both sides before anyone declares victory.
Where I have done this
- As an employee of a consultancy: contributed to a 25+ API micro-service architecture carrying a contractual 1,000 req/sec SLA for a major Canadian airline — booking, seat maps, flight search and automated baggage handling. It met the SLA in production.
- Salesforce ↔ PeopleSoft bi-directional sync, and SAP HANA B1 integrated over OData.
- FINTRAC reporting extracted from a white-labeled vendor platform running a live ATM network — the system of record belonged to someone else, and the regulator did not care.
- Idempotent webhook ingestion keyed on provider event IDs, plus anonymous-to-identified event backfill, in KeystoneOS.
- Salesforce Platform Events & CDC
- SAP HANA B1 over OData
- MuleSoft Anypoint, DataWeave, API Manager
- Azure Service Bus back-pressure
- DLQs, retry scopes, reconciliation & backfill
- Salesforce ↔ PeopleSoft bi-directional sync
Describe it in a paragraph.
Tell me what the system is, what it is doing wrong, and what has to be true by when. I will tell you whether I am the right person for it — including when I am not.
The other three
- Platform builds, zero to production
Built and shipped, not prototyped — auth, billing, tenancy, queues and observability included.
- AI systems that do real work
Sold on the auditing, cost control, idempotency and evaluation — the parts that decide whether it survives contact with production.
- Technical due diligence & rescue
A fixed-scope audit of a stalled or inherited system, delivered as a prioritized roadmap you can act on.