In this Post

    Migrating from a legacy middleware platform like IBM MQ to a modern event-driven integration platform like PubSub+ can seem daunting, but Solace provides products that facilitate the process, and has developed processes and tools over the course of helping dozens of companies make the switch.

    This paper will help you understand how to most easily and effectively upgrade your own infrastructure from MQ to PubSub+ depending on your environment and objectives.

    Proven Migration Approaches

    Solace has helped many leading enterprises successfully migrate from IBM MQ to PubSub+, including big banks, leading credit card companies, telcos, and more. You can learn about several successful migrations here.

    Most migrations are done in three ways, each of which are suitable for different situations, objectives and resource constraints: message dual publish, bridging with a packaged micro-integration for MQ, and flash cutover. You can learn about these approaches and how to choose the right one for you. (Needs to go to gated version)

    Message Dual Publish

    Message dual-publish is a migration approach by which you have publishing applications send messages to both platforms, let subscribers select which platform they consume messages from, and phase out the use of the old platform as soon as all subscribers are using the new platform.

    Basic Steps

    1. Publisher client sends message on old broker and Solace broker at the same time
    2. One by one, clients move over to Solace
    3. When all clients are moved, publisher client stops publishing on old broker
    4. When all flows are migrated, old broker can be shutdown

    Pros, Cons and Keys to Success

    • Pros: Controlled, incremental migration process
    • Cons: Complex approach that risks data inconsistency or loss
    • Keys: Must implement robust data validation processes

    Learn more about the message dual-publish approach.

    Interface Bridging

    The interface bridging migration strategy revolves around connecting the old and new messaging systems, enabling bi-directional communication. This approach allows for a phased transition, where legacy clients can continue top use MQ while new clients interface with the new messaging system. Establishing a bridge between the platforms to gradually refactor and migrate applications from the old platform to the new one. Solace provides a micro-integration for IBM MQ that makes it easy to take the interface bridging approach with IBM MQ.

    Basic Steps

    1. Initially all clients are using the old broker
    2. A bi-directional bridge connects old broker with Solace broker
    3. New clients are built are top of Solace broker and can interface with legacy clients
    4. One by one, legacy clients move over to Solace once they are refactored
    5. When all flows are migrated, old broker can be shutdown

    Pros, Cons, and Keys to Success

    The main benefit of interface bridging is the flexibility it provides, allowing organizations to migrate applications at their own pace and reducing the risk of disruption to critical business processes.

    • Pros: Flexibility and phased migration
    • Cons: Complex bidirectional bridge configuration and monitoring.
    • Keys: Establish reliable monitoring and optimization

    Learn more about the interface bridging approach.

    Flash Cutover

    Flash cutover is this is the fastest way to get rid of legacy platform so you can start saving on infrastructure costs, licensing costs and generally get free and clear of EOL products most quickly with this approach. Flash cutover migration entails getting all publishers and subscribers ready to send and receive messages via your new platform, then “flipping the switch” when the time is right.

    The process entails removing the interface and dependencies to the old messaging platform and implementing all flows on the new one.

    Basic Steps

    1. Interface to old broker is removed ​
    2. Publisher and subscriber clients are integrated with Solace broker​
    3. One by one, all flows are implemented on Solace​
    4. When all flows are migrated, old broker can be shutdown

    Pros, Cons, and Keys to Success

    • Pros: Clean transition to a modern platform
    • Cons: Potential service disruption during transition.
    • Keys: Execute seamless migration with vigilant monitoring.

    Learn more about the flash cutover approach.

    Environment-Specific Migration Strategies

    Here is how we apply those approaches to a few scenarios where IBM MQ is in use.

    App Connect Enterprise (ACE)

    ACE is used for integrating with transaction hosts like mainframe and mid-range-based applications, among others, and has connectivity nodes for MQ and Mainframe using Cobol copybook.

    Migration strategy:

    • Replace MQ Cluster (non-MQI applications) with Solace VPN
    • Create the corresponding queue on Solace VPN
    • ACE brokers can talk to Solace using JMS or JCA adapter
    • It only requires connectivity replacement
    • The integration with IMS/CICS can remain as-is

    After the migration, native JMS applications will be unchanged as Solace supports JMS 1.1 specs. Application servers can communicate with Solace either on JMS or using the JCA resource adapter.

    This diagram depicts a typical deployment of ACE with MQ and transaction hosts:

    DataPower to Connect Mainframe

    Migration strategy:

    • DataPower to MQ flows can be replaced with REST over HTTP POST connectivity to Solace
    • MQ Queues (Local as well as Cluster Queue) can be replaced by Solace Queue / Durable Topic endpoints
    • DataPower integration with other endpoints should remain the same except for replacement of MQ connectivity endpoints

    This diagram depicts a typical deployment of Datapower linking mainframe and new assets.

    DataPower as B2B/B2C Gateway

    Typically, DataPower appliances are hosted in a DMZ, passing traffic to a core network containing another set of DataPower appliances or an MQ Cluster. PubSub+ is a natural choice for MQ replacement in this scenario as it provides a complete datapath eliminating MQ clusters.

    This diagram depicts a typical deployment of using Datapower as a B2B/B2C gateway, before and after migrating from MQ queue managers to a PubSub+ Event Broker.

    The migration strategy in this scenario:

    • Replace DataPower to MQ flows with REST over HTTP POST connectivity to Solace
    • Replace MQ Queues (Local as well as Cluster Queue) with Solace Queue / Durable Topic endpoints

    Proven Migration Process

    In order to migrate from IBM MQ to PubSub+, you’ll need a detailed plan that addresses your applications, business processes, development practices, and infrastructure. The plan should involve your IT operations, middleware, and application teams, and document a set of milestones that ensure a migration pace that makes sense for your business.

    This section breaks down the series of steps our professional services team follows when helping a company migrate from MQ to PubSub+.

    Assessment

    The first step in any migration is to determine the size and complexity of the system being migrated. Here are the steps you should take at this phase of your migration:

    1. Collect operations inventory:  Identify scripts, tools, utilities, and processes used to operate the existing ecosystem.
    2. Collect application inventory: Identify applications and categorize based on application risk profile, priorities, 3rd party/COTS software products, and other factors related to migration.
    3. Collect performance information: Identify current and future expected performance requirements related to message sizes, volumes, failures mode recovery objectives, latency, bandwidth use, and other performance risk aspects for the messaging middleware ecosystem.
    4. Assess operational readiness: Evaluate the experience level of the existing teams to support migration to Solace products.
    5. Develop migration strategy and timeline: Develop a customized approach and timeline suited to your goals and capabilities.

    Preparation & Planning

    Once you’ve collected all of the above information and have a solid understanding of where you stand, the next step is to formulate a plan not just for the migration itself, but for how you will communicate and work with stakeholders across your organization.

    You’ll also want to put in place the lab environments in which you’ll work, and the tools you’ll use to automate both development and testing.

    1. Communicate roadmap to stakeholders: Inform leadership and other stakeholders of the plans, processes, and key individuals who will be responsible for the migration
    2. Develop communication plan: Prepare to educate and inform the organization with brown bags sessions, town halls, and other means of communicating to help reduce anxiety and concerns
    3. Develop project plan: Create high-level plan with milestones that objectively demonstrate progress
    4. Set up lab environment: Initial environment to test theories and help onboard the migration team
    5. Perform baseline testing: Demonstrate equivalency of functionality and performance between legacy and Solace messaging systems, focusing on system-level items like monitoring and management
    6. Develop automation utilities: Create and test migration utilities, to simplify and speed up certain manual tasks

     Develop Abstraction Layer (if necessary)

    If you’re taking an approach that entails having both MQ and PubSub+ operational at the same time, you’ll need to develop a custom messaging interface that insulate applications from technology and product changes so they can communicate via either platform. Here’s what that entails:

    1. Design the abstraction layer: Identify the interface operations and signatures.
    2. Development and unit testing: Implement the interfaces in the target languages that need to be supported.
    3. System testing: Test the interfaces for functional equivalence with current legacy and Solace messaging features.
    4. Performance testing: Test the interfaces for HA, DR, throughput, and other performance characteristics to maximize investment in Solace while balancing trade-off for simplified migration.

    Run a Pilot Project

    Once the plan is set and an abstraction layer is in place, if necessary, you should run through the migration process at least once to ensure it is understood by everyone, and meets everyone’s expectations, so you can create an internal success story that galvanizes support for the migration of additional applications.

    1. Test the target application: Capture performance data for the application with current messaging system
    2. Migrate the application: Modify the application code if and as necessary, creating a recipe book for future applications to follow
    3. Regression testing: Test the functionality of application with Solace messaging system.
    4. Performance testing: Test the performance of application with Solace messaging system full in place, e.g. latency, throughput, HA/DR recovery, etc.
    5. Test environment operational support: Validate that monitoring and management capabilities are similar or better for application teams and system administration and operations teams.

    Optionally, you can run the application in parallel and compare results for a period, which will of course require the creation of custom comparison utilities.

    Operational Readiness

    With a successful pilot project in the can, it’ll be time to ensure the organization responsible for the Solace ecosystem is ready to handle things when applications start moving into production on Solace

    1. Prep UAT and production environments: Configure Solace brokers for production use, including integration with security services
    2. Update monitoring systems: Integrate Solace products into system monitoring systems, setup system-level alerts and thresholds
    3. Update management systems: Integrate Solace products into system management systems, including change management, backup and recovery, and scripting aspects
    4. Update and modify ops procedures: Integrate Solace products into system operational procedures including call center assistance, web portal/self-service capabilities, runbooks, and other operational areas
    5. Train ops personnel: You’ll want to sign the operations team up for Solace training so they can troubleshoot and resolve production issues during the migration period.

    Application Conversion

    Once you’re sure the ops team is ready to support the Solace ecosystem after migration, it will be time to move ahead with the conversion and testing of all applications according to the migration roadmap.

    • Baseline Test Application: Capture test results of the application with current messaging system.
    • Perform application conversion: Modify the application code using recipe book developed during pilot phase.
    • Regression test application: Test application with Solace messaging system after modifications, including performance testing.
    • Oversee deployment to production: Prepare application deployment scripts including Solace configuration information, and oversee promotion of application to production environment.
    • Provide post deployment monitoring: Oversee application running in production for a defined period until confidence is established that it is stable.

    Optionally, you can run the application in parallel and compare results for a period (custom comparison utilities will need to be developed)

    Post-Migration Decommission

    Once you’ve migrated all or part of your MQ estate to PubSub+, you will want to make sure everything works as expected and necessary, then proceed to decommission software and hardware assets that are no longer necessary.

    • Ensure all messages are consumed: Verify that legacy messaging system messages are all properly handled and that no new messages are still accumulating.
    • Ensure all connections are released: Verify that no applications are still connected and using the legacy messaging system.
    • Shut down broker instances: Shut down and remove of legacy messaging system instances.
    • Update operational procedures: Remove references to legacy messaging system from operational utilities, processes and procedures.
    • Recover and redeploy hardware: Find ways to reuse physical assets no longer required as a result of migrating to Solace products.

    Ready to Migrate from IBM MQ?

    If you’re eager to embrace the cloud, sick of slow recovery times, and tired of maintaining a massive middleware estate, Solace PubSub+ can help.

    We’ve helped some of the world’s largest global companies migrate from IBM MQ to PubSub+. Book a consultation with an expert and learn how to start your journey to a more agile and future-proof messaging ecosystem!