Integration Platform Migration
I led the migration of a live lab ↔ EMR integration platform, orders and results, from a legacy system to a new one, and assumed operational ownership from the team that had run it before. This was not building new integrations. It was moving 250+ existing connections onto a new platform without disrupting providers, taking over the runbook and on-call, and proving zero data loss end to end. The work turned on a controlled, off-hours cutover and a clean ownership handover, so nothing broke for a practice and nothing fell through the cracks between teams.
250+
Connections migrated
~4 mo
Program duration
Few hours
Off-hours cutover
Zero
Data loss
Move a live platform, and take it over, without disrupting anyone
The system: a legacy system carried the lab's live orders and results integrations, and it was reaching the end of its useful life. A new platform was set to replace it, but the connections, mappings, and operational know-how all lived in the old one.
The ownership gap: the integration was owned and operated by another team. Migrating it meant not just moving data paths, but assuming operations: the runbook, the monitoring, and the on-call, none of which I held at the start.
The task: migrate orders and results for 250+ connections to the new platform and take over running it, with no data loss, no business-hours downtime for live providers, and a full knowledge transfer so my team could own it the day after cutover.
The migration charter
Before touching a connection, I set a charter so every team, including the one handing the platform off, agreed on the goal, the boundaries, and what "done safely" meant. It kept a migration from quietly turning into a redesign.
Goal
Move all 250+ orders and results connections from the legacy system to the new platform, and assume full operational ownership, with no data loss and no provider disruption.
Scope
In: transport and mapping migration, parallel-run validation, off-hours cutover, legacy decommission, and the ownership handover (runbook, monitoring, on-call).
Out: new integration features and EMR-side workflow changes.
Success criteria
- check_circleZero data loss across all connections
- check_circleNo business-hours downtime
- check_circleFull knowledge transfer to the new owning team
- check_circleReversible cutover with a tested rollback
Taking over operations, not just the data paths
A migration is only half done if the new team cannot run what it inherited. I planned the ownership handover as its own workstream, coordinated across the prior owning team, Engineering, Lab Operations, and EMR vendors, so operational knowledge moved with the platform.
Knowledge transfer
Structured sessions with the prior owning team to capture how each connection behaved, the known edge cases, and the operational history that is not written down anywhere, before access changed hands.
Runbook creation
Turned that knowledge into a runbook for the new platform: how to monitor connections, triage transfer failures, and recover, so day-two operations did not depend on the people who left.
On-call handover
Stood up monitoring and on-call for my team and ran a defined handover so responsibility passed cleanly, with the prior team available as backup through the transition window.
The dependency map
The migration depended on four parties lining up. I mapped each one with an owner and a clean handoff, so no connection waited on an unnamed party and nothing was assumed to "just work" on the new platform.
Legacy system
Held the live connections and mappings being moved. Handoff: exported configs and connection inventory. Owner: the prior owning team + Engineering.
New platform
Received and ran the migrated connections. Handoff: validated mappings provisioned and parallel-run before cutover. Owner: Engineering.
EMR vendors
Endpoints on the practice side of each connection. Handoff: confirmed connectivity and any endpoint changes ahead of cutover. Owner: EMR vendors + Engineering.
Lab LIS
Received orders and produced results behind the platform. Handoff: reconciliation against the lab's data contract. Owner: Lab Operations + Engineering.
The cutover plan and sequencing
IllustrativeThe cutover was sequenced to de-risk itself: prove the new platform alongside the old one first, switch over in a tight off-hours window, then retire the legacy system only once everything checked out. Every step had a reversible path.
Step 1
Parallel run & validation
New platform ran beside the legacy system; outputs compared connection by connection until they matched.
Step 2
Off-hours cutover
Traffic switched to the new platform in a few-hour window outside business hours, so no practice saw downtime.
Step 3
Decommission legacy
Legacy system retired only after post-cutover reconciliation confirmed every connection was healthy.
Rollback: because the legacy system stayed live through the parallel run and was not decommissioned until after sign-off, the cutover was reversible. If post-switch checks had failed, traffic could fall back to the legacy system with no data loss, and decommission would simply wait.
Risks, assumptions, issues & dependencies
IllustrativeI ran a living RAID log and worked it every cadence. For a migration, the point was to name the ways data or knowledge could be lost, and close each one before cutover.
| Type | Item | Severity | How I unblocked it | Owner |
|---|---|---|---|---|
| Risk | Data loss during the move | Parallel ran both systems and reconciled record counts per connection before and after cutover. | Engineering | |
| Risk | Mapping drift between platforms | Validated each migrated mapping against the lab's data contract and flagged mismatches in the parallel run. | Engineering + Lab Ops | |
| Issue | In-flight orders during cutover | Scheduled the switch off-hours and drained in-flight messages so nothing was mid-transfer at the cutover point. | Engineering + PM | |
| Dep. | Knowledge gaps from the handover | Ran structured knowledge transfer and built a runbook before access changed hands, with the prior team on standby. | Prior team + PM | |
| Assum. | Off-hours window is low traffic | Confirmed traffic patterns before scheduling the cutover so the window genuinely avoided business hours. | PM |
Proving zero data loss across 250+ connections
"Zero data loss" only counts if you can show it. The validation approach made it a measured result, not a hope: compare both systems while they ran together, reconcile what flowed, and sign off connection by connection before anything was retired.
Parallel-run comparison
With both systems live, orders and results were compared side by side so any divergence surfaced before the switch, not after.
Record reconciliation
Record counts were reconciled per connection across the cutover, so a missing or duplicated message would show up against the expected totals.
Sign-off before decommission
The legacy system was not retired until each connection passed reconciliation and was signed off as healthy on the new platform.
Result: all 250+ connections reconciled with zero data loss, and the legacy system was decommissioned only once every connection was confirmed healthy on the new platform.
The outcome
250+
Connections migrated
Zero
Data loss
20+
Team coordinated
1k+
Transactions handled
Verified outcome: 250+ connections migrated to the new platform in a roughly four-month program, with a few-hour off-hours cutover, zero data loss, and ownership fully transferred so my team ran the platform from day one.
What I'd carry forward
- check_circleParallel-run before you commit. Running both systems side by side and reconciling per connection was what turned "zero data loss" from a goal into something I could prove, and what made the cutover reversible. I would never migrate a live data path without it.
- check_circleTreat the ownership handover as a real workstream. The risk in a takeover is not the data, it is the undocumented knowledge that walks out the door. Planning knowledge transfer, a runbook, and on-call as deliverables, not afterthoughts, is what let my team own the platform the day after cutover.
- check_circleSchedule the disruption away. A tight off-hours window with in-flight messages drained meant the migration was invisible to providers. The least dramatic outcome, nobody noticing, was exactly the goal.