TIBCO EMS Retirement: Matching Messaging Workloads to Kafka and AMQ

Executive summary

Replacing the broker safely required more than choosing a less expensive technology. We had to identify how each workload behaved, match it to the right platform, establish a second migration path when testing exposed gaps in discovery, and keep application teams moving toward a commercial deadline.

The business problem

An upcoming TIBCO EMS renewal coincided with broader cost-reduction goals. Renewing preserved an expensive platform; forcing every application onto Kafka ignored transactional and conventional broker behavior. The program therefore had to identify active destinations and owners, define when each workload belonged on Kafka or AMQ, and migrate or retire it without disrupting ecommerce, inventory, or scheduling processes.

My role and scope

I began the initiative as a Staff engineer and was promoted to Senior Software Engineering Manager shortly afterward. I owned the executive recommendation, contract timeline, workload analysis, product guidance, budget alignment, delivery accountability, testing strategy, migration tracking, and escalation when application-team commitments slipped.

I partnered with a program manager on the integrated plan and dependencies while remaining accountable for the organizational change required to keep the migration moving.

Building the workload inventory

An automated process retrieved TIBCO topics and queues and cross-referenced them with usage and team mappings. The resulting inventory went beyond broker objects: it tracked activity, ownership, message pattern, replay needs, transactional behavior, target platform, test status, migration date, and risk.

The same evidence later exposed ghost jobs and destinations whose ownership could no longer be established, giving leaders a basis for deliberate shutdown decisions.

Matching workloads to Kafka and AMQ

Approximately 90% of the portfolio aligned with Kafka’s strengths: asynchronous event distribution, replayable streams, multiple independent consumers, and high-throughput integration. Testing showed that the remaining workloads depended on transactional or traditional broker behavior and could not move safely without refactoring.

Rather than turn the migration into a blanket Kafka mandate, I established a decision model that mapped supported use cases to Kafka or AMQ. I also aligned adjacent portfolios, documented ownership through a RACI, and tied cloud AMQ readiness to the contract-exit plan.

Reducing migration friction and managing the exit

Requiring every application to adopt a new independent client would have created a cleaner long-term boundary but threatened the deadline. I directed changes to the existing high-availability client so teams could migrate with less disruption, sequencing immediate contract exit ahead of an ideal future ownership model.

As the deadline approached, I used the program plan to identify late teams, escalate missed commitments, and require recovery plans or explicit risk decisions. Remaining ghost jobs were reviewed with executive oversight and manually disabled when ownership could not be resolved.

Measured results

• Retired TIBCO EMS from the targeted ecommerce application portfolio.
• Migrated approximately 1,000 topics and queues across roughly 15 teams.
• Moved approximately 90% of workloads to Kafka and 10% to cloud AMQ.
• Reduced annual licensing costs by approximately $1.3 million.
• Completed the program with approximately one month remaining before the contract deadline.
• Established reusable platform-selection and ownership guidance for Kafka and AMQ.

Leadership lessons

Infrastructure inventory is not the same as use-case discovery. A migration should begin with explicit product boundaries, supported patterns, and workload-level mapping, then use testing to validate behavior before committing every application to a destination.

Related projects