WebSphere Migration and Support
Last reviewed by Tyler Eastridge
AceMQ helps enterprises that run IBM WebSphere Application Server decide whether to stay, move to WebSphere Liberty, or move to Tomcat or JBoss, then plans the platform move in waves with a rollback for each and gives 24/7 production support for the estate you keep. IBM states no planned end-of-support date for traditional WebSphere 8.5.5 and 9.0.5, so the reason to move is cost or fit, not a deadline. AceMQ is an independent provider and not an IBM reseller. WebSphere MQ is now IBM MQ and has its own AceMQ pages.
A senior engineer, not an SDR. No sales sequence attached.
Without rewriting your applicationsFor production incident cover, see AceMQ WebSphere 24/7 support.
Customers
Partners
The Problem
Six WebSphere problems that teams bring to AceMQ, from an infrastructure bill nobody can break down to a migration wave that stalls on one application. If one describes your quarter, that is where the work starts.
Traditional WebSphere is a large line on the infrastructure bill and nobody has written down what each cell actually runs
Someone says WebSphere is end of life, but IBM's own support page lists no planned end-of-support date for 8.5.5 and 9.0.5, so the real driver is cost or platform fit
Liberty, Tomcat and JBoss each support a different set of Jakarta EE features, and the choice is argued from opinion instead of from what the applications use
Applications depend on things defined in the cell and not in the application: JNDI names, data sources, JMS destinations, resource adapters and shared libraries
Deployment runs on console clicks and scripts that nobody can replay to build a new environment
A migration wave stalls on the one application nobody inventoried, and the old and new runtimes both stay on the bill
A good fit if you run WebSphere Application Server across several applications and need an independent stay-or-move answer, a platform move planned in waves, or senior engineers on call for the estate you keep.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy WebSphere.
How it breaks, and the fix
A wave moves three applications to a new runtime. One is a plain web application. The other two lean on things that were defined in the old cell and not in the application. The wave is only as safe as the inventory behind it.
One migration wave to a new runtime
Three applications, one rollout, the old cell kept
All three applications run on traditional WebSphere, with their data sources, JNDI names and adapters defined in the cell. Nothing has moved yet.
The wave moves the three applications. The web-tier app starts. One application looks up a JNDI name that exists only in the old cell, and the other needs a resource adapter the new runtime does not have, so both fail.
The wave is paused, not abandoned. The binding is recreated in the new server's configuration, the adapter is replaced or that application stays on the old cell, and the wave resumes with the old cell still available for rollback.
A traditional WebSphere application often depends on resources defined in the cell rather than in the application: JNDI names, data sources, JMS destinations, resource adapters, shared libraries and security settings. They move with the runtime only if someone recreates them, and Tomcat implements only a subset of Jakarta EE, so EJB, JMS and adapter dependencies need a library or another runtime there. The assessment lists these per application before any wave starts, so a missing binding turns up in a test environment, and the old cell stays available until a wave has run clean.
Our Services
AceMQ runs five WebSphere service lines: a stay-or-move assessment, Liberty planning, Tomcat or JBoss planning, 24/7 production support and a fixed-scope health check. Support can follow any of them. AceMQ is an independent provider, not an IBM reseller, and has no access to IBM fixes.
A written answer to whether the estate should move at all, based on what the applications use and what the runtime costs you to keep.
A plan for moving applications from traditional WebSphere to WebSphere Liberty or Open Liberty, with the configuration mapped and the waves ordered.
The same assessment for moves to Apache Tomcat or to JBoss EAP and WildFly, including a written account of what each target does not provide.
24/7 engineers for the WebSphere or Liberty estate you keep: hung servers, failed deployments, resource exhaustion and configuration failures.
The fixed-scope entry engagement: a written report on how your cells are configured and where they are exposed, which your team can act on with or without AceMQ.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ gives you an engineer and a 15-minute first response when a WebSphere or Liberty server fails in production, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Fixes for IBM software still come from IBM: AceMQ has no access to them.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
How It Works
An AceMQ WebSphere engagement runs in four stages: a scoping call with a quote within 1 hour, an application assessment, a written target decision, then waves or ongoing cover. Each stage ends in writing.
Quote within 1 hour
A senior AceMQ engineer asks what you run: WebSphere version and fix pack, cells and nodes, how many applications, what has prompted the question and what you already know about the target. A quote request is answered within 1 hour.
Scoped per estate
Each application classified by what it uses and what it needs from the runtime. IBM Transformation Advisor, which IBM describes as determining the complexity of applications and estimating the effort to a modern Java runtime, is one input. AceMQ reads its output next to a manual review of bindings and resources.
Scoped per estate
A written recommendation per application group: stay on traditional WebSphere, move to Liberty, move to Tomcat or move to JBoss EAP or WildFly. Staying is a valid answer and the plan says when it is the right one.
Ongoing or fixed scope
Pilot applications first, then waves with the old cell kept for rollback. The work ends with a runbook for the new runtime. You can stop there or add 24/7 cover for whichever runtime you keep.
A senior engineer, not an SDR. No sales sequence attached.
Moving off traditional WebSphere
The runtime is the part AceMQ plans and moves. The applications stay as they are: where one needs a source change to run on the target, the assessment names it and your developers own it. Three steps, in this order.
Classify
Each application goes into one of three groups: web tier only, uses EJB, JMS or resource adapters, or depends on WebSphere-specific bindings. The groups decide which targets are open to it, because Tomcat implements only a subset of the Jakarta EE specifications.
Choose
Open Liberty documents Jakarta EE 11 and 10 features, EAP 8.0 provides Jakarta EE 10, and Tomcat 10.1 and 11.0 target Jakarta EE 10 and 11 as a subset. The written plan matches each group to a target and records what is lost or gained by that choice.
Move
A pilot application first, then one wave at a time with the old cell still running for rollback. A move to a new runtime does not share a window with a JDK, database or version upgrade, so a failure has one cause.
Typical engagements
Typical WebSphere engagements from AceMQ: what the environment looks like, what AceMQ assesses or changes, and what the engagement delivers.
Solutions
AceMQ covers WebSphere end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed WebSphere on your infrastructure and fully managed WebSphere on AceMQ infrastructure, plus end-of-life versions.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running WebSphere for you.
Compare the four WebSphere support tiersSide by side
Each destination trades something. Liberty is the shortest step inside IBM's family, Tomcat is the lightest and supports the least, and JBoss EAP is a full platform from Red Hat. Staying is a real option too, because IBM lists no planned end of support. Each row below answers one question.
| Question | Stay on traditional WebSphere | WebSphere Liberty or Open Liberty | Apache Tomcat | JBoss EAP 8 or WildFly |
|---|---|---|---|---|
| What do the vendors say about support dates? | IBM states no planned end-of-support date for 8.5.5 and 9.0.5. Any fix pack is eligible for an iFix for two years from its release, and security iFixes cover the two most recent fix packs (IBM policy page, 9 September 2026). | IBM says Liberty follows a continuous-delivery lifecycle and has no end-of-support date. Open Liberty 26.0.0.11 was the latest release on 3 November 2026. | Tomcat 10.1 and 11.0 are current lines. Tomcat 9.0 is the last for Java EE 8, and the project expects its end of support no earlier than 31 March 2027. | EAP 8 has Full Support to 5 February 2028 and Maintenance Support to 5 February 2031 on Red Hat's data. WildFly is a community project with frequent releases. |
| Which Jakarta EE level does it give you? | Set by the WebSphere version and fix pack you run. AceMQ reads IBM's documentation for the exact level. | Open Liberty's documentation lists API and feature sets for Jakarta EE 11, 10, 9.1 and 8, including jakartaee-11.0 and webProfile-11.0. | A subset only: Servlet, Pages, Expression Language, WebSocket, Authentication and Annotations. Tomcat 10.1 targets Jakarta EE 10 and 11.0 targets Jakarta EE 11. | EAP 8.0 provides Jakarta EE 10. |
| What breaks when an application moves in? | Nothing. This is the option that needs no migration. | Configuration moves from the cell into Liberty's server configuration files, and bindings that were defined in the cell have to be recreated for each application. | EJB, JMS and resource adapters are outside the subset, so an application that uses them needs libraries or a different runtime. | The javax to jakarta change if the application is built for an earlier Java EE level, plus the same cell-defined bindings. |
| Who answers when it fails at 3am? | IBM, under your IBM support terms, and an AceMQ engineer within 15 minutes for diagnosis and operations. | IBM for WebSphere Liberty under IBM support terms, and an AceMQ engineer within 15 minutes, 24/7. | An AceMQ engineer within 15 minutes, 24/7, if you take Tomcat support. | Red Hat under a subscription for EAP, and an AceMQ engineer within 15 minutes, 24/7, for any of them. |
| When does it fit, and who should stay? | The runtime cost is acceptable and the applications are stable. AceMQ will say so in the assessment and quote support instead of a move. | Applications fit the Jakarta EE level you need and you want the shortest step with the least rework. | Applications use only the web tier. A team that wants applications rewritten rather than moved should look elsewhere. | Applications need a fuller platform and you accept a Red Hat or community model. |
For Java runtime lifecycle dates by vendor, read Tomcat versions and end-of-life dates. AceMQ is an independent provider: it resells no IBM or Red Hat software and gives no vendor licensing advice.
One partner, not five
WebSphere rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
Guides from AceMQ engineers on Java runtime lifecycles, plus the AceMQ services around the application server: JBoss, Tomcat, IBM MQ and the JDK.
FAQs
Five answers on WebSphere from AceMQ: end of life, which target to choose, the IBM MQ name and what AceMQ does not sell.
Still have questions about WebSphere? Email an Expert
IBM states there is no planned end-of-support date for traditional WebSphere 8.5.5 and 9.0.5 (IBM's support FYI page, updated 17 July 2025), and its lifecycle pages list WebSphere 9.0.x as generally available since 24 June 2016 with no end-of-support date. IBM's wording is no planned date, not a contractual commitment, so ask IBM for anything you need in writing. The decision to move is usually about cost, platform or fit.
It depends on what each application uses, which is why the assessment classifies applications first. Liberty is IBM's own continuous-delivery line, and IBM says it has no end-of-support date. Tomcat implements only a subset of Jakarta EE, so applications that use EJB or JMS need libraries or another runtime. JBoss EAP 8 provides Jakarta EE 10 under a Red Hat subscription. Staying on traditional WebSphere can also be the right answer.
No. IBM renamed WebSphere MQ to IBM MQ at version 8, and it is a messaging product, not an application server. AceMQ covers it on its own pages for IBM MQ support and for IBM MQ migration to RabbitMQ. This page covers WebSphere Application Server only.
Yes. AceMQ works on WebSphere in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your WebSphere environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how WebSphere is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer reviews your WebSphere estate, tells you what to assess first, and quotes the work. Quote requests are answered within 1 hour.
Production incident right now?Email a WebSphere Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
