That is useful news for Windows-based enterprise Java teams, but the most important detail is not the headline application count. MMNA’s portfolio remains on Windows Server 2016, Java 8 and traditional WebSphere Network Deployment, with dependencies spanning IBM MQ, Db2, mainframe systems, IBM i/AS400 workloads and IBM Operational Decision Manager. A runtime migration in that environment is a dependency-management exercise, not a simple server replacement.
IBM has provided the only public account of the MMNA project, and no independent outlet has reported the application count, the “hours” required for the assessment, or whether any Liberty production cohorts have already gone live. The case study should therefore be read as an IBM-reported migration plan rather than a completed transformation. Still, its technical details expose a more grounded lesson: automated portfolio analysis can sharply reduce the number of applications treated as migration emergencies, while making the genuinely difficult services impossible to ignore.
The immediate deadline is Windows Server 2016, not WebSphere alone
MMNA’s starting platform matters to Windows administrators because Windows Server 2016 reaches the end of extended support on January 13, 2027. That is a fixed operating-system deadline, and it gives the organization less than five months from the date of IBM’s post to establish how those workloads will be hosted, patched and secured afterward.
IBM frames the work partly as a supportability and security modernization effort, but the product records add an important qualification. IBM’s current support information says WebSphere Application Server 9.0.5 has no planned end-of-support date, while IBM has extended Liberty support for Java 8 applications through December 2030. In other words, Java 8 and WebSphere 9.0.5 are not automatically unusable on IBM support grounds alone.
That does not make standing still a sensible answer. Java 8 limits access to newer application frameworks and development patterns, and Windows Server 2016’s lifecycle is a concrete infrastructure exposure. But it changes the decision MMNA faces. The organization is not being forced to choose between a risky all-at-once rewrite and unsupported middleware. It can separate three decisions that are often bundled together: replacing the aging Windows host operating system, moving applications to Liberty, and moving selected codebases from Java 8 to Java 17.
That separation is the strongest part of IBM’s described approach. A team that has one migration deadline should resist inventing three more.
Ninety low-change applications are a sequencing signal, not a deployment result
IBM says AMA examined 110 business applications and 60 web services, identifying about 90 of the business applications as candidates for minimal or no code change. The figure should not be mistaken for 90 applications that can be cut over with no operational work.
Compatibility analysis can identify API usage, shared libraries, packaging, configuration and source-level migration issues. It cannot by itself certify end-to-end behavior through dealer systems, downstream queues, database connections, legacy mainframe transactions, external partner calls or production authorization paths. In MMNA’s case, those surrounding interfaces are exactly where the cost of a seemingly uncomplicated runtime move can appear.
The sensible interpretation is more modest and more valuable: IBM’s assessment gives MMNA a defensible first migration cohort. Those applications can be used to establish a repeatable Liberty deployment template, configuration convention, performance baseline, rollback procedure and test evidence before the more complex services move.
For administrators, the first cohort should be chosen for more than low code-change scores. A good initial wave includes applications with clear owners, available regression tests, manageable transaction volume, known dependency maps and a rollback path that does not depend on manually reconstructing WebSphere configuration. A technically compatible application that has no business owner or no realistic test data is not a low-risk pilot.
The point is to create a production method, not simply improve a portfolio dashboard. If every cohort requires a new deployment recipe, different certificate handling, a new connection-pool model or separate monitoring work, the organization has not achieved low-disruption modernization—it has merely spread the disruption across multiple release windows.
SOAP and JAX-RPC are the real migration boundary
The hardest work in the MMNA account sits in the web-service layer. IBM says approximately 95% of the services already use REST, while the remaining SOAP endpoints include older Java technologies such as JAX-RPC and JAXB. Those are not interchangeable findings.
JAXB itself is not necessarily a migration blocker. Liberty continues to offer JAXB capabilities, including support for applications running on Java 17. The question is whether an application relies on old package names, application-bundled libraries, server-provided APIs or generated classes that need adjustment when the Java and enterprise API levels change.
JAX-RPC is different. IBM’s Liberty documentation is explicit that JAX-RPC applications need migration work because Liberty does not support JAX-RPC directly. IBM’s recommended path is to move those services to JAX-WS, using a migration helper that identifies WSDL files and can automate portions of the update. IBM also advises completing JAX-RPC modernization before other modernization changes because later Java enterprise stacks may no longer include the APIs needed to analyze and convert the old implementation.
That makes the post’s “about 95% REST” detail more significant than it first appears. The remaining share may be numerically small, but SOAP services often sit at business boundaries: dealer integrations, identity systems, financial processing, older partner contracts or long-lived internal workflows. A few endpoints can carry disproportionate migration risk.
MMNA should not treat “convert SOAP to REST” as a routine compatibility fix. A REST replacement may be a strategic option, but it can alter client contracts, authentication behavior, error handling, payload formats, monitoring assumptions and partner certification requirements. Where existing SOAP contracts remain necessary, moving JAX-RPC to JAX-WS while retaining the WSDL and endpoint behavior is the more conservative runtime-modernization step. REST conversion belongs in a separately governed interface-modernization backlog.
Observability provides the missing before-and-after evidence
IBM says MMNA installed Instana agents across WebSphere nodes, including the deployment manager and custom nodes, then added Java instrumentation to trace transactions through JVMs. That is more than a supplementary product sale in this particular project: a runtime migration without usable pre-move telemetry produces arguments instead of evidence when performance changes.
IBM’s Instana documentation confirms that its Java sensor can collect JVM health data and automatic distributed traces, while WebSphere monitoring includes JMS-related tracing data. For an estate that uses IBM MQ, database connections and a mix of synchronous and asynchronous services, this can expose whether a migration regression begins in the application server, a connection pool, a database call or the messaging chain.
But there is an operational caveat administrators should not skip. Instana warns against using application-performance agents from multiple vendors in the same JVM because conflicting instrumentation can result in unpredictable behavior and potentially application failures. Teams should inventory existing Java agents, security instrumentation and bytecode-modifying tooling before attaching another monitoring layer across every production node.
The baseline also has to be deliberate. Response-time comparisons are meaningless if they are taken during different dealership traffic periods, month-end processing cycles or batch windows. For each migration cohort, MMNA needs a defined pre-cutover observation period and a small set of release gates: error rate, latency by transaction class, JVM heap and garbage collection behavior, database-call duration, MQ queue depth where relevant, and business-level completion rates.
That turns observability into a control mechanism. Without that discipline, it becomes an expensive way to discover after a cutover that an application is slower.
Liberty can be introduced without forcing containers
IBM’s post correctly distinguishes Liberty adoption from container adoption. Liberty can run on virtual machines as well as containers, which gives MMNA a way to replace the application runtime and move to a newer Java release without immediately redesigning deployment and operations around Kubernetes or another orchestration platform.
For a small development team, that sequencing is practical. Containers add image construction, registry management, vulnerability scanning, runtime policy, orchestration, storage, networking, secret management and incident-response changes. Those can be worthwhile, but combining them with Java upgrades, legacy-service remediation and a Windows Server retirement project would multiply the variables in every failed test.
IBM also documents a bridge that deserves attention in organizations with entrenched Network Deployment administration: Modernized Runtime Extension for Java lets Network Deployment 9.0.5 administrators manage Liberty workloads through familiar Network Deployment interfaces while those workloads run on Java 17 or Java 21. MMNA’s post does not say it will use that option, and it should not be assumed. But it illustrates that a Liberty transition need not discard established operational controls on day one.
The project’s real value is therefore not that IBM found 90 easy applications. It is that MMNA can use those applications to prove a migration factory: assess, select a cohort, establish a measured baseline, migrate, validate business and integration behavior, then reuse the result.
By January 13, 2027, MMNA will need a supported answer for the Windows Server 2016 foundation beneath these workloads. IBM’s assessment gives it a path to avoid treating all 170 applications as equally urgent—but the JAX-RPC services, production integration testing and host-platform deadline will determine whether that path remains low-disruption in practice.