01
EMS Estate Inventory
Queues, topics, durable subscribers, routes and bridges, connection factories, security settings and every application that connects, from the server configuration and from code.
TIBCO EMS Migration
TIBCO EMS Migration to RabbitMQ or Kafka, Mapped Feature by Feature
Last reviewed by Tyler Eastridge
AceMQ plans and runs TIBCO EMS migrations to RabbitMQ or Kafka with partner messaging specialists. We inventory every queue, topic and connected application, map each EMS feature your code uses against what the target documents, flag the gaps before they surface in testing, and move applications in waves with the old and new brokers running in parallel. AceMQ is an independent provider: it is not a TIBCO partner or reseller, gives no licensing advice and supplies no TIBCO patches.
- current TIBCO EMS release, February 2026
- 10.5.0
- TIBCO retired EMS 10.3.0, per its support policy notice
- 31 Mar 2026
- JMS namespaces EMS ships: javax.jms and jakarta.jms
- 2
Is This You?
You probably need this if…
- 01
A TIBCO EMS renewal is coming, and the business case for staying or leaving has never been costed on the real workload
- 02
You run an EMS release TIBCO has retired and want a plan before the next change window forces one
- 03
Nobody can list every queue, topic, durable subscriber and connected application, and the person who could has left
- 04
Applications use JMS features such as XA transactions or message selectors that a target may not provide
- 05
The estate mixes javax.jms and jakarta.jms clients across Java versions
- 06
A cloud or platform team wants Kafka, while most of the traffic is queued work and request-reply
- 07
You want an independent view of RabbitMQ against Kafka for this estate, from a party that does not sell EMS
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your TIBCO EMS estate when the engagement closes.
Before
The EMS estate is known from memory: a config export, an old diagram and one engineer.
After
A complete inventory of queues, topics, durable subscribers, bridges and client applications, each tagged with what it needs from a broker.
Before
JMS compatibility is assumed, and the gaps appear in user acceptance testing.
After
A written gap list per application: the features it uses, what the target documents for each, and the redesign or workaround for what is missing.
Before
RabbitMQ or Kafka is decided by preference, and every workload goes through the same answer.
After
Each flow routed on evidence: RabbitMQ for queued work and request-reply, Kafka where streaming and replay are the real requirement.
Before
Cutover is one weekend, with no way back.
After
Per-application cutover with old and new brokers in parallel, reconciliation gates and a rollback rehearsed before it is needed.
Scope
What's covered
- 02
JMS Feature Mapping
Each JMS feature in use set against the target's documentation: transactions, selectors, queue browsing, acknowledgement modes, client identifiers and the javax or jakarta namespace.
- 03
Target Choice
RabbitMQ or Kafka per workload, with the reasons written down, including where a workload should stay on EMS for now.
- 04
Parallel Run and Bridging
A bridge or dual-publish pattern chosen per flow, so producers and consumers can move one application at a time.
- 05
Target Build
RabbitMQ or Kafka designed for your availability needs, with queue types, topic and partition layout, security and monitoring.
- 06
Security and Access
Users, permissions and transport security carried across, including any FIPS or other compliance requirement the EMS estate meets today.
- 07
Validation and Cutover
Message counts, ordering and delivery checks per flow, go or no-go checkpoints and a rollback for each wave.
- 08
Interim EMS Cover
Engineering help with your running EMS estate while the move proceeds, case by case. AceMQ is an independent provider and supplies no TIBCO patches or support entitlement.
- 09
Handover and Support
Runbooks for your team, and 24/7 support or managed service for the new platform.
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 estate
Assess
Inventory the EMS estate and its clients, record which JMS features each application uses, and note release, topology and compliance requirements. Written findings before anything moves.
You receive
- Inventory of destinations, bridges and applications
- JMS feature usage per application
- Gap list against RabbitMQ and Kafka
- Phase 2Scoped per program
Design
Choose the target per workload, design the new platform, decide the parallel-run pattern per flow, and plan the order of applications and the rollback for each.
You receive
- Target design
- Wave plan with rollback per wave
- Decisions on gaps: redesign, workaround or stay
- Phase 3Scoped per wave
Build and rehearse
Stand up the target, move a non-critical flow first and rehearse failure: broker loss, consumer reconnection and restart. Production gets no first attempts.
You receive
- Target platform in service
- Rehearsed migration of a first flow
- Failure test results
- Phase 4Until each flow reconciles
Parallel run
Move applications in waves with old and new running side by side, comparing counts and ordering until each flow reconciles.
You receive
- Reconciliation per flow
- Signed-off pass criteria
- Go or no-go per wave
- Phase 5Planned change windows
Cut over and retire
Switch the last producers and consumers, keep the EMS fallback open for the agreed window, then retire it with sign-off so renewal lines actually stop.
You receive
- Applications on the new platform
- EMS decommission sign-off
- Optional 24/7 support or managed service
Where JMS applications meet the target: the gaps that decide the plan
A JMS application can be moved with small code changes when it only sends and receives. It gets hard where it uses transactions, selectors or browsing. These are the places we look first, using the targets' own documentation. We state what each documents, and we test your applications against it.
| If your applications use | RabbitMQ (documented) | Kafka | What we plan |
|---|---|---|---|
| The JMS API itself | A JMS client library: JMS 2.0 as of version 2.7.0 and JMS 3.0 as of 3.0.0, both branches supported. The 2.x line needs Java 8 or later and 3.x needs Java 11 or later. | Kafka's documentation describes its own producer and consumer APIs and does not mention JMS, so JMS clients are rewritten or bridged, not repointed. | Count clients by namespace and Java version first. EMS ships both javax.jms and jakarta.jms jar sets. |
| XA and distributed transactions | The JMS client does not implement the XA interfaces. Local transactions do not guarantee atomicity and can result in partial completion. | Kafka transactions make a producer's writes to several topic partitions all-or-nothing. For writes to an external system, Kafka's design documentation suggests storing the consumer offset with the output instead of a two-phase commit. | Redesign the unit of work: idempotent consumers, an outbox pattern or a transaction manager outside the broker. |
| Message selectors | Message selectors for queues are not supported by the JMS client. Topic selectors need the JMS Topic Exchange plugin. | Consumers subscribe to topics, and records with the same key go to the same partition. | Replace with routing keys, separate destinations or consumer-side filtering. |
| Queue browsing | Browsing temporarily hides messages and can reorder them. | Records stay in the log after they are read, for a retention period set per topic. A consumer reads from an offset it controls and can rewind, which is a different model from peeking at a queue. | Find every application that browses and decide whether it needs a different monitoring approach. |
| Acknowledgement and delivery semantics | The client uses group acknowledgement, which the docs say differs slightly from the JMS specification. NoLocal is ignored. | Consumer groups track progress as one offset per partition. Kafka 4.4 also documents share groups, in which records are acknowledged individually. | Test failure and redelivery paths per application, not just the happy path. |
| Non-Java clients and protocols | RabbitMQ 4.0 and later supports AMQP 1.0 natively next to AMQP 0.9.1 on one port, and the docs call the 0.9.1 client ecosystem more extensive. | Kafka's own protocol. Only the Java clients are maintained in the Kafka project; other languages use independent open source clients. | Match each non-Java client to a supported library before it appears on a wave. |
What we do not claim
There is no drop-in JMS migration from EMS to either target. Where RabbitMQ is the target, its JMS client is real and maintained, and it has the documented limits above. We find them in your code during assessment, not during cutover.
RabbitMQ or Kafka: choosing per workload
Where an EMS flow is queue-based work distribution or request-reply, RabbitMQ fits its shape, so RabbitMQ is our default target. Kafka is the better answer when the requirement is a retained, replayable event log read by many consumers, and an EMS estate sometimes holds both. The assessment sorts flows, and a single estate can end up with both targets.
- Choose RabbitMQ when — the flow is queue-based work distribution, the consumers acknowledge and move on, and you want JMS or AMQP clients with the fewest code changes.
- Choose Kafka when — consumers need to replay history, many independent consumers read the same events, or the flow is already moving toward streaming and analytics.
- Stay on EMS for now when — an application depends on features neither target provides and is not worth redesigning yet. Staying is a decision with a date, not a default.
TIBCO EMS releases and the dates TIBCO has published
TIBCO EMS is a Cloud Software Group product, and its release notes list the current release as 10.5.0 from February 2026. TIBCO publishes a support-policy notice for each retired release. These are the ones we read on 4 November 2026.
| Release | Retired | What TIBCO says happens |
|---|---|---|
| 8.6.0 | 31 December 2024 | Moved from an earlier July 2024 date. |
| 10.2.0 and 10.2.1 | 31 March 2025 | Notice dated 1 March 2024. |
| 8.7.0 | 30 September 2025 | Notice dated 9 September 2024. |
| 10.3.0 | 31 March 2026 | After retirement TIBCO stops accepting new cases for the release and closes open cases under investigation. Available hot fixes and knowledge base articles remain available. |
| 10.4.0 and 10.5.0 | No notice found | Check TIBCO's support site for the notice that applies to your release. |
AceMQ gives no advice on TIBCO licensing or renewal terms. The dates are TIBCO's, and the useful question is whether the release you run is still taking new cases.
Who this is not for
- Teams expecting a drop-in JMS swap — If your applications depend on XA transactions, queue selectors or atomic local transactions, the move includes redesign. The assessment sizes it.
- Other TIBCO products — BusinessWorks, Spotfire, BPM and other TIBCO products are not covered. This page is EMS only.
- Application rewrites — We map JMS features and tell your developers what to change. Rewriting application logic belongs to your teams.
- TIBCO licensing and renewal advice — AceMQ is an independent provider, not a TIBCO or Cloud Software Group partner. It does not resell licences, negotiate renewals or advise on contract terms.
- Anyone who needs TIBCO's own support — We cannot provide TIBCO patches or act as TIBCO support. Interim cover is engineering help, not a vendor entitlement.
Typical engagements
How these engagements run
Typical engagement scenarios: what the work covers and what it delivers. They describe the service, not past results.
TIBCO EMS to RabbitMQ: JMS Gap Analysis and Parallel Run
Regional Insurer
A typical engagement for a team moving off TIBCO EMS: inventory queues, topics and clients, list the JMS features each application uses against what RabbitMQ documents, then move applications one at a time with both brokers running.
TIBCO EMSRabbitMQJMS
FAQ
Questions about TIBCO EMS to RabbitMQ or Kafka migration
Who can migrate TIBCO EMS to RabbitMQ or Kafka?
AceMQ plans and runs EMS migrations with partner messaging specialists. We inventory queues, topics and clients, map JMS features against the target's documentation, run old and new in parallel and cut over in waves. AceMQ is an independent provider that sells no EMS licences, so we recommend RabbitMQ, Kafka or staying on EMS for each workload on the evidence.
Is moving from EMS to RabbitMQ a drop-in change for JMS applications?
No. RabbitMQ has a maintained JMS client supporting JMS 2.0 and 3.0, but its documentation says XA interfaces are not implemented, local transactions do not guarantee atomicity, and queue message selectors are not supported by the client. Applications that use none of those move with small changes. Those that do need redesign.
Should the target be RabbitMQ or Kafka?
Per workload. RabbitMQ is our default for queued work and request-reply. Kafka fits retained, replayable event streams read by many consumers. Many EMS estates hold both kinds of traffic, so the assessment sorts flows and the answer may be both.
Can we keep EMS running while we move?
Yes, and we plan for it. Old and new brokers run in parallel with a bridge or dual-publish pattern chosen per flow, so applications move one at a time, and EMS stays as the fallback until each flow is signed off. Cutover is per application, not one weekend.
Do you advise on TIBCO licensing or renewals?
No. AceMQ is an independent provider: it is not a TIBCO partner or reseller and gives no licensing or contract advice. We can tell you what your estate uses and which releases TIBCO has retired, from TIBCO's own support policy notices, and plan the move.
Let's talk
Scope a TIBCO EMS Migration
Tell us your EMS release, the number of queues, topics and applications, and the date you are working against. We reply within 1 hour and follow with a written assessment plan.
Get in Touch
Talk to an AceMQ Expert
Send us a message and we'll follow up within 1 hour — 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.