Keeping enterprise Java applications up to date is critical for maintaining security and taking advantage of modern technology innovations. But updating applications to newer runtime or framework versions often requires developers to update the application code before it can compile or run on the new version. Busy developers need to prioritize work that adds value to an application, such as building new capabilities. Spending time making code updates just to make the application work the way it did before a framework upgrade does not provide business value.
For example, bug fixes and new features are generally released in the next version of the runtime or framework on which the application runs, so the runtime or framework needs to be updated to that new version. The next version might, however, be a major release, such as moving from Spring Framework 5.3 to Spring Framework 6. The move to a new major version of the runtime or framework can then require other changes, such as needing to upgrade Java SE to Java 17, and to upgrade Java EE to Jakarta EE 9. Those additional upgrades can have further impacts on the application, including, among other changes, needing to upgrade Java EE javax specification namespaces to the Jakarta EE jakarta namespaces.
The temptation is, therefore, to avoid upgrading the application runtime or framework for as long as possible. Unfortunately, this is just accumulating technical debt for the business and increasing risk to potential security exposures. The number of attacks and the time between vulnerability disclosure and active exploitation is shrinking. IBM’s 2025 study estimates that the global average cost of a data breach is now as high as $4.4M. Additionally, data breaches can also result in potential fines due to compliance violations (security negligence due to unpatched known vulnerabilities). So, it is even more critical to stay up-to-date and current, especially with security fixes.
But what if upgrading to new runtime or framework versions didn’t have to be so difficult and risky? What if developers could upgrade the runtime or framework that an application uses without touching the application code itself? Applications could remain secure and reliable with security fixes, without having to re-write the apps. The principle of “zero migration” enables this.
What is zero migration?
Zero migration is a design principle that guides teams to release new runtime or framework versions, importantly, without breaking existing applications. When teams follow the zero migration design principle, they can add security fixes and new capabilities to the runtime or framework, and existing applications running on these runtimes or frameworks can continue running as before without needing any code or configuration changes. The Liberty application runtime for Java applications has followed this design principle since it launched in 2012.
Zero migration and modularity
Zero migration makes use of the modularity built into modern application runtimes and frameworks such as Liberty (https://ibm.biz/JavaProOpenLiberty). Modularity partitions a system into smaller, independent building blocks (modules) that communicate through defined interfaces. These partitions have meaning: in Liberty, they appear as separate “features.” Other runtimes and frameworks also use modularity (e.g. Quarkus uses “extensions,” and Spring Boot uses “dependencies”) but modularity alone does not provide zero migration. Liberty uses modularity to enforce the zero migration design principle because it allows applications to access multiple versions of features, regardless of the runtime version.
How zero migration works in practice on Liberty
A Liberty feature is a representation of a specific Liberty capability. For example, the Jakarta Persistence API (JPA) feature provides persistence, and the Request Timing feature provides diagnostic information. Each Liberty feature has two components: the feature name and the feature version. Developers specify both the feature and the version in their application configuration files, such as server.xml. Liberty does not tie feature versions to the Liberty runtime version. This separation lets teams upgrade Liberty without being forced to upgrade the features their applications use.
If a breaking change does need to be introduced into a feature, the feature version is incremented but Liberty continues to support all previous versions of the feature, as well as the new version. Ultimately, this gives developers control over if and when they want their application to make use of a newer version of a feature. This gives teams assurance that these new feature versions will not change the APIs used by their application or the behavior of their application.
For example, if an application that runs on Liberty requires version 3.0 of the Jakarta RESTful Web Services API, the application’s configuration file would contain the entry:
<feature>restfulWS-3.0</feature>
Because Liberty follows the zero migration design principle, the application can continue using version 3.0 of the restfulWS feature even after Liberty releases version 3.1. It will continue to work this way no matter how many future versions are released.
Zero migration makes it easier and cheaper to ensure the Liberty runtime remains current with security fixes and new capabilities. It not only reduces technical debt, but also reduces the overhead of maintaining a runtime and in many cases eliminates this overhead entirely. This freedom allows development teams to focus on higher‑value work in both development and operations.
It’s worth noting that there is one caveat to zero migration: very occasionally, security fixes necessitate a change in behavior. In such cases, the scope of the change is limited as much as possible, and users are provided with a way to revert the behavior whenever possible.
What if I don’t have zero migration available?
Many development teams run applications on servers and frameworks that do not support zero‑migration design. This leaves these teams with few options to stay up to date.
In these cases, developers often have no choice but to re‑design their applications. They might need to remove deprecated APIs or adopt alternatives with different behaviors. They might also need to rework unsupported integrations or even migrate to entirely new application servers and frameworks. While this process can reduce technical debt, it demands significant time, effort, and expertise. It also delivers little innovation beyond necessary security updates. It is a lot of work simply to maintain the status quo.
So yes, you can re‑write your application. But is that effort worth it when zero migration lets you stay current without handling breaking changes?
The real value lies in having the freedom to choose when to adopt behavioral changes to your applications, APIs, libraries, and tools. Minimizing technical debt is only part of the story. The greater goal is enabling application development teams to focus on strategic innovation, while staying secure, efficient, and reliable on the latest runtime version—with as little friction as possible.
Enhancing zero migration with continuous delivery
Continuous delivery further enhances the concept of zero migration. It is a software engineering approach where teams produce software in short cycles. Continuous delivery enables frequent, incremental releases, allowing developers to stay up to date on a regular schedule. This approach removes the long waits for bug fixes or new features that often occurred with waterfall‑style delivery practices.
In the case of Liberty’s continuous delivery policy, a new version of Liberty is released every four weeks. Since 2019 (starting with 19.0.0.1), there have been approximately 12 releases each year. To get the latest updates, including security, performance, and bug fixes, developers simply need to update to the latest version of Liberty, while zero migration means that these applications will continue to run as before. Developers can upgrade from any Liberty version to any newer Liberty version, skipping any releases they’ve missed. It also offers developers and operators predictability and options to pick an upgrade schedule that works best for them.
Coupling continuous delivery with zero migration enables developers to implement a continuous integration environment for their applications. By continuously upgrading, the process becomes very routine, less intrusive, and easier to digest. Additionally, the official Liberty container images are updated with new versions of Liberty on the same cadence and are also updated weekly with the latest operating system and Java fixes. This all means that the developer doesn’t have to worry about anything other than their application.
The benefits of zero migration in action
To show how this works in real life, we can start with an older enterprise sample Java application (PlantsByWebSphere) and show that we can easily upgrade the version of Liberty that this application runs on without having to make any code or configuration changes.
PlantsByWebSphere is a comprehensive Java EE sample application. It simulates an online store that sells plants, allowing users to browse items, place orders, and manage inventory. The main application code has not changed in seven years and uses Java EE 7 technologies.
If you want to try this yourself, clone the application from its GitHub repository: https://ibm.biz/JavaProPlantsByWebSphere. Then follow along with the steps provided in the IBM Developer article: https://ibm.biz/JavaProZeroMigrationExample.
When you build the PlantsByWebSphere application with Java 8, it runs on Open Liberty 18.0.0.2 from June 2018. With a simple build file update, you can run the same application on Open Liberty 25.0.0.12 from December 2025. The application behaves the same on 25.0.0.12 as on 18.0.0.2 with no underlying changes to the application’s code or behavior. This is a jump of more than 80 Open Liberty releases! This scenario shows the practical benefits of zero‑migration architecture.
To highlight the significant work saved through zero‑migration architecture, let’s examine what could have happened to the PlantsByWebSphere application without it. The application runs on Java EE 7, which uses the javax namespace. If a Liberty upgrade had required Jakarta EE 9, developers would need to update all javax namespaces to jakarta. This change would have required significant time to locate every affected area and apply the necessary updates. That is a substantial amount of work just to keep the application running on a secure runtime. Fortunately, Liberty’s zero‑migration support prevents this scenario. This is just one example showing how zero migration can dramatically reduce cost and development effort. It allows teams to focus on meaningful work and adopt changes only when they are ready.
Summary
Traditional runtime and framework updates often force developers to modify application code. These updates may require namespace changes, replacements for deprecated APIs, and a lot of testing. All of this effort is required just to maintain existing functionality.
The zero‑migration design principle changes this dynamic. Zero migration ensures that new runtime or framework versions preserve compatibility with existing applications. It allows developers to upgrade the underlying platform without changing application code or configuration. Liberty has followed this principle since its inception. Zero migration lets applications keep running unchanged as new runtime versions are released. This approach reduces technical debt, removes much of the risk typically associated with upgrades, and makes staying current both easier and cheaper for development teams.
Zero migration becomes even more powerful when combined with continuous delivery, which provides a predictable, frequent release cadence. Liberty delivers a new version every four weeks, giving teams regular access to security, performance, and reliability improvements. Because applications keep running as before, even after multiple version releases, teams can upgrade to the latest version whenever they choose. These upgrades occur with minimal friction and require no rewrites.
The PlantsByWebSphere example demonstrates this in practice: an unmodified Java EE 7 application running on an older runtime version can move through more than 80 Liberty releases without changing a single line of code. Without zero migration, such an upgrade would require major namespace changes from javax to jakarta. These changes would multiply effort and cost with no real functional gain.
Together, zero migration and continuous delivery remove anxiety from runtime upgrades. They keep applications secure and modern, while freeing developers to focus on innovation instead of maintenance.
Give it a go yourself
If you want to see the benefits of zero migration, visit the demo app’s GitHub repository: https://ibm.biz/JavaProPlantsByWebSphere. Then follow along with the steps provided in the IBM Developer article: https://ibm.biz/JavaProZeroMigrationExample. These resources enable you to experience first-hand how zero migration makes staying current easy.
Alternatively, if you’re interested in learning more about Liberty as a cloud‑native Java runtime, try the Getting Started guide: https://ibm.biz/JavaProGettingStartedGuide. You can also try the Liberty starter project, which provides a simple Liberty application in just a few minutes: https://ibm.biz/JavaProGettingStartedProject. You can also check out the JavaPro article on Open Liberty
This article is part of the JAVAPRO special magazine issue:
Java in the Age of AI
Explore how AI is transforming the way we build, secure, and operate software with Java.
From AI agents and new architectural patterns to security, data, and team dynamics—this edition brings together real-world insights for building intelligent, production-ready systems.
Discover the edition →
