Corepoint to Mirth Connect Migration: A 2026 Practical Guide

Honest reasons we encounter in our engagements, in rough order of frequency.

License renewal at a difficult number. Corepoint licenses are typically tied to deployed instances, throughput tier, and feature modules. For mid-size hospitals and regional health systems, the annual cost is a meaningful budget line. At renewal, when budgets are tight, migration becomes a real conversation. The license savings — recurring, year over year — are what fund the migration project and continue paying back indefinitely.

Vendor consolidation after M&A. Hospital acquisitions frequently produce a multi-engine landscape: Corepoint at one facility, Mirth at another, Iguana or Rhapsody at a third. After integration, IT leaders often want a single engine to reduce operational complexity, concentrate hiring, and simplify support. When the consolidation target is Mirth (commonly the case given its license economics at multi-site scale), Corepoint installations migrate.

Healthtech multi-tenant scaling.Healthtech platforms running Corepoint for early hospital customers often hit license-cost walls as they expand to 10+ hospital tenants. Mirth's per-tenant cost is effectively zero (operational cost only); Corepoint's scales with deployed instances. The crossover point typically arrives around 5–15 tenants.

Capability or roadmap concerns. Specific feature gaps, slow vendor response on capability requests, or strategic-direction disagreements. Less common than cost as a primary driver, but real for specific organizations.

Acquisition or ownership changes. Corepoint Health Solutions was acquired by Lyniate (which has also at various times owned Rhapsody and other healthcare integration products). Corporate ownership transitions sometimes drive customers to reconsider long-term commitments to commercial products versus open-source alternatives.

For evaluation-stage analysis comparing the two engines, see Mirth Connect vs Corepoint. This article assumes you've already decided to migrate and focuses on execution. For broader product context, the Mirth Connect complete guide covers the engine end-to-end, and Mirth Connect support is the home of our productized program.

Phase 1 — Discovery & Channel Inventory   (2-4 weeks)
Phase 2 — Concept Mapping                  (1-2 weeks)
Phase 3 — Build & Validation in Mirth      (8-16 weeks)
Phase 4 — Parallel Run                     (4-12 weeks)
Phase 5 — Cutover & Decommission           (1-2 weeks)

Total elapsed time: typically 4–8 months depending on:

• Number of channels (20 channels takes significantly less time than 200)
• Complexity per channel (vendor-specific codes, custom scripts, etc.)
• Number of downstream systems requiring coordination
• Available engineering bandwidth (in-house, vendor, or both)
• Risk tolerance (clinical workflows require longer parallel-run periods)

Phases overlap in practice. Phase 3 work begins on simpler channels while Phase 1 discovery continues on more complex ones. Phase 4 parallel-run on early channels happens while Phase 3 build proceeds on later ones.

For the parallel migration framework we use for Rhapsody, see Rhapsody-to-Mirth Migration Guide — the high-level phasing is identical because both are commercial-engine-to-open-source migrations following the same playbook.

Before migrating anything, know what you have.

The channel inventory. Catalog every channel in the current Corepoint deployment with:

• Channel name and purpose — what business workflow it serves
• Source — which system sends messages, in what format, on what schedule
• Destination(s) — which systems receive, in what format
• Message types — ADT^A01, ORU^R01, SIU^S12, FHIR resources, etc.
• Volume — messages per second peak and average
• Criticality — clinical, financial, administrative
• Owner contact — the business stakeholder for this channel
• Documentation status — well-documented, partial, undocumented

For hospital deployments, a complete inventory typically has 20–100 channels. Regional health systems can exceed 200. Healthtech platforms can have anywhere from a few channels per tenant to hundreds across tenants.

Configuration export.Corepoint exposes channel configuration through its admin interface and (depending on version) APIs. Export every channel's configuration to a structured format your migration team can analyze. This export is the source-of-truth for the migration.

Action and script inventory. Beyond channels, Corepoint installations have actions (Corepoint's term for processing steps, similar to Mirth transformer steps), filters (conditional logic gating message flow), mapping definitions (message transformations, often visual-editor-built), custom scripts (Corepoint Script Language (CSL) or JavaScript depending on version), and custom Java extensions (JAR files added to the Corepoint classpath). Each of these has a Mirth equivalent that needs to be reimplemented or mapped (see Phase 2). Inventory them now.

Integration dependencies.Beyond Corepoint itself, identify database dependencies (Corepoint tables that downstream systems query directly), file-share dependencies (directories Corepoint reads from or writes to), scheduled jobs (cron-style triggers or Corepoint's internal scheduler), monitoring integrations (alerts feeding into Splunk, Datadog, or similar), and authentication integrations (AD/LDAP, SSO bindings). These all need reproduction in the Mirth deployment.

The discovery deliverable is a written Migration Discovery Document including the channel inventory, action/script inventory, integration dependencies map, per-channel risk assessment, proposed migration sequence, and a resource and timeline estimate. Skipping or shortcutting Phase 1 is the most common cause of migrations that overrun. The cost of thorough discovery is small relative to the cost of mid-project surprises.

Both engines share conceptual models — channels, filters, transformers, routes — but specifics differ. Map carefully.

Filter migration. Corepoint filters typically use CSL or JavaScript expressions. Each filter maps to a Mirth filter with similar logic: read the existing Corepoint filter, identify Corepoint-specific API references, and rewrite using Mirth's return-true / return-false JavaScript or Groovy pattern. Most filters port in under 30 minutes each. For transformer language guidance, see Mirth Connect Groovy vs JavaScript transformers.

Mapping migration. This is where most migration effort concentrates. Corepoint mappings can be visual / drag-and-drop (built in Corepoint's mapping editor), CSL-based (Corepoint Script Language for complex logic), or hybrid (visual mapping with embedded CSL). In Mirth, all of these become transformer steps in JavaScript or Groovy. The translation is straightforward in principle but tedious in execution: each Corepoint mapping needs a corresponding Mirth transformer producing equivalent output for equivalent input. For logic shared across many channels, Code Templatesare the Mirth equivalent of Corepoint's reusable mapping libraries.

Corepoint Script Language (CSL). CSL is Corepoint-specific and has no direct equivalent. Each CSL script needs rewriting as JavaScript or Groovy. The good news: most CSL is straightforward (field extraction, conditional logic, string manipulation) and ports cleanly. Complex CSL scripts may require deeper analysis but are still tractable.

Custom Java code. If your Corepoint installation includes custom Java JARs (extensions, libraries), most code can be reused directly in Mirth. Mirth allows custom JARs in /custom-lib/ and the code is callable from both Groovy and JavaScript transformers.

Scheduled jobs.Corepoint scheduling features correspond to source connectors with polling intervals (Database Reader, File Reader), external cron / scheduler triggering Mirth channels via HTTP API, or Quartz scheduling in some Mirth deployment patterns. Choose based on the specific job's nature.

The concept-mapping deliverable is a written Concept Mapping Document detailing how each Corepoint construct will become a Mirth construct. This document is the build specification for Phase 3.

Channel-by-channel rebuild, with validation at each step.

Build sequencing. Start with channels that are lowest clinical criticality (administrative, financial, or batch channels first), simplest in logic (fewer transformers, fewer custom code paths), and well-documented. Save high-criticality and complex channels for later, after the team has built confidence with simpler ones.

Common sequencing patterns: batch file feeds first, administrative ADT next, lab results, pharmacy / orders, real-time clinical (most critical) last.

Build process per channel. For each channel:

1. Read the Corepoint source channel configuration
2. Map to Mirth using the Phase 2 concept map
3. Configure the source connector in Mirth (port, framing, etc.)
4. Build the source filter
5. Build the source transformer (port CSL / mappings to JavaScript or Groovy)
6. Configure destination connector(s)
7. Build destination filter(s)
8. Build destination transformer(s)
9. Test with sample messages from Corepoint's actual production traffic
10. Compare output byte-by-byte (or semantically) with Corepoint's output
11. Document the channel

For practitioner-level guidance on Mirth channel building, see How to build an HL7 interface in Mirth Connect.

Validation approach uses three layers, in order. Unit validation: sample messages through individual transformers, verify expected outputs match. Channel validation: end-to-end messages from a test source through the channel, verify outputs match Corepoint's output. Behavioral validation: real production traffic captured from Corepoint, replayed through Mirth, output compared with Corepoint's actual output. Behavioral validation catches the most bugs — production traffic always contains edge cases the test set doesn't.

The build deliverable per channel is a complete, validated Mirth channel with documented configuration, transformers, and validation evidence. Each channel ready for Phase 4 parallel-run.

The risk-reduction phase. Both Corepoint and Mirth process the same traffic; outputs are compared.

Architecture for parallel run. Two patterns:

Pattern A — Tee at source.A network appliance or Mirth-side listener mirrors inbound MLLP traffic to both Corepoint and Mirth. Both engines process; both emit outputs. Outputs are compared; only Corepoint's output goes to the actual destination during this phase.

Pattern B — Echo at destination. Mirth runs alongside Corepoint and processes the same inbound traffic, but its destination outputs go to a parallel-validation system (log file, database, comparison engine) rather than the actual downstream. Corepoint continues serving the real downstream. Pattern B is operationally simpler and is what most migrations use. Pattern A gives stronger evidence but requires more infrastructure.

Duration depends on channel criticality: 2–4 weeks for administrative / batch channels, 4–8 weeks for routine clinical channels, 8–12 weeks minimum for high-criticality clinical (real-time alarms, code workflows). The goal is to observe edge cases, unusual message patterns, vendor-specific quirks, and seasonal volume variations before cutting over.

What to compare.For each message processed by both engines, compare output message bytes (semantic equality — timestamp differences in headers are typically acceptable), ACK behavior (same code, same timing), error patterns (same messages flagged as errors), and processing time (Mirth's throughput should match or exceed Corepoint's).

Discrepancies fall into three categories: Mirth correct, Corepoint had a bug (celebrate, document, proceed); both correct, different formatting (confirm downstream accepts either, proceed); Mirth wrong (fix the Mirth channel and reset the parallel-run clock).

Decision to cutover. Cutover when no new discrepancies have appeared for at least 2 weeks, all known discrepancies are documented and resolved, the operational team has practiced operating Mirth (deploys, troubleshooting, alerts), the rollback plan is rehearsed, and stakeholders sign off. For operational practice during parallel run, our team uses the Mirth Connect issues and fixes catalog as a training reference for what to expect.

The actual switch. Corepoint stops handling production traffic; Mirth takes over.

Cutover sequencinghappens per-channel, not all-at-once: pick a channel that's been parallel-running cleanly for 4+ weeks; schedule a maintenance window (typically off-hours, with stakeholder notification); stop the Corepoint channel; activate the Mirth channel as the production source (or destination); verify message flow end-to-end; monitor closely for 24–72 hours; document the cutover; move to the next channel. Per-channel cutover limits blast radius — if one channel has a problem, the rest continues on Corepoint.

Hypercare period. After each channel cuts over, run a hypercare period: 24–72 hours of intensive monitoring with an on-call engineer immediately available, elevated alerting threshold the first week, normal alerting plus periodic comparison sampling the first month, and a full operational review the first quarter. For broader hypercare and ongoing operations patterns, see Mirth Connect support services guide.

Rollback plan. For each channel, the rollback plan should define the trigger (what conditions cause rollback — data loss, clinical impact, etc.), the procedure (stop Mirth channel, reactivate Corepoint channel, verify), the time budget (typically 15–30 minutes per channel), the communication (who is notified during rollback), and the investigation (root-cause analysis of why rollback was needed). Most migrations do not need to use rollback procedures, but the procedures must exist and be rehearsed.

Corepoint decommissioning.After all channels are cut over and have completed their hypercare periods: run Corepoint in a “warm-spare” state for an additional 30–60 days (channels deployed but not processing live traffic) as a deeper-rollback option; after the warm-spare period, archive Corepoint configurations to long-term storage (compliance retention); terminate Corepoint licenses at the next billing cycle; document the full decommissioning for audit purposes. License termination is where the migration's financial payback begins — once Corepoint licenses lapse, the recurring savings start accruing.

Honest numbers for US Corepoint-to-Mirth migrations in 2026.

Timeline by deployment size:

Multi-tenant healthtech timelines depend heavily on whether all tenants migrate simultaneously or sequentially. Sequential is safer and more common.

Cost ranges for outside-engagement migration projects:

Costs vary substantially with scope, complexity, your team's prior Mirth experience, and parallel-run duration. Confirm specifics with your engineering team and any prospective vendor.

Payback math. The financial case for migration typically pencils out within 12–24 months. Example for a mid-size hospital: current Corepoint annual license is a meaningful budget line (varies; verify your specific situation); one-time migration cost around $250K (mid-range estimate); annual operational cost differential is roughly equivalent (Mirth has operational cost; the savings is licensing). Payback period: typically 12–18 months.

After payback, license savings continue indefinitely. Over a 5-year planning horizon, cumulative savings are typically substantial — but exact numbers depend on your specific Corepoint license terms. For broader engagement economics across our service catalog, see Mirth Connect pricing guide.

Migration risk falls into four categories. Each has mitigations.

Data loss / message corruption. Risk: migration discrepancies cause messages to be lost, duplicated, or corrupted during the transition. Mitigation: the parallel-run phase (Phase 4) catches discrepancies before they cause production impact; behavioral validation (replaying production traffic) is more rigorous than sample-message testing; per-channel cutover limits the blast radius if a problem occurs; documented rollback procedures enable rapid recovery.

Clinical workflow disruption. Risk: a channel cutover affects a clinical workflow in unexpected ways — patient orders mis-routed, lab results delayed, alarms not flowing. Mitigation: sequence cutovers from low-criticality to high-criticality; extended parallel-run for clinical channels (8–12 weeks minimum); stakeholder sign-off before each cutover; hypercare period after each cutover.

Team knowledge gaps. Risk: the team doesn't fully know Mirth and breaks production while learning. Mitigation: training during Phase 3 (build is a learning opportunity); documented runbooks for common incidents (see Java heap space error, MLLP connection refused, channel not starting); outside support engagement during cutover and hypercare; knowledge transfer documentation produced throughout the project.

Schedule and budget overrun. Risk: the project runs long and over budget because of unforeseen complexity. Mitigation: thorough Phase 1 discovery reduces surprises; fixed-bid scoping (where available) puts overrun risk on the vendor; phased delivery with go/no-go decision points; built-in contingency time for the riskier channels.

For broader risk management in production Mirth operations, see Mirth Connect support services guide.

Across Corepoint migration projects we've shipped and audited, recurring patterns that cause trouble.

• Underestimating Phase 1 discovery. Teams skip discovery to “save time” and discover halfway through the build that they have undocumented channels, hidden integration dependencies, or vendor-specific quirks that weren't in scope. Discovery is the highest-leverage phase in the project.
• Treating CSL ports as one-to-one code translation. CSL doesn't translate mechanically to JavaScript or Groovy. Engineers who try line-by-line literal translation produce brittle, hard-to-maintain code. Read the CSL's intent, then write clean Mirth transformer code that achieves the same intent.
• Short-changing the parallel-run phase. Parallel-run is where most discrepancies surface. Compressing it from 8 weeks to 2 weeks because “we already tested everything” is the most common reason post-cutover incidents happen.
• All-or-nothing cutover. Teams cut over all channels in one weekend to “minimize risk.” The opposite is true — all-at-once cutover concentrates all the risk into one window with no rollback flexibility. Per-channel cutover is the safer pattern.
• Ignoring downstream system coordination. Downstream systems (EHRs, LIS, billing) have their own integration teams who need to know about the cutover. Ports may change. IP allowlists may need updates. TLS certificates may need re-trusting. Surprise cutovers cause downstream incidents.
• No operations playbook for Mirth before going live. The team builds Mirth channels but never builds the operational playbook for running Mirth in production — monitoring, alerting, runbooks, on-call rotation. Day 1 in production is the wrong time to figure out monitoring. Establish operational practices during Phase 3, not after cutover.
• Skipping retention and pruning policy. Mirth's database grows aggressively without a pruning policy. A migration that doesn't establish retention on day 1 leaves the new deployment building up a database performance problem from the start. See Mirth Connect database configuration.
• No clear definition of “migration complete.” Migration projects can stretch indefinitely if success criteria aren't pinned down. Define clearly: all channels cutover, all stakeholders signed off, Corepoint licenses terminated, decommissioning documented. Then declare done.
• Losing institutional knowledge during transition. The engineers who knew Corepoint well leave or get reassigned before knowledge transfers to the Mirth team. Capture knowledge in writing during Phase 1 and Phase 2, not after the fact.
• Trying to fix bad Corepoint patterns during migration. Some teams use the migration as an opportunity to redesign poorly-architected Corepoint channels. Resist this. Migration scope creep is the most common reason projects overrun. Migrate to equivalent behavior first; redesign separately after stabilization.

Many migrations succeed in-house. The pattern that says “bring in outside help”:

Use outside help when:

• You have a hard deadline — Corepoint renewal in 6 months, contractual cutover date, or executive commitment already public.
• Your team has no Mirth experience — building first-time skill on a migration timeline is risky.
• You don't have spare bandwidth — your team is fully utilized running current Corepoint operations and can't take on migration work in parallel.
• You want fixed-bid risk transfer — converting variable internal cost to fixed external cost is sometimes the right financial choice.
• You need outside expertise for specific phases — even teams doing the bulk of work in-house often bring outside help for parallel-run validation or post-cutover hardening.

Stay DIY when:

• You have a strong in-house Mirth team already — the marginal cost of doing it yourself is just your existing salary spend.
• You have time flexibility — slow, careful in-house migrations work when there's no deadline pressure.
• The deployment is small — 10-channel migrations are feasible in-house for most teams.
• Migration is part of broader team upskilling — sometimes the migration is the training program for a new Mirth team.

For organizations choosing outside help, our Corepoint-to-Mirth Migration productized service uses the framework in this article on fixed-bid engagements. For broader engagement models, see our services overview and support tier guide.

The migration project ends; Mirth operations continue.

Steady-state operations. Mirth Connect requires the same operational discipline as Corepoint did — monitoring, patching, certificate management, capacity planning, performance tuning. The skills are the same; the tooling changes. Build the operational practice as part of the migration project (Phase 5) rather than as an afterthought. For ongoing operations, our support tier program covers Bronze through Enterprise engagements. Many migration clients move into a Silver or Gold support relationship after cutover to ensure operational continuity.

Long-term cost trajectory. Once Corepoint licenses are terminated, the cost trajectory shifts. License savings are continuous, recurring, and the full Corepoint license cost is eliminated. Operational cost is roughly equivalent to Corepoint's operational cost (monitoring, on-call, etc.). Specialist work is project-based, as new EHRs onboard or new capabilities are added. Over a 3–5 year planning horizon, cumulative license savings typically justify the one-time migration cost multiple times over.

Strategic optionality. Beyond cost, Mirth Connect's open-source license gives organizational optionality that Corepoint doesn't: no vendor lock-in (the source code is yours; you cannot be coerced by license terms or vendor strategic changes), multi-tenant scaling (adding new hospital tenants doesn't trigger new license fees), modification freedom (custom features can be built into the engine itself if needed — rare but valuable in some healthtech use cases), and community ecosystem (the Mirth community is large, active, and produces patterns, extensions, and operational tooling that complement the engine). For the broader strategic case, see Mirth Connect alternatives 2026.

Corepoint migrations are predictable when scoped correctly and painful when scoped poorly. Our engineers have shipped these migrations across US hospitals, health systems, and ambulatory networks and use the framework in this article as the standard playbook.

• Fixed-bid Corepoint-to-Mirth Migration — five-phase framework, defined deliverables, predictable timeline
• One-week scoping engagement to produce the Migration Discovery Document before committing to a full project
• Ongoing support tier engagement after cutover to sustain operations
• NDA available on request — confidential, no sales pressure

Talk to a Corepoint migration expert →