Integration engine modernization where retirement is part of the scope, cutover is proven by parallel run rather than by a weekend, and the estate that emerges is smaller and documented rather than the same estate on a newer platform.
A like-for-like migration moves every interface, including the ones nobody consumes, the ones with undocumented logic and the ones that were replaced years ago but never switched off. It costs more, takes longer and leaves you with the same operational burden on a platform you now also have to learn. CaliberFocus treats a migration as the one moment retirement is politically achievable, and designs the programme around that.
There is no maintenance window for admission and discharge traffic. The cutover is the risk, not the build.
The technical work of moving an interface from one engine to another is well understood. What consumes the schedule is discovery: establishing what each interface actually does, which transformations are business rules that migrated into the engine years ago, who still consumes the output, and whether the person who could explain any of it is still employed.
Interfaces carry live clinical and financial traffic with no natural downtime. An admission message cannot wait for a weekend window, which means cutover has to be provable rather than hopeful, and a rollback has to be executable in minutes by whoever is on call.
The undocumented interface is the schedule
Specification, not development, is the long pole. An estate with good documentation migrates in a fraction of the time, and almost no estate has good documentation.
Business logic living in the engine
Filtering, enrichment and routing decisions accumulated inside channels over years. Migrating them faithfully preserves logic nobody has reviewed since it was written.
The running configuration is more accurate than the documentation
A transformation may carry patient matching, provider mappings, location translation or payer-specific rules that production now depends on.
Vendor sunset forcing the timeline
Without reliable matching across organizational boundaries, exchange returns nothing useful—or returns the wrong patient.
No safe cutover window
Clinical traffic does not stop. A big-bang weekend cutover on interfaces carrying patient movement is a risk decision.
Migration scoped as everything
The default scope often includes the dead interfaces because nobody is funded to prove an interface is unused.
Separate the forced move from the improvement.
When a vendor sunset sets the timeline, run two tracks: the minimum compliant migration to meet the deadline, and a deliberate improvement programme with its own scope and business case.
Doing discovery before the plan is fixed is the difference between a programme that lands and one that reforecasts twice.
Step 1
Inventory everything
Including direct connections, scheduled jobs and file transfers built around the platform.
Step 2
Establish real usage from traffic
Last meaningful message, volume trend and named consumers, evidenced rather than asserted.
Step 3
Classify every interface
Retain as is, remediate, consolidate, redesign, migrate as built, or retire.
Step 4
Specify what survives
Message and field usage, transformations, routing rules and local extensions documented from production traffic.
Step 5
Separate business logic from integration logic
Decide deliberately whether embedded business rules move, stay or are lifted out.
Step 6
Design the target architecture
Routing model, environments, deployment pipeline, monitoring, alerting and resilience before rebuilding.
Step 7
Sequence by dependency group and risk
Related interfaces move together, aligned to workflows rather than alphabetically.
Step 8
Build, prove and cut over with rollback
Both engines run in parallel, outputs are compared, and cutover follows a tested rollback plan.
The migration is the only moment retirement is politically possible.
During a migration the question changes from “should we stop this?” to “should we pay to move this?” Organizations that skip classification migrate their entire estate and live with it for another decade.
Rebuilding an interface on a new platform is the part that looks like the project. Discovery beforehand and operational handover afterwards determine whether the organization is actually better off.
Assess
Estate Discovery and Traffic Analysis
Full inventory including connections outside the engine, with real usage evidenced from message traffic rather than an inherited spreadsheet.
Interface Specification From Production
Documenting what each surviving interface actually does from real messages, including local extensions and conditional logic.
Classification and Retirement Analysis
Every interface classified with the evidence behind each decision recorded.
Platform Selection Support
Vendor-neutral evaluation against message volume, standards mix, skills base, cloud position and operating model, including the option of staying where you are.
Migrate
Interface Rebuild and Consolidation
Rebuilding on the target platform, consolidating duplicated routes, and bringing point-to-point connections back inside governed integration.
Business Logic Extraction
Identifying transformation and routing logic that is genuinely business rule, and deciding with the owning team what to do with it.
Migration Factory
Repeatable templates, configuration standards, regression tests, documentation, cutover checklist and rollback procedure.
Shared Logic Standardization
Terminology mappings, crosswalks, identity resolution, validation and error handling extracted as shared services.
Parallel Run and Output Comparison
Both engines processing live traffic with automated comparison of outputs so cutover is evidenced rather than asserted.
Cutover and Rollback
Interface-by-interface cutover with a tested rollback executable by whoever is on call.
Operationalize
Target Architecture and Environments
Routing model, environment separation, deployment pipeline, source control, resilience and disaster recovery designed before the first interface moves.
Monitoring and Reconciliation
Volume, error, latency and distribution monitoring plus sent-against-processed reconciliation built into the target from the start.
Documentation and Runbooks
Specifications, mappings, extension catalogues and operational runbooks produced as programme deliverables.
Handover and Enablement
Training, shadowing and a defined readiness gate so the operating team can genuinely run the platform.
What CaliberFocus does, and does not do.
We are not a reseller for any integration platform and we will recommend staying on your current engine when that is the right answer. Frequently the real problem is not the engine at all: it is undocumented interfaces, missing monitoring, point-to-point sprawl and an estate nobody has pruned.
The word modernization gets applied to different programmes with different risk profiles, costs and business cases. Naming which one you are actually doing changes the scope and sequencing.
| Programme | What it is | The real risk |
|---|---|---|
| Engine-to-engine migration | Moving interfaces from one platform to another, usually driven by vendor sunset, cost or capability | Cutover on live clinical traffic, and discovering undocumented logic mid-build |
| On-premises to cloud | Relocating the platform, often with the same interfaces | Latency to on-premises source systems, connectivity resilience and the on-premises gateway becoming a new single point of failure |
| Post-merger consolidation | Combining two estates after an acquisition | Two sets of conventions, code sets and local extensions, and two teams who each believe theirs is correct |
| Point-to-point consolidation | Bringing direct connections back inside governed integration | Frequently the highest return work on this page and it needs no platform change at all |
What Consolidation Is Not Centralization.
A modern estate legitimately contains an integration engine, FHIR services, an API gateway, event infrastructure, secure file transfer and data platform ingestion. The objective is that every method has a defined role, named owner and operating model.
The single architectural decision that shapes everything else is whether messages route through a canonical internal representation or map directly source to target. Both are defensible and suit different estates.
| Model | Suits | Cost |
|---|---|---|
| Direct source to target | Estates with a small number of well understood connections and limited fan-out | Mapping effort grows with every new pair. Adding a destination means touching every source. |
| Canonical internal model | Estates where one source feeds several destinations, or where systems will be replaced over time | Upfront modelling effort and ongoing governance burden. Pays back when the fan-out is real. |
| Hybrid, canonical where fan-out exists | Most provider estates, honestly assessed | Requires the discipline to decide per interface rather than defaulting to one or the other. |
Environments and promotion, from day one
Development, test and production separated, with a promotion path and source control.
Monitoring and reconciliation designed in
Every migrated interface inherits volume, error, latency and distribution monitoring plus sent-against-processed reconciliation.
Resilience proportionate to the traffic
High availability and disaster recovery designed against what the interfaces actually carry.
The engine is not the estate
A modernized platform with point-to-point connections still running around it has not solved the problem.
Prove equivalence before you prove improvement. An interface that has run for years carries undocumented behaviour downstream systems depend on. Improvements are introduced deliberately afterwards as their own change with their own testing.
Both engines run on live traffic, outputs are compared automatically, and discrepancies are investigated and resolved before anyone switches.
Specify
From production traffic, including edge cases, error conditions and local extensions.
Rebuild
On the target platform, with monitoring and reconciliation inherited from the platform standard.
Replay
Historical messages through both engines, comparing outputs field by field.
Run in parallel
Target engine receiving real live traffic but not delivering downstream.
Compare continuously
Every discrepancy investigated, including the ones that look cosmetic.
Cut over
When the comparison has been clean for an agreed period, not when the schedule says so.
Hold recoverable
Source engine kept in a recoverable state for a defined shadow period.
Retire
Source interface switched off with the decision recorded, then the shadow removed.
Sequence by Risk, Not by Ease
Start with interfaces simple enough to prove the method but real enough to teach you something, then move through the estate with clinical and financial traffic later. Anything without a specification does not enter the queue until it has one.
A migration that finishes with a working platform and a team dependent on the implementer has moved the risk rather than removed it. Operational readiness is a gate with defined criteria, not a status update.
Monitoring inherited by default
- Volume, error rate, latency and queue depth monitoring applied as a platform standard so every interface inherits it.
- Sent against processed reconciliation on every interface where partial loss would matter.
Documentation as a deliverable
- Interface specifications built from production traffic and maintained as current.
- Local extension and code translation catalogues.
- Runbooks covering failure behaviour, replay, escalation and rollback.
- A maintained inventory with owner, consumers, purpose, monitoring status and review date.
Governance
- Source control and promotion path for specifications, mappings and configuration, with production never edited directly.
- Named owners for technical operation, data definition, exception resolution and vendor coordination.
- A retirement process with dependency validation, shadow period and tested rollback.
Readiness gate
- The operating team has run a live incident, a replay and a rollback themselves, with the implementer observing rather than acting.
- Every migrated interface has a current specification, named owner and monitoring in place.
- The source estate is decommissioned rather than retained indefinitely.
- Outstanding defects and limitations are documented and accepted.
If the old engine is still running six months later, the programme did not finish.
Decommissioning is a dated deliverable in the plan, not an aspiration after it.
A migration reported on interfaces migrated is measuring effort. These measures show whether the organization is better off than it was.
| Category | What we measure | Why it matters |
|---|---|---|
| Estate reduction | Interfaces at end versus start, point-to-point connections consolidated, dead interfaces retired. | A migration that moved everything did not modernize anything. |
| Cutover safety | Cutover incidents, rollbacks executed, and defects found in parallel run versus in production. | The measure of whether the method worked. |
| Documentation coverage | Interfaces with a current specification, extension catalogue and named owner. | The durable benefit, and the one that outlasts the platform. |
| Detection | Failures found by monitoring rather than by a user, and time to detection. | Whether the new platform is actually better operated than the old one. |
| Team readiness | Incidents, replays and rollbacks handled by the internal team without escalation. | Determines whether risk was removed or transferred. |
| Standardization | Interfaces using common naming, mapping, error, monitoring and deployment patterns. | Whether historical variation is shrinking or being reproduced. |
| Knowledge risk | Critical interfaces dependent on undocumented individual knowledge. | The operational continuity measure. |
| Decommissioning | Source platform retired on schedule, and dual-running cost eliminated. | Where the business case actually lands. |
Discovery will change your scope and it will feel like bad news.
Expect to find interfaces nobody can explain, business logic in channels that should have been reviewed years ago, and at least one connection everyone assumed was decommissioned that is carrying live traffic.
We will analyze real traffic against your inventory, classify every interface as migrate, consolidate, replace or retire, and give you a defensible scope with the retirement candidates evidenced. That assessment routinely removes a meaningful share of the estate from the migration before anyone commits a budget, and occasionally concludes you should not migrate at all.
Bring us a specialty or clinical setting where clinicians are spending too much time creating notes. We will assess where ambient documentation fits, what must remain clinician controlled, how it should integrate with your EHR, and how to measure whether it is actually reducing burden.
One conversation with people who have run these deployments, and a written readiness view you can use with or without us.
- AI Agents and Workflow Automation
- Voice and Conversational AI
- Document AI and Intelligent Processing
- Generative AI and Enterprise Copilots
- AI Strategy and Governance
- HCC and Risk Adjustment Analytics
Security & Compliance
