We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.


Table of Contents

1. Overview

2. Examining Migration Objectives: Why Migrate a Java EE Application?

   2.1 Reduce Complexity

   2.2 Reduce Operating Costs

3. Examining Java EE Application Migration Targets

4. Confirming Migration Ability

   4.1 Techniques for Determining Migration Suitability

5. Migrate the Application to Tomcat

   5.1 Web Application Deployment

6. Conclusion

1. Overview

While it has been commonplace (and well documented) for IT organizations to migrate Java EE applications initially developed on Apache Tomcat upward to commercial Java application servers, such as Oracle’s WebLogic, in recent years the trend has been reversing. There are a number of compelling reasons for creating new web applications using today’s deployment architectures on Tomcat instead of WebLogic, but perhaps even more interesting is the trend to migrate existing Java EE applications from WebLogic to Tomcat.

In this white paper, we explore the reasons for migrating from WebLogic to Tomcat, considerations for making the decision, and techniques to be followed for a successful migration. Note that when we talk about Java EE applications, we are including applications, application components, and SOA service instances, each of which is an “application,” even when the user is another service or application, rather than a human.

When we are discussing “migration,” we are focusing on those applications that would transition from WebLogic to Tomcat without major re-architecture or re-write. While it is theoretically possible to move any application from WebLogic to Tomcat, those involving sophisticated transactionality (EJB or CORBA, for example) would require so much development effort that they should be considered a completely new application, not a migration.

While there is no single process for determining migration requirements and strategy, this white paper describes steps that can be used to make a migration decision and successfully implement it. The steps typically include:

  • Set migration objectives: determine the reasons for the migration program. These may include business needs, cost savings, technical/architectural objectives, etc.
  • Set migration targets: identify those Java EE applications with migration potential based on meeting the above objectives.
  • Confirm migration ability: assure that the selected Java EE applications can be migrated from WebLogic to Tomcat. This step will typically involve code analysis, trial migration, etc . Watch in particular for the use of “hidden services”... portions of WebLogic “auto-magically” used by your Java EE application without explicit developer activity.  Also important would be considering any WebLogic or third-party administrative tools used by IT staff, which might not be available for or compatible with Tomcat.
  • Identify external services: Determine those services external to Tomcat that may be needed, factoring in costs to provide those services.
  • Convert code: convert selected Java EE applications to Tomcat, coding as required and migrating administrative/deployment/management tooling  as required.

2. Examining Migration Objectives: Why Migrate a Java EE Application?

This is the first, and probably most important, question to ask, particularly when you already have a stable running Java EE application on WebLogic and there will be both costs and risks associated with making the changes. There may be a number of answers to this question, including the need to expand capacity, reduce IT systems complexity, retire WebLogic licenses due to vendor changes or to reduce overhead, and to reduce ongoing costs. 

2.1. Reduce Complexity

Another frequent objective for migration is to reduce the complexity of the IT environments. While WebLogic is extremely powerful, it is also very complicated, both to program and to administer . Today’s  IT budgets require “do more with less” processes and staffing, making it difficult to sustain such server environments. 

Developer productivity is also somewhat higher with Tomcat, particularly for those applications that do not require the complexity of WebLogic. Whereas a Java developer may take days to set up and configure instances of WebLogic, they can often do this in hours or even minutes for Tomcat .  During development/debugging, Tomcat can be stopped and re-started (“bounced”) in a few seconds, rather than the minutes required each time by WebLogic. In one study , this impacted developer productivity by more than an hour per day.

Also driving complexity reduction is the need for IT agility. Whereas business applications used to take years to develop and deploy, business requirements now demand applications in weeks/months. This requirement drives architectural and process changes, including a transition to a more horizontal, lighter-weight, more modular deployment architecture. WebLogic is both too costly and too heavyweight  to meet these requirements.

2.2. Reduce Operating Costs

Maintaining WebLogic is very costly, not the least because of the vendors service contract pricing, but also because of the amount of hardware required to support a WebLogic instance and the associated space/power/cooling costs.  With typical Tomcat operating costs/server coming in at 1/4 to 1/6 the cost of WebLogic , many IT organizations are investing in transitioning all possible web applications from WebLogic to Tomcat, reserving their WebLogic servers for Java EE applications that require EJB or other major Java EE facilities that Tomcat does not offer.

Cost reduction is the driver for many of the migration projects , although  as we see below, the single largest component of WebLogic operating cost is the service contract, which may not be readily re-targeted and is typically not cancellable.

3. Examining Java EE Application Migration Targets

Selecting suitable Java EE applications for migration is an important step. Typically, it depends on the objectives from above, some educated guesswork regarding what applications might be suitable for migration, and some thoughts about cost savings. With multiple interacting factors in play, this is typically a somewhat iterative process. For example, migrating a specific application might achieve business objectives, but upon detailed analysis, it might prove to be too highly integrated into WebLogic services that are not available in Tomcat and too costly/complex to provide as a separate Java process or separate add-on Java component.

There are three general types of applications for which Tomcat is highly suitable. These are:

  1. Any web application that has primarily been developed using Tomcat during development and is currently running on WebLogic in production.
  2. User interface (GUI), including sophisticated dynamic interfaces with features like user-specific content, forms validation, etc.
  3. Application components (including SOA services), particularly those requiring highly horizontal scaling and non-demanding business logic.

One recent example of a GUI motivated migration was the JSP for an order entry form in a highly successful e-commerce site, where the WebLogic server clusters were being seriously bogged down with accepting and validating customer-entered data. In this case, instead of doubling the number of WebLogic licenses, they split the Java EE application by removing the GUI JSP/servlets (the web application), adding a Web Services interface, and moving those functions to a Tomcat server farm. The WebLogic loading immediately fell by over 70%, and the cost of the Tomcat server farm, including load balancing and grid clustering, was less than 20% of what the additional WebLogic licenses would have cost. Furthermore, as the demand increases, adding additional Tomcat instances costs them under $2,000 each, instead of $35,000 to $40,000 for WebLogic server instances .

Evolutionary changes in application architectures have made lightweight Java containers an increasingly viable environment for today’s enterprise applications, particularly those using service oriented architectures based on Web Services standards. Increasingly, IT organizations are de-composing huge vertical legacy applications running on mega-servers into collections of more horizontal application components (Web Services, etc.) running on lightweight, low-cost servers. They are also encapsulating legacy systems in Web Services to enable a ‘building block” approach to future dynamic IT requirements. In both cases, migrating portions of the application from the WebLogic server to Tomcat provides operational efficiencies and improves IT agility.

Where architectural changes are the motivating driver, you must still take a close look at both the costs and the details of the migration process. In some cases, portions of the existing application code can be readily split off, but often new code has to be written to glue the results together. Targets of opportunity in a conversion would include portions of the code that have to horizontally scale but that do not require sophisticated services. User interface code is one typical area to focus on, plus application components doing large volumes of relatively simple things.

4. Confirming Migration Ability

The next step in assessing migration is to determine whether the functionality used by the application requires a WebLogic server or whether it can be supported by Tomcat, perhaps with a small number of add-on application services. Studies have shown that in most cases, only very small portions of the WebLogic functionality actually was used in any one Java EE application. While having everything you’d ever need at hand in every server instance was convenient, it was also complex and highly costly, both in acquisition cost and ongoing maintenance.

In some cases, the Java EE application from WebLogic will use one or more services not present in the Tomcat server. These may include data access/persistence, messaging, e-mail, etc. In these cases, the selected application services must be installed and configured, and typically the Java EE application code would be changed to use those specific third-party services.

4.1 Techniques for Determining Migration Suitability

With the differences between WebLogic and Tomcat in mind and suitable Java EE applications targeted for migration, we can turn to the migration process itself. There are several steps involved in the migration, starting with determining that the selected applications do not require services that will be missing in the Tomcat environment. 

You may use the following checklist to decide if your application can move from WebLogic to Tomcat:


Migrate to Tomcat?

Next Steps

Application has been developed using Tomcat as runtime during development


Determine configuration and deployment changes

Application primarily uses servlets and/or JSPs


Check if app leverages any WebLogic-specific services and identify their equivalent replacements for Tomcat

Application uses Spring Framework


Determine configuration and deployment changes

Application is written to be strictly standards-compliant


Determine if other Java EE technologies are used and identify equivalent replacements for Tomcat

Application is third-party software that is also available for Tomcat


Obtain the Tomcat version of the web application and deploy it on Tomcat

Application uses EJB or other WebLogic server functionality not readily available for Tomcat


Need code refactoring to remove the use of such functionality. This is a “new application,” not a migration.

An easy way to do a trial migration is to move the selected web application, perhaps stubbing out those previously noted sections, to Tomcat. This effort is primarily a configuration and deployment exercise and will be described in more detail below. At this stage, it is fairly rare for the web application to function fully, unless the original developers were meticulous in assuring portability. Typically, a short debugging session either will result in a basically running web application or will surface previously unknown reasons that the web application will not readily migrate.

Once the web application is basically running, it is extremely useful to be able to use the same test suites and tooling used to maintain the original WebLogic-based application. Although these are third-party tools, they are almost always Tomcat compatible and typically ship on Tomcat by default. Where WebLogic monitoring and debugging tools have been leveraged, there are no comparable capabilities included in Tomcat, so either third-party tooling or commercialized versions of Tomcat which include monitoring/debugging/administration functions must be used. This is typically the most frustrating and time-consuming part of the migration process, because WebLogic offers a rich suite, and the open source Tomcat does not include these features.

5. Migrate the Application to Tomcat

At its most basic level, migrating a “clean” servlet/JSP application from WebLogic to an installed instance of Tomcat is a matter of bringing over the WAR file from WebLogic, setting up server.xml configuration parameters using your favorite text editor (including changing the hostname in server.xml, if you want to use anything other than the default localhost), deploying the application by placing the WAR file into the appropriate hostname, and starting Tomcat.

Once the software is installed, we have successfully moved clean example code from WebLogic to Tomcat and had it running in a couple of hours. While this is possible in an IT environment, it is by no means the rule.

5.1. Web Application Deployment

Deployment is a significant area of difference between WebLogic and Tomcat. In WebLogic, Java EE applications are deployed through the administration console, and the scope of application management is a WebLogic cluster. Application configuration is managed by the WebLogic Administrative Server (which can also be an application runtime server) and is maintained in an embedded proprietary database. A cluster can be widely distributed, and WebLogic automatically distributes both the application and configuration across the cluster, verifying that each WebLogic server is up to date.

Note: Tomcat lacks even rudimentary administration, which means you must manually edit configuration files during installation. Commercialized versions of Tomcat add administration/management/monitoring capabilities to the basic Tomcat distribution, which adds significant value to Tomcat.

Tomcat offers three options for deploying a web application: 

  • WAR file: Manually moved into the local machine, manual or automatic local configuration
  • Unpacked web application directory: Manually moved into the local machine, manual or automatic local configuration
  • TCP connection to remote manager web app: Move either the WAR or the unpacked directory to the remote manager app.

With stock Tomcat, you'll need to choose one of these deployment methodologies for each web application you want to deploy.


6. Conclusion

There are several steps to consider when migrating a Java EE application from one application server to another, but migrating to Tomcat can bring your technology stack up to date while also offering significant licensing cost savings. At the same time, you can move to a popular open source application server that is well known and heavily used in the enterprise, and make your web application more standards-compliant to allow your developers to use their choice of industry standard developer tools.

Migrating to Tomcat from WebLogic will help your bottom line, improve developer productivity, enable your operations staff to keep your web applications performing well, and allow for easier incremental application server upgrades. End to end, your server-side environment will be significantly more agile and cost-effective.