What's the deal with IBM WebSphere Application Server?

Note:

• If your host OS will be a container, you do all of this as part of “building” the “container image” before publishing it as a “version” of that container image into a “container registry.” You’ll always be just spinning down containers running your old container image, and spinning up containers running your new container image, no matter whether you’re:
  • Just spinning up a new workload for the first time, or:
  • Releasing new fixes / features / configuration settings.
• If your host OS will be a VM, you do all of this as part of either:
  • Spinning up the VM for the first time, or:
  • Each time you releasing a fix / feature for your application or the VM’s configuration settings.

Install a Java runtime

You probably want to use some sort of infrastructure as code tool to automate getting a Java runtime (JVM) installed onto the VM/container.

Install IBM Installation Manager

Apparently, WAS is typically installed onto machines using IBM Installation Manager, so you probably need to install that onto the VM/container first.

You probably want to use some sort of infrastructure as code tool to automate downloading, unpacking, and running this installer.

Install IBM WAS

Using IBM Installation Manager, install WAS onto the VM/container.

You probably want to use some sort of infrastructure as code tool to automate downloading, unpacking, and running this installer.

Expose shared files

You’ve probably got your WAS license file on some sort of shared network drive, so you’ll want to mount that drive into the VM/container’s filesystem and make sure that WAS has appropriate read access to the license file. Otherwise, WAS might refuse to start up, on account of believing it’s an unlicensed copy.

Similarly, if you’re using WAS to control a whole cluster of VM/container servers, there will probably be some shared files that you’ll store on a shared network drive (e.g. your *.war files). So you’ll also want to mount that drive and grant appropriate access to its files and folders.

You’ll also probably need to create some “service users” in your VM/container’s OS, configure some “system services” of that OS, modify some “system files” in that OS, and set some “environment variables” in that OS.

You probably want to use some sort of infrastructure as code tool to automate these VM/container user configuration, filesystem configuration, and access control steps.

Container skills

Your team doesn’t have the skill to securely and reliably manage container-based servers.

OS kernel isolation

Nitpicky security or compliance rules at your organization mean you’re not allowed to let different containers share the same host OS kernel and need better resource isolation than containers offer.

OS miscellany

You’ve got a really quirky way you’re using WAS that requires host OS configurations that just can’t be done easily in containers, but can be done easily in VMs.

Or you’ve got a really quirky way you’re using WAS that absolutely positively requires making ad-hoc OS-level modifications, rather than modifying the settings by simply replacing containers configured the old way with containers configured the new way. (Perhaps even with load balancing and a “blue-green deployment” pattern to avoid the application running on WAS experiencing any downtime.)

Distributed computing orchestration

You’ve got a way of using WAS in a distributed fashion that would make it extremely toilsome to change over from traditional WebSphere Network Deployment (“ND”) clustering/orchestration to a container-native distributed computing orchestration architecture.

Legacy code and WebSphere expertise

It’d be too darned much toil to refactor it.

Licensing

Apparently a WebSphere license comes with a license to run the Java Enterprise Edition (“Java EE”) and support from IBM for it?

Similarly, if your compliance rules force you to have certain kinds of commercial support, long-term maintenance, or certifications that only IBM can provide, that might be a great reason to develop on WAS.

Distributed computing orchestration

Being even older than Kubernetes, WAS already thought a long time ago about clustering, failover, scalability features, etc., and does it “batteries included.”

You might not want to have to reinvent the wheel and learn load balancing, container orchestration, etc. when WAS can just … do all of that for you.

(On the other hand, it’s 2025, so you might not need to learn container orchestration if your workload is safe to run in the cloud. There’s probably a cloud-provided PaaS that will take care of that for you. In theory, all you’d need to do would be to build your container image and publish it into a container registry – the cloud PaaS should be able to take it from there.)

IBM integrations

If you’ve got an IBM mainframe, or IBM DB2 databases, there’s a lot of IBM-authored middleware (e.g. connection pooling and advanced JDBC features) that WAS integrates with nicely right out of the box.

For applications that need to integrate with such products, Websphere’s probably gonna be way more fun to configure and write Java code for than, say, Tomcat.

Moving a legacy Java app (not tied to IBM products) to Azure App Service or containers on Azure PaaS involves several layers of work—some technical, some organizational. While Java WAR files are technically portable, most legacy apps make assumptions about their runtime environment that require code and configuration changes for a successful migration. Here’s what’s typically involved:

1. Assessment and Planning

• Inventory and Analyze Dependencies: Identify all external dependencies, integrations, and OS-level assumptions (e.g., file paths, environment variables, local storage, custom scripts)¹²³⁴.
• Choose Migration Path: Decide between “lift-and-shift,” partial refactoring, or full re-architecture. For Azure App Service or containers, you’re usually looking at refactoring or re-platforming, not a pure lift-and-shift²³⁵⁴.

2. Code and Configuration Refactoring

• Externalize Configuration: Legacy apps often use hardcoded file paths or expect config files on local disk. Move these to environment variables or Azure App Service/Container configuration settings²³⁵.
• File I/O Adjustments: Azure App Service and containers have ephemeral local storage. If your app writes files locally (logs, temp files, uploads), you’ll need to redirect these to Azure Blob Storage or another persistent service.
• Session Management: If your app stores session state on the local filesystem or in-memory, switch to a distributed cache (e.g., Azure Cache for Redis) to support scaling and failover.
• Database Connectivity: Update JDBC URLs and drivers to connect to managed Azure databases (e.g., Azure SQL, Azure Database for PostgreSQL/MySQL, or Azure-managed DB2 if available).
• Security and Secrets: Move sensitive data (passwords, API keys) to Azure Key Vault or App Service secrets management.

3. Runtime and Platform Assumptions

• OS-Level Access: Remove or refactor any code that expects direct OS access (e.g., shell scripts, native binaries, cron jobs). Azure App Service restricts OS access; containers offer more flexibility, but you still need to package everything needed inside the image²³⁶.
• Startup Scripts: App Service and containers have specific entry points. You may need to adapt your app’s startup scripts or use a custom Dockerfile for containers.

4. Packaging and Deployment

• WAR to JAR or Docker: For Azure App Service, you can deploy a WAR file directly. For containers, you’ll need a Dockerfile that builds an image with your app and its dependencies⁷⁶.
• CI/CD Integration: Set up automated builds and deployments using Azure DevOps, GitHub Actions, or another pipeline tool.

5. Testing and Optimization

• Cloud Readiness Testing: Use Azure’s testing tools (Azure Monitor, Application Insights) to validate that the app works as expected in the new environment ²³.
• Performance Tuning: Adjust scaling, memory, and CPU settings for App Service or container instances. Monitor and tune for cloud-specific performance issues.

6. Operational Changes

• Logging and Monitoring: Integrate with Azure Monitor, Log Analytics, and Application Insights for centralized logging and alerting.
• Backup and Disaster Recovery: Implement Azure-native backup and DR solutions.
• Scaling and Orchestration: For App Service, scaling is mostly automatic. For containers, configure scaling rules and health checks in Azure Kubernetes Service (AKS) or Azure Container Apps⁷⁶.

7. Team Training and Process Updates

• Cloud Skills: Upskill your team on Azure services, PaaS/container management, and cloud security best practices¹.

Key Takeaways

• Yes, you’ll almost always need to refactor code—especially for configuration, file storage, and OS-level assumptions.
• Session state, file I/O, and external dependencies are the most common pain points.
• Azure App Service is best for traditional web apps with minimal OS dependencies; containers (AKS, Azure Container Apps) are better for apps needing more control or with complex dependencies⁷⁶.
• Testing and optimization in the cloud are crucial before going live¹²³.

Migrating to Azure PaaS or containers is very achievable, but expect to invest in refactoring and modernization to fully leverage orchestration, scalability, and managed services.

Here are some architectural mini-refactors you can make now—while improving infrastructure configuration and CI/CD for your legacy WebSphere apps—that will make any future move to Azure App Service or Azure container PaaS much smoother, even if you’re not planning a full migration yet:

1. Externalize Configuration

• Move all environment-specific settings (URLs, credentials, feature flags) out of static files and into environment variables or external configuration sources.
• Avoid hardcoding file paths, hostnames, or credentials in code or bundled config files.
• Prepare to use Azure App Service’s Application Settings or container environment variables for config injection later⁸.

2. Centralize and Externalize Secrets

• Store sensitive data (passwords, API keys) outside of your WARs and property files.
• Use a secrets management tool now (even if not Azure Key Vault yet) so you can swap in Azure Key Vault references easily in the future⁸.

3. Reduce Server-Level Dependencies

• If your app relies on server-level classpath libraries, shared JNDI resources, or global data sources, start moving these into your application package or externalizing them.
• Aim for a model where each WAR is self-contained, reducing reliance on shared server resources⁸.

4. Abstract File Storage

• Refactor any code that reads/writes to local disk (uploads, logs, temp files) to use a storage abstraction.
• Prepare to redirect file storage to Azure Blob Storage or another cloud storage service in the future, since local disk is ephemeral in PaaS/container environments.

5. Session Management

• If your app stores session state in memory or on local disk, consider moving to a distributed session store (like Redis) or at least abstract session management so you can switch easily later⁹.

6. Modularize Scheduled Jobs

• Separate scheduled/batch jobs from the main application logic. Move them into standalone modules or services.
• This will make it easier to migrate them to Azure Functions, Logic Apps, or separate containers later⁸.

7. Standardize Logging

• Use a logging framework that supports external sinks (e.g., Log4j, SLF4J with appenders for cloud logging).
• Avoid writing logs to local disk only; prepare to send logs to Azure Monitor or another centralized logging service¹⁰.

8. Database Connectivity

• Parameterize JDBC URLs, credentials, and connection pool settings.
• Prepare for cloud-managed databases by not assuming static IPs or local hostnames; use DNS and credentials that can be swapped for Azure SQL or other managed services⁹.

9. Container-Ready Practices

• Avoid OS-specific dependencies, custom shell scripts, or hardcoded assumptions about the runtime environment.
• Use standard Java startup scripts and document any required OS packages or environment setup in a way that would translate easily to a Dockerfile⁸.

Why These Steps Help

• They reduce coupling to the WebSphere runtime and on-premises infrastructure, making your app more portable.
• They align with best practices for cloud migration and containerization, minimizing future rework.
• They are often quick wins when you’re already modernizing deployment and configuration management.

Summary:

Focus on externalizing config and secrets, reducing server-level dependencies, abstracting file/session storage, modularizing jobs, and standardizing logging and DB connectivity. These mini-refactors are low-hanging fruit during CI/CD and infra improvements, and will significantly ease any future move to Azure App Service or container-based PaaS—even if you’re not planning that move yet⁸⁹¹⁰.