01
Workload Classification
Every queue manager, queue and channel inventoried, then routed by messaging pattern: RabbitMQ for transactional and routing-heavy traffic, Kafka only where the workload is a real event stream.
Insurance Integration
Insurance Integration Platform: Move Off IBM MQ Without Replacing the Core
AceMQ moves an insurer's messaging from IBM MQ to RabbitMQ in phases while the policy, claims and billing systems stay where they are. American National Insurance did it this way: Windows-based queues first, a roadmap for the mainframe queues, and both brokers running in parallel until behavior was validated. A named senior engineer covers the platform before, during and after the move, 24/7 with a 15-minute emergency response.
- enterprise customers
- 130+
- countries served
- 26+
- min emergency SLA
- 15
Is This You?
You probably need this if…
- 01
IBM MQ subscription cost is up for renewal and nobody can say how much of the traffic needs it
- 02
Your IBM MQ version is past standard support, or the upgrade keeps slipping
- 03
Queue managers on versions IBM no longer fixes are failing or behaving unpredictably, and there is nobody to call
- 04
Policy administration, claims and billing depend on the queues, and replacing the core system is not on the table
- 05
Some queues sit on Windows and some on the mainframe, so a single cutover looks impossible
- 06
Member or benefits data crosses the queues and HIPAA applies to how it is handled
- 07
A Kafka cluster exists only to carry database change events, and running it costs more than the use case justifies
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your Insurance estate when the engagement closes.
Before
IBM MQ looks like one big move tied to the core systems, so nothing moves.
After
Workloads classified by pattern, moved in phases, and the core systems keep their interfaces throughout.
Before
A cutover has no way back if behavior differs.
After
Old and new brokers run in parallel, behavior is validated before each cutover, and the rollback is rehearsed.
Before
Unsupported versions are an audit finding and a risk nobody owns.
After
Support in place on the version you run while the move happens, then on the target broker.
Before
The subscription renewal is the only date on the calendar.
After
A phased plan that retires IBM MQ queues as each phase completes, so the bill falls as the work lands.
Scope
What's covered
- 02
Phased IBM MQ to RabbitMQ Migration
Distributed queues first to reduce risk and build experience, with messaging patterns translated into RabbitMQ exchanges and bindings and code refactoring guidance for the applications.
- 03
Mainframe Queue Roadmap
Mainframe queues treated as a later phase with their own technical architecture and roadmap, so they do not block the rest.
- 04
Parallel Running and Validation
Old and new brokers run side by side until behavior is validated, and cutover happens per workload.
- 05
Regulated Data Handling
Data handled to the customer's requirements throughout, such as HIPAA for benefits and health data. We help gather the evidence; your compliance team decides what satisfies your framework.
- 06
Change Data Capture on Kubernetes
Database change events captured with Debezium and published straight to RabbitMQ, without a Kafka cluster where the workload does not need one.
- 07
Support for Unsupported Versions
24/7 support for IBM MQ and RabbitMQ versions the vendor or community no longer fixes, while the upgrade or migration is planned.
- 08
24x7 Support and Managed Operation
From reactive support to AceMQ running the platform, on the four-stage ladder.
The Engagement
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
- Phase 1Scoped per engagement
Inventory and Classify
We inventory queue managers, queues, channels and the applications behind them, record each IBM MQ version against IBM's lifecycle dates, and classify workloads by pattern, ordering and latency needs.
You receive
- Queue manager, queue and channel inventory
- Application and client dependency map
- Version and support position against IBM's lifecycle dates
- Phase 2Scoped per engagement
Plan the Phases
We agree which workloads move first, which stay on IBM MQ for now, and which belong on Kafka. The mainframe queues get their own roadmap. Health check assessments of an existing broker take one to four weeks depending on complexity, focus areas and problems found.
You receive
- Phase plan with sequencing and risk
- Target broker per workload
- Mainframe roadmap
- Phase 3Scoped per engagement
Migrate in Phases
Changes made alongside your engineers: patterns translated, code refactoring guidance given, both brokers run in parallel, behavior validated before each cutover.
You receive
- Workloads migrated and verified
- Rehearsed rollback per cutover
- IBM MQ queues retired as phases complete
- Phase 4Ongoing
Operate
The operating model you choose on the support ladder, from escalation cover to AceMQ running the platform in your account.
You receive
- Agreed support stage and escalation path
- Runbooks and topology documentation you keep
Insurance integration platform: the paths off IBM MQ at a glance
An insurance integration platform is the messaging layer between policy administration, claims, billing, document and partner systems. Moving it off IBM MQ does not require touching those systems' business logic, because they talk to queues, and the queues can move in phases. The table shows the choices.
| Path | What changes | What stays | When it fits |
|---|---|---|---|
| Stay on IBM MQ, on a supported version | Upgrade to a release IBM still fixes | Everything else | The workload needs IBM MQ features and the subscription is justified. |
| Move queues to RabbitMQ | Messaging patterns translated into exchanges and bindings; applications refactored where they depend on IBM MQ behavior | Policy, claims and billing systems and their business logic | Transactional, routing-heavy and request and reply traffic. |
| Move event streams to Kafka | Event-style workloads re-platformed | The systems of record | Many consumers reading the same events, with replay. |
| Leave mainframe queues until later | Nothing yet; a roadmap and architecture are written | Mainframe queue managers | Mainframe code is the constraint, so those queues are a later phase. |
The full decision, including IBM's lifecycle dates by version, is on IBM MQ migration and alternatives
and the wider approach is in the messaging modernization solution
American National: IBM MQ to RabbitMQ without replacing the core
American National Insurance, a named AceMQ customer, had IBM MQ entrenched for years, with significant legacy code depending on it. AceMQ led a phased migration to RabbitMQ on Kubernetes. Windows-based IBM MQ queues moved first, which reduced risk and built migration experience before the mainframe queues. The mainframe migration roadmap and technical architecture were defined and validated as a later phase.
IBM MQ messaging patterns were translated into RabbitMQ exchanges and bindings, mapped to the existing queue topology, with code refactoring guidance for the applications. The work was done under the customer's HIPAA requirements, with a parallel operation period and behavior validation before each cutover. The outcome the use case records is continuity of operations while IBM MQ licensing costs were progressively eliminated.
American National also replaced a Kafka-based change data capture pipeline for SQL Server with standalone Debezium publishing directly to RabbitMQ, which removed the operational weight of running Kafka clusters and Kafka Connect for a use case that did not need them.
The migration is written up in the IBM MQ to RabbitMQ migration use case
and the change data capture case in the Debezium and RabbitMQ use case
For how the same approach applies across banks, payment firms and insurers, see RabbitMQ and Kafka for financial services
Unsupported IBM MQ versions and subscription cost
IBM MQ keeps running past the end of standard support. What stops is the flow of fixes, and an unsupported version becomes an audit finding on its own. Per IBM's lifecycle page, as listed on our IBM MQ migration page and checked on 14 October 2026, IBM MQ 9.1 left standard support on 30 September 2023 and 9.2 on 30 September 2025. IBM MQ 9.3 reaches that point on 30 September 2027.
The reasons insurers move are usually subscription cost and the shape of newer workloads, and the constraint is legacy code and mainframe queues. We do not publish IBM MQ price comparisons, because the figures depend on your contract. What we can do is measure what the workload actually needs, so the renewal conversation starts from data.
- Stay and stay supported — If an upgrade cannot happen this quarter, support on the version you run covers the gap with a 15-minute emergency response and a planned route to a supported release.
- Move and retire — Each migrated phase retires IBM MQ queues, so the subscription can shrink as the work lands rather than all at once at the end.
- Never migrate and upgrade in one window — We keep the two changes apart so a problem can be traced to one cause.
IBM MQ support is described in IBM MQ support
and RabbitMQ versions that have left community support are covered by RabbitMQ extended LTS support
A patching and blue-green migration case for an insurance and member services provider is in the insurance CVE patching use case
24x7 support and the four-stage ladder
Policy and claims platforms run outside office hours, so cover has to as well. Most insurers start at Stages 1 and 2, which add escalation cover and monitoring to a team that already runs the brokers. Stages 3 and 4 hand the day-to-day operation to AceMQ.
| Stage | What it is | The question it answers |
|---|---|---|
| Stage 1: Reactive support | Senior engineers on call for incidents under a contracted SLA. | Our team runs the platform. Who do we call when it breaks at night? |
| Stage 2: Proactive support | Stage 1 plus monitoring through AceMQ's observability setup. | Who notices trouble before members and agents do? |
| Stage 3: Managed on your infrastructure | AceMQ operates the platform inside your cloud account or data center. | Data must stay inside our boundary and we do not want the pager. |
| Stage 4: Managed on AceMQ's infrastructure | AceMQ hosts and operates the platform. | We want it run for us, and our policy allows a hosted service. |
IBM MQ and ActiveMQ estates are covered by support rather than the managed stages.
Every stage carries AceMQ's published support response times. They are a response, not a resolution: within 15 minutes of a P1 a senior engineer is on a live bridge with you, and resolution time depends on the problem.
| Severity | Response | What it covers |
|---|---|---|
| P1 Emergency | 15 minutes | Production down: total outage, messages not flowing, complete queue manager failure, data loss risk |
| P2 Critical | 1 hour | Severe degradation: major performance loss, high error rates, approaching capacity limits |
| P3 High | 4 hours | Performance issues: noticeable slowdowns, non-critical configuration problems, partial failures |
| P4 Standard | Next day | Guidance and questions: best practices, architecture questions, proactive tuning |
Start with RabbitMQ support
or see managed RabbitMQ services
For change data capture, see Debezium support
Other starting points are the AceMQ solutions overview
What this page does not claim
- No certification claims — AceMQ helps you gather and produce evidence for the messaging layer. Whether it satisfies HIPAA, a state regulator or another framework is for your compliance team and auditors.
- Named customers — American National is the named reference on this page. Other examples are anonymised, and details that could identify a customer are left out.
- No outcomes promised in advance — We do not quote durations, throughput, availability or cost figures before seeing your estate.
- The core systems stay yours — We change how the systems talk to each other, not the policy, claims or billing logic itself.
FAQ
Questions about Insurance integration
Can you modernize IBM MQ without replacing the policy core?
Yes. Policy administration, claims and billing systems talk to queues, not to the broker's internals, so the queues can move in phases while those systems keep their business logic. Applications that depend on IBM MQ-specific behavior need refactoring guidance, and old and new brokers run in parallel until behavior is validated.
Who has moved an insurer from IBM MQ to RabbitMQ?
American National Insurance, a named AceMQ customer. AceMQ led a phased migration to RabbitMQ on Kubernetes, with Windows-based queues first and a validated roadmap for the mainframe queues, under the customer's HIPAA requirements. The use case page describes it.
What do we do about IBM MQ versions IBM no longer supports?
Keep them supported while the move is planned. AceMQ supports IBM MQ estates around the clock with a 15-minute emergency response, and the migration retires queues phase by phase. Check your version against IBM's lifecycle dates on our IBM MQ migration page first.
Does the move reduce our IBM MQ subscription cost?
That is the usual reason for moving. Each migrated phase retires IBM MQ queues, so the subscription can shrink as the work lands. We do not quote savings before seeing your contract and your workload.
Do mainframe queues have to move too?
Not at the start. Mainframe queues are treated as a later phase with their own roadmap and technical architecture, so they do not block the distributed queues.
Do you provide HIPAA or other compliance certification?
No. We handle data to the customer's stated requirements during the work and help gather evidence for the messaging layer. Your compliance team and auditors decide whether it satisfies a framework.
How much does this cost?
It is scoped on the estate, the number of workloads and the depth of work, and we do not publish a price list. Tell us what you run and we will come back with a written quote.
Let's talk
Talk to an Engineer About Your Insurance Messaging Platform
Tell us which IBM MQ versions you run, what depends on them, and when the renewal is. We will scope the work and come back with a written quote.
Get in Touch
Talk to an AceMQ Expert
Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.