EHR Migrations & Upgrades
You just announced a migration.
You have 200 interfaces to validate.
Cerner to Epic. MEDITECH to Epic. Legacy to anything modern. The timeline is 12 months. The interface inventory is 200+. The team that mapped the first 50 interfaces three years ago has turned over twice. The spreadsheet says “complete.” Nobody trusts the spreadsheet.
Migrations fail at the interfaces.
The EHR conversion project plan has 400 line items. Somewhere around line 287 is “Validate all interfaces.” It has a two-week window and a single analyst assigned. That analyst is about to discover that the source system and the target system format PID.3 differently, use different Z-segment structures for insurance data, and disagree on whether OBR.16 is the ordering or attending provider.
These are not bugs. They are dialect differences between two systems that have never spoken to each other. And you have 200 of them to find, document, and resolve before the cutover window opens.
The Migration Command Center workflow.
Five phases. One engine. From source system baseline to post-cutover production monitoring.
Baseline the source system with Post.
Before you touch the target system, document what the source system actually sends. Not what the spec says. Not what the 2019 spreadsheet claims. What the interfaces produce today.
Do this for every interface category: ADT, ORM, ORU, RDE, SIU. Each profile captures the dialect. Each profile is evidence, not memory.
$ pidgeon config analyze --samples ./cerner_traffic/ \
--save cerner_baseline.json
Analyzing 2,341 messages across 47 interfaces...
Vendor detected: Cerner (97.8% confidence)
PID.3 structure: CX with Mod-10 check digit
Insurance: IN1/IN2 segments (no Z-segments)
Field population: 127 fields mappedGenerate target-system test data with Post.
Generate messages in the target system’s dialect. If you are migrating to Epic, generate Epic-pattern messages. If you are migrating to MEDITECH, generate MEDITECH-pattern messages. Then validate the target interfaces against what they will actually receive.
278 trigger events. Vendor-specific field patterns. Clinically correlated code sets. The test data your migration team needs without copying production PHI.
$ pidgeon generate ADT^A01 \
--count 500 \
--vendor epic \
--output ./migration_test/
$ pidgeon validate \
--file ./migration_test/ \
--profile epic_target.json \
--mode strictSeed staging environments with Flock.
200 interfaces need more than test messages. They need a populated database. Flock generates entire synthetic patient populations grounded in real epidemiological data — relationally consistent across tables, schema-aware, FK-ordered.
10,000 patients with realistic disease distributions for your geography. No PHI. No legal review. No six-week data use agreement blocking your migration timeline.
$ pidgeon flock generate \
--schema target_db.ddl \
--population 10000 \
--location OH
Generating synthetic population...
Demographics: Census ACS 2023 (Ohio)
Disease distributions: CDC WONDER
Lab value ranges: NHANES 2021-2023
Relational integrity: FK graph resolved
Output: 10,000 patients → target_seed.sqlDiff source against target.
Compare the Cerner baseline against the Epic target. See exactly which fields changed format, which segments moved, and which values need mapping. The deviation report becomes your interface conversion checklist.
Field-level precision across every interface category. HTML reports for the project steering committee. AI triage identifies root causes and suggests mapping rules.
$ pidgeon diff ./cerner_baseline/ ./epic_target/ \
--report migration_diff.html
Comparing 47 interface categories...
ADT^A01: 12 field-level deviations found
PID.3: CX Mod-10 → CX (Epic MRN format)
IN1.2: Local code table → Epic payer list
OBR.16: Ordering provider → Attending MD
Report written: migration_diff.html (47 pages)Monitor post-migration with Loft.
Cutover is done. The first real messages are flowing. Loft watches every interface in real time, validates against the vendor profiles you built in Phase 1, and alerts within 60 seconds when a message fails at the structure level.
Not when a physician calls to ask why the lab results did not arrive. Before that call ever happens.
The migration that does not end with a bridge call.
200 interfaces. 12 months. Every dialect documented. Every mapping validated. Every staging environment seeded with realistic data. Every production interface monitored from the moment of cutover. One engine powers the entire migration lifecycle — the validation rules that caught dialect differences in testing catch them in production.
Built for every role in the migration.
The same five-phase workflow serves the full team — from the analyst running validation scripts to the director who has to answer to the CMO on Monday morning.
Post gives you the vendor profiles and test data to validate 200 interfaces without hand-building a single message. Script the entire Pre-Flight Check for each interface category and run it before every migration milestone.
This is the engagement differentiator. Show up with the Migration Command Center workflow. Baseline the source system on day one. The client has never seen their interfaces documented this fast.
Loft gives you a real-time dashboard of every interface during and after cutover. When the CMO asks how the migration is going, you open Loft instead of checking Slack.
Flock populates your staging environment without a single production data copy request. 10,000 patients, relationally consistent, zero PHI.
The products behind this playbook.
Three products, one engine. The same Pidgeon.Core powers every phase of your migration.
Post — CLI Testing Tool
Generate clinically coherent HL7/FHIR test messages for any trigger event, vendor pattern, or dialect. Baseline source systems, validate target interfaces, and diff environments. Free and open source.
Flock — Population Engine
Generate entire synthetic patient populations grounded in CDC WONDER, NHANES, and Census data. Schema-aware, FK-ordered SQL output. Seed staging databases without touching production PHI.
Loft — Interface Observability
Real-time monitoring and alerting for every live interface. Validates messages against the vendor profiles you built during migration. Alerts within 60 seconds when something breaks post-cutover.
Runs entirely on your machine.
Pidgeon Desktop runs locally. Your HL7 traffic, your schema definitions, and your generated populations never leave your environment. No cloud upload. No PHI transmission. Zero compliance overhead for migration projects involving real patient data flows.
Start with the source system baseline.
Download the CLI and profile your first interface category in under five minutes. For enterprise migration support across 100+ interfaces, contact us.