WebLogic to Apache Tomcat: What Actually Migrates and What Doesn't

Tomcat is a servlet container, not a Java EE application server, and that single fact decides whether your WebLogic exit costs six figures or seven. This analysis maps the feature boundary application by application, prices the WebLogic licences you are trying to shed, and tells you which workloads to move first and which to leave behind on a shrunken, downgraded contract.

The Money You Are Trying To Escape

Before anyone estimates refactoring effort, size the prize precisely, because the entire business case is a subtraction problem. On the Oracle Technology Global Price List effective 16 April 2026, WebLogic Server Standard Edition lists at $10,000 per Processor, Enterprise Edition at $25,000, and WebLogic Suite at $45,000, with Premier Support at 22% of net, meaning $2,200, $5,500, and $9,900 per Processor per year at full list. The Suite premium over Enterprise Edition is $20,000 per Processor, and that premium is where the features live (Coherence, Enterprise Manager packs, ADF runtime) that a servlet container cannot consume at all. Run the arithmetic on a modest production cluster: four application nodes, two sockets each, 12 cores per socket, gives 96 cores; apply the 0.5 x86 core factor and you are licensing 48 Processors. At Enterprise Edition list that is $1.2M in licence plus $264,000 per year in support, for four boxes. At Suite it is $2.16M and $475,200 per year. Those numbers are what makes a two-year, multi-team migration programme defensible to a CFO, and they are also why the exit is rarely as clean as the slide deck claims.

Two traps sit between the saving on paper and the saving on your P&L, and both are contractual rather than technical. First, Premier Support is 22% of the net licence fee, list minus your negotiated discount, so decommissioning WebLogic mid-term reduces nothing unless the Customer Support Identifier is restructured and the terminated licences are formally dropped at a renewal boundary. Oracle will happily let you run Tomcat while continuing to invoice the shelf. Second, the same CSI almost always carries adjacent lines Tomcat cannot absorb: SOA Suite at $57,500 per Processor with $12,650 support, Coherence, and legacy Internet Application Server entitlements that nobody remembers buying. In our experience across middleware renewals, the WebLogic line is between a third and two thirds of the CSI, so plan the middleware licensing exit alongside the technical migration rather than after it.

Premier Support is 22% of net, so decommissioning WebLogic mid-term saves nothing until the CSI itself is restructured.

The Support Clock That Sets Your Deadline

Your decision window is 2026 to 2027, and Oracle set it, not your architecture board. Fusion Middleware 12c (12.2.1.4) reaches end of Premier Support in December 2026 and end of Extended Support in December 2027, with Oracle signalling a Market Driven Support programme beyond that, which in practice means bespoke pricing on a shrinking codebase. Critically, 12.2.1.4 is the terminal 12c release: it is the final version carried through the Premier and Extended dates in the Lifetime Support Policy, so there is no minor upgrade that buys you another two years inside 12c. If most of your estate is on 12.2.1.4, you have roughly eighteen months of comfortable runway and then you are choosing between an in-place upgrade, an unsupported production tier, or a migration that is already underway.

Do not treat 14.1.1 as a safe harbour. It was never planned as an LTS or terminal 14.1.x release, and Oracle's own guidance was explicit: once a later 14.1.x version ships, error correction on 14.1.1 ends after a grace period, and customers wanting LTS-only deployments should wait. The real stay option is WebLogic Server 14.1.2, designated Long Term Support with eight years of error correction, structured as five years Premier plus three years Extended. That is a genuine alternative to migration, and you should price it as one, because a credible willingness to upgrade rather than exit is what gives you leverage on the renewal.

One documentation trap causes more wrong internal deadline slides than anything else: the 14.x error correction dates are not in the Lifetime Support Policy PDF for Fusion Middleware dated 13 April 2026. They live in a separate My Oracle Support article, KB65053. Pull both documents, date-stamp them, and put the MOS article reference on the slide, because Oracle account teams will correct a wrong date and use the correction to reset the conversation. Anyone building a timeline for an Oracle middleware negotiation should have both sources in the pack before the first vendor call.

What Tomcat Actually Implements: The Specification Boundary

Stop arguing about Tomcat in terms of "lightweight" versus "enterprise" and state the boundary the way the Apache project itself states it. Tomcat 11.0.x, the current development focus, implements Servlet 6.1, JSP 4.0, EL 6.0, WebSocket 2.2, and Authentication 3.1, the versions required by the Jakarta EE 11 platform, and that list is exhaustive. There is no EJB container, no JTA or XA transaction manager, no JMS provider, no JCA resource adapter framework, no Batch runtime, no CDI as a platform-supplied service, and none of the security realm, WLST scripting, node manager, or diagnostics framework surface that WebLogic administrators treat as baseline. The Jakarta EE Web Profile subset is the migration boundary, full stop, and every application you propose to move has to fit inside it or get re-architected. Two secondary floors set your project constraints: Tomcat 10.1 implements Jakarta EE 10 on Java 11 or later, Tomcat 11.0 requires a Java 17 minimum, and Tomcat 12, still in early development against Jakarta EE 12, will require Java 21 with no announced milestones or dates. If your WebLogic estate is pinned to Java 8 by third-party libraries, the JDK uplift is a prerequisite work package, not a migration side effect. Bring the stability evidence to your architecture board rather than waiting to be asked for it: 11.0 was announced 9 October 2024 but was not considered stable until the Jakarta EE release review completed 7 April 2025, with 11.0.6 shipping 9 April 2025, and the project maintains three parallel lines, with 11.0.24, 10.1.57, and 9.0.120 all released 3 July 2026. Also budget the javax.* to jakarta.* namespace rewrite across every class touching the servlet API; the bundled Apache Tomcat Migration Tool for Jakarta EE automates most of the mechanical work, but in our experience the residual manual effort on reflection, XML descriptors, and shaded dependencies is where schedules slip.

The JMS, JTA, and Clustering Gaps That Block a Clean Exit

This is the argument that decides your budget: WebLogic high availability does not port, it gets rebuilt. WebLogic treats JMS servers and the JTA Transaction Recovery Service as pinned services, designed on the assumption that only one instance is active in the cluster at any moment, and makes them highly available through migratable targets and service-level migration. There is no Tomcat equivalent to that concept, not a weaker one, none. Worse, Transaction Recovery Service migration requires the backup server to read the failed server's transaction logs out of the WebLogic default persistent store, so the recovery guarantee your operations team has relied on for a decade is a property of WebLogic's store format and cluster membership model, not of your application code. A Tomcat target therefore forces one of two designs. Either you externalise both halves, moving messaging to ActiveMQ Artemis, Kafka, or a managed cloud queue, and embedding a standalone transaction manager such as Narayana or Atomikos to keep two-phase commit, or you abandon XA outright and redesign the affected flows to be idempotent with compensating actions and a retry ledger. Both are legitimate. Neither is free, and the second is the one that generates the multi-quarter developer effort that makes seven-figure exits happen. Add the sleeper breaking change most plans miss: SecurityManager support is completely removed in Tomcat 11, deprecated in Java 17 and dropped from the Jakarta EE 11 specification, so any WebLogic estate using policy-based sandboxing to separate tenants or restrict untrusted code loses that control outright and must replace it with container or operating system isolation. In practice, the applications that clear this bar cleanly are stateless HTTP and REST tiers with a single JDBC datasource, and the ones that do not are the integration hubs, batch orchestrators, and anything with a message-driven bean. Score each one before you commit to a date, and read the licensing consequences of a split estate in our guide to migrating off Oracle WebLogic and the licensing exit, because leaving ten percent of your workloads behind can preserve the full support bill.

WebLogic high availability does not port, it gets rebuilt.

Application Triage: Sorting Your Estate Into Four Buckets

Do not survey your estate application by application and argue each one on its merits. That produces a spreadsheet nobody trusts and a migration plan nobody funds. Run a four-bucket triage instead, applied mechanically against deployment descriptors and datasource configuration, and let the buckets carry the argument. In the estates I have triaged over the past two decades, roughly 60 to 70 percent of applications by count land in bucket 1, and those same applications account for a much smaller share of the WebLogic Processor licences you are paying for, because the expensive nodes are the ones running the transactional and messaging workloads. That asymmetry is the single most important thing to establish before you brief a steering committee: high application counts move cheaply, high licence consumption does not.

Two costs apply to every bucket and are routinely omitted from business cases. First, the javax.* to jakarta.* namespace change introduced in Jakarta EE 9: any move to Tomcat 10.1 or 11.0 requires rewriting imports across every class touching the servlet API. The Apache Tomcat Migration Tool for Jakarta EE, bundled and updated throughout the 11.0.x series, automates most of the import rewriting, but it does not reconcile runtime behaviour, third-party libraries that still ship javax bytecode, or reflective class loading. Budget regression testing, not translation. Second, Tomcat 11 removed SecurityManager support entirely, so any WebLogic application that relied on policy-based sandboxing loses that control and needs a compensating design. Price both before you commit to a wave plan, and read the wider exit economics in migrating off Oracle WebLogic.

Partial Migration Is Normal, So Plan the Licence Position Around It

Assume you finish at 70 to 85 percent Tomcat with a residual WebLogic footprint carrying the bucket 3 applications. That is the normal outcome, not a failure, and it is commercially fine only if you restructure the contract deliberately rather than letting a smaller deployment sit under an unchanged CSI. Four levers do the work. First, consolidate the residual WebLogic onto the smallest defensible core count before your renewal date: at the 0.5 x86 core factor, every two cores you remove is one Processor licence, so a 96-core four-node cluster at 48 Processors and Enterprise Edition list pricing of $25,000 per Processor is $1.2M of licence and $264,000 a year of support that consolidation attacks directly. Second, test the Processor to Named User Plus crossover at 50 users per Processor for genuinely low-user internal applications, which is where residual bucket 3 workloads often sit.

Third, downgrade the edition. If Coherence, the Enterprise Manager packs, and the ADF runtime are no longer consumed because those applications either moved or were retired, you are paying the $20,000 per Processor list delta between WebLogic Suite ($45,000) and Enterprise Edition ($25,000) for nothing. Fourth, and most often skipped, terminate or split the CSI so support actually falls with the licence count. Premier Support is 22 percent of the net licence fee, so a mid-term reduction in deployment changes nothing at all unless the support agreement is restructured at renewal. Oracle publishes no discount schedule. Reviewed Oracle technology quotes land 25 to 85 percent below list, with database at the deeper end and middleware historically discounting less, so build the business case against your actual net position, not against published list. If you need to sharpen the ask, the negotiation leverage analysis covers what actually moves Oracle price.

A smaller WebLogic deployment under an unchanged CSI saves nothing: support is 22 percent of net licence fee, and net licence fee does not fall because you stopped deploying.

What To Do First: A 90-Day Sequence

Weeks 1 to 3 are pure evidence gathering, and none of it involves Oracle. Pull the CSI and list every Fusion Middleware line on it, not just WebLogic: SOA Suite at $57,500 per Processor list, Coherence, and the legacy Internet Application Server lines all sit on the same price list at the same 22% support rate, so retiring WebLogic alone rarely retires the CSI. Confirm the exact production versions against MOS KB65053, because 14.x error-correction dates live there and not in the April 13, 2026 Lifetime Support PDF, which is the single most common source of wrong internal deadline slides. Then freeze the deployment count: number of instances, sockets, cores, and core factor, dated and signed.

Weeks 4 to 8 are technical. Run the four-bucket triage with an automated XA and JMS dependency scan across every deployed EAR and WAR, not a sample. Get the architecture board to ratify Tomcat 11.0.24 as target and Java 17 as the floor, and document the SecurityManager removal as an accepted risk rather than a discovery in month five.

• Weeks 9 to 12: build the residual-footprint licence position, model the Suite-to-Standard downgrade (the $20,000 per Processor Suite premium over Enterprise is the first thing to challenge), and restructure the CSI, since support at 22% of net does not fall just because licences go unused.
• Open the renewal conversation with a documented reduction case before Oracle frames the discussion around post-2027 Market Driven Support pricing. See our middleware migration and licensing exit analysis for the sequencing detail.

Two prohibitions from repeated experience. Do not tell the account team you are migrating before the licence position is set, because that converts your exit into their forecast problem and their audit trigger. Do not decommission instances without retaining deployment evidence; you will need it to defend the historical footprint, and audit questioning starts from what you cannot prove.

Related advisory: the full topic guide.

Frequently asked questions

Can Apache Tomcat replace Oracle WebLogic outright?

Only for applications that live inside the Jakarta EE web profile. Tomcat 11 implements Servlet 6.1, JSP 4.0, EL 6.0, WebSocket 2.2, and Authentication 3.1, and nothing more, so anything relying on EJB, container-managed JTA/XA transactions, JMS, or JCA needs external components or a rewrite. In practice most estates land at 70 to 85% Tomcat with a residual WebLogic or alternative-server footprint for the blocked applications.

What happens to my JMS queues when I move to Tomcat?

They do not move; Tomcat has no JMS provider. You deploy an external broker such as ActiveMQ Artemis, Kafka, or a managed cloud queue and re-point the application, then rebuild the high availability behaviour that WebLogic gave you through pinned services and migratable targets. Budget for redelivery, ordering, and dead-letter semantics changing, because those are broker-specific and will surface in testing, not in design review.

Does migrating to Tomcat reduce my Oracle support bill immediately?

No. Premier Support is 22% of the net licence fee, and Oracle will keep invoicing the full CSI until the licence quantities are formally reduced or the CSI is restructured at renewal. Decommissioning servers without a contractual change saves you nothing, so sequence the licence position before the technical cutover.

When does WebLogic 12c support actually end?

Fusion Middleware 12c (12.2.1.4) Premier Support ends December 2026 and Extended Support ends December 2027, with 12.2.1.4 as the terminal 12c release. Oracle has signalled a Market Driven Support program beyond 2027, which is discretionary and priced accordingly. Confirm your own dates against MOS KB65053 for 14.x, because the Lifetime Support Policy PDF does not carry the 14.x error-correction dates.

Should we go to WebLogic 14.1.2 instead of migrating?

It is a legitimate holding position: 14.1.2 is a Long-Term Support release with eight years of error correction, structured as five years Premier plus three years Extended. The tradeoff is that you keep paying 22% support on the same Processor count and stay exposed to Oracle's core-factor and virtualisation positions. Use it to buy time for triage, not as a substitute for a decision.

What is the biggest hidden cost in a WebLogic to Tomcat project?

Two of them compete. The javax.* to jakarta.* namespace change touches every class using the servlet API across the whole portfolio, and the complete removal of SecurityManager support in Tomcat 11 strips policy-based sandboxing from any multi-tenant deployment that relied on it. Third is the Java SE licensing question, which frequently arrives with the JDK 17 or 21 upgrade that Tomcat 11 and 12 require.