Kubernetes replatforming
Replatform Java to Kubernetes without rewriting it.
Most applications can move with targeted changes. The work is in state, configuration and operations, not in the business logic.
The short answer
Replatforming to Kubernetes means running an existing application in containers on a cluster with limited code change. For Java this usually means moving off an application server, externalizing configuration and state, adding health checks and building a container image. Ace8 does the code work in slices and checks each step with tests.
Definition
What is replatforming, and how is it different from rehosting or refactoring?
Replatforming sits in the middle. It gets most of the operational benefit of Kubernetes at much lower risk than a refactor. If you do want to split a system, see monolith to microservices.
| Approach | What changes | Typical use |
|---|---|---|
| Rehost | Nothing in the code. The VM moves. | Quick exit from a data center |
| Replatform | Runtime, packaging and configuration. Little business code. | Move to containers and Kubernetes |
| Refactor | Application structure, such as splitting services. | When the design blocks change |
Readiness
What stops a Java application running on Kubernetes?
Most of these are found by static analysis plus a read-through by an engineer. Tools such as Konveyor can list them across a portfolio.
- Application server dependence: JNDI lookups, server-managed data sources and server-specific deployment descriptors.
- Local state: sessions held in memory, files written to local disk, scheduled jobs that assume one instance.
- Hard-coded configuration: host names, file paths and credentials in the code or the build.
- Old Java versions with poor container awareness of CPU and memory limits.
- No health endpoints, so the cluster cannot tell a stuck process from a healthy one.
- Long start-up and shutdown behavior that conflicts with rolling updates.
Method
How do we replatform an application?
- 1
Assess
Score each application for readiness. Some are easy, some need an upgrade first, a few should stay where they are.
- 2
Upgrade the runtime
Move to a current Java version and, where it helps, off the application server. See Java modernization.
- 3
Externalize state and config
Move sessions, files and settings out of the application so many copies can run.
- 4
Containerize
Build a small, reproducible image with health checks. See application containerization.
- 5
Deploy alongside the old system
Run both, compare behavior, then move traffic gradually with a rollback ready.
Judgment
Which applications should not move to Kubernetes?
A good assessment says which ones to leave. Moving everything is not the goal.
- Stable, low-change applications with no pressing reason to move, where the cost exceeds the benefit.
- Applications tied to hardware or to a vendor product that is not supported in containers.
- Heavy stateful systems with no clear operating model for persistent storage.
- Applications near retirement.
Run
Who runs the cluster afterwards?
A platform change moves operational work to whoever owns the cluster: upgrades, security patches, capacity, monitoring. Decide this before cutover. Ace8 does the migration. AceMQ supports the open-source stack afterwards, including the container and messaging components. See supported after migration. We are not a managed Kubernetes provider, and we say so up front.
Evidence
What have we measured?
We have not published figures on container start-up, memory use or cutover effort for a sample application yet. When we do, they will be labeled with the application, the Java version and the cluster used. Until then this page claims none.
Running an existing application in containers on Kubernetes with limited code change, mainly to packaging, configuration and state. It differs from a rewrite or a service split.
Often yes, after removing application server dependence, externalizing state and configuration, and adding health checks. Some applications need a Java upgrade first.
Not always, as some servers can run in containers, but exiting the server usually simplifies the move and removes licence cost. The assessment decides per application.
No. Stable, low-change or hardware-bound applications may be better left where they are.
No. We do the migration. AceMQ supports the open-source components afterwards, and you decide who owns the cluster.
Know the cost before anything moves.
A fixed-price assessment gives you the inventory, the risk score and a phased plan. Scope and cost are fixed before the migration starts.
Book a Fixed-Price AssessmentGet in touch
Talk to a modernization engineer
Tell us what you run today. An engineer, not a sales script, replies within one business day.