Wrapping a legacy field-service platform in a modern integration layer

The client sells appliance protection memberships and dispatches technicians across an island market. Work orders lived in a long-established field-service platform, payments in Stripe, retail in Shopify, customer messaging in a CRM, and member records in a database the field-service vendor could not see.

Staff re-keyed the same customer into three screens. Nobody could answer a simple question like "is this member paid up, and is a tech already booked?" without opening every tool.

• Replacing the field-service platform was off the table. It held years of job history and the technicians were trained on it.
• Its API was inconsistent: some write calls returned success without returning an identifier, and paginated reads returned the same page twice.
• The membership database had already been paused once by its host over billing, so anything business-critical could not depend on it alone.

1. 01Strangler pattern, not a rewriteEach workflow (enrollment, booking, payment, dispatch) moved behind the new layer one at a time. The legacy platform kept running the whole time and stayed the system of record for jobs.
2. 02One adapter per vendorEvery outside system is reached through a single module that normalizes its quirks: retries, pagination, field mapping, the write call that returns no ID. Nothing else in the codebase calls a vendor directly.
3. 03Ledgers outside the primary databaseDeal intake and dispatch state are written to an append-style blob ledger, so the staff board keeps working and keeps telling the truth even if the main database is unavailable.
4. 04Dead-letter and retryA write that fails upstream is parked with its full payload and reason, surfaced to staff in plain English, and retried on demand. Nothing fails silently.

• Two separate identity paths: members by verified email or phone, staff by PIN with role-based permissions. A member token can never reach a staff route.
• Every vendor secret lives in the hosting provider's encrypted environment, never in the repository or the browser bundle.
• Per-endpoint rate limiting on login and intake routes.
• Inbound webhooks authenticated by signature or shared key before any parsing.
• A data-erasure function so a member's records can be removed on request across connected systems.

• Creating the member in the CRM, the billing system and the field-service platform
• Checking payment status before a booking is accepted
• Opening a CRM opportunity and texting the member when a deal arrives from any source
• Creating the field-service work order from an approved booking
• Retrying failed vendor writes and surfacing the reason to staff

~10 min

Re-keying removed per new member

One record typed into three tools at roughly 3 minutes each, now entered once.

4 to 1

Screens per customer question

Billing, CRM, field service and member database collapsed into one console.

0

Manual hand-offs from deal to work order

All four hops run automatically; staff only act on a red step.

Time figures are estimates per unit of work, based on the manual steps the build removed. Every other number on this page is measured.

Staff work from one admin console with tabs for members, pipeline, store, parts and dispatch, instead of four vendor UIs.

Every deal shows four fixed hops (received, CRM opportunity, member texted, work order) with the exact reason when one stalls.

The integration layer exposed an upstream defect that had been invisible for months: the field-service API was accepting job creation and returning no job. That is now a tracked vendor issue with evidence attached, not a mystery.