Many companies moved their applications to the cloud by copying virtual machines and found that the bill went up while releases came no faster. The cloud changes cost and resilience only when the application changes how it runs. Cloud application modernization is that change, and it is decided application by application: some should move as they are, some should be rebuilt, and some should not move at all.
What is cloud application modernization?
Cloud application modernization is changing an existing application so that it uses what a cloud platform offers: instances that start and stop on demand, managed databases and queues, deployment from a pipeline, and monitoring built in. The application may already run in the cloud or still sit in a data center; what matters is how much of it changes.
Three terms get mixed up in proposals, and they describe different amounts of work:
- Cloud migration moves an application to cloud infrastructure. On its own, it changes where the application runs, not how.
- Cloud application modernization changes the application so the move pays: its state, its configuration, its dependencies on the server it used to run on.
- Cloud native describes the result. The Cloud Native Computing Foundation's definition says cloud native systems are "loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable."
Cloud native is now the default for new systems. In the CNCF's 2025 survey, 98% of organizations said they had adopted cloud native techniques and 82% of container users ran Kubernetes in production, up from 66% in 2023 (CNCF, January 2026). The question for an older system is how far toward that it should go, and in what order.
Legacy application migration options, from rehost to refactor
AWS describes seven migration strategies, the "7 Rs", which our enterprise cloud guide charts in full. Three of them decide how much a legacy application changes on the way:
| Strategy | What changes | Fits when |
|---|---|---|
| Retire | The application is switched off or archived | Nobody uses it, or another system already does the job |
| Retain | Nothing; it stays where it is | A move does not pay yet, or a dependency blocks it |
| Rehost (lift and shift) | Nothing in the application | A data center deadline, or an application that stays as it is |
| Relocate | The hypervisor layer moves to a cloud version of the same platform | Large VMware environments with a fixed exit date |
| Replatform | Runtime and services: containers, a managed database, configuration | Most business applications that will keep changing |
| Repurchase | The application is replaced by a product, usually SaaS | The application does a commodity job |
| Refactor or re-architect | The architecture, to use cloud native features | Parts with spiky load or a release pace the rest cannot match |
Two rules from the cloud providers' own guides are worth keeping in front of the team. Microsoft's Cloud Adoption Framework says rehosting is suitable only when the workload stays in its current state for at least two years; anything that will change sooner should change on the way. And AWS says refactoring is not recommended for large migrations, because it modernizes the application during the move. Both point to the same order: move most applications with a replatform, then refactor the parts that need it once they are running in the cloud.
Which applications should go first
The first application sets the pattern for the rest, so it should be one where the cloud makes a measurable difference and a failure does not stop the business. That rules out both ends of the portfolio: the core system everything depends on, and the internal tool nobody would notice moving.
| Signal | Points to |
|---|---|
| Load that varies a lot by hour, day or season | Move early: elastic capacity pays directly |
| Frequent releases slowed by manual deployment | Move early: a pipeline and containers shorten every release |
| Hardware or a data center contract that ends soon | Move on that date, rehosted if there is no time for more |
| Heavy, constant load on licensed software | Model the cost first; it may be cheaper where it is |
| Low latency needs to systems that stay on premises | Move with those systems, or keep it near them |
| No tests, unsupported framework versions | Fix that first: upgrade, then move |
The last row comes up more often than any other. An application on Java 8 and an unsupported Spring release needs an upgrade before it can use current container images, managed services and observability agents, and doing both at once makes every failure harder to trace. Our Java 21 vs 25 guide covers the version side; our IT modernization strategy guide covers the triage across a whole portfolio.
Cloud native application modernization: what changes inside a Java application
Most of the work of a replatform is moving things that lived on the server into managed services, so that any instance can be stopped at any time without losing anything.
Moving state out of the instance
An instance that the platform can stop holds nothing that matters. HTTP sessions go to a shared store such as Redis, uploaded files to object storage, and in-memory caches either become a shared cache or are accepted as per-instance and rebuilt on start. Scheduled jobs that ran from cron on the host need a scheduler that runs them once, not once per instance.
This is usually the largest change in code, and the one that decides whether the application can run as more than one instance.
Configuration and secrets from the environment
The Twelve-Factor App methodology, written at Heroku and open-sourced in 2024, still sums up the rules: configuration in the environment, backing services as attached resources, logs as event streams, processes that start fast and stop gracefully. A properties file with a database password inside the deployment artifact breaks most of them. In a Spring application, the move is mostly to environment variables and a secrets manager the platform injects at start.
Starting fast and stopping cleanly
A platform that scales out under load needs new instances ready in seconds, and one that scales in or redeploys needs running instances to finish their work before they stop. Spring Boot covers the second part: graceful shutdown is enabled by default with all three embedded web servers, and the Actuator exposes liveness and readiness probes at /actuator/health/liveness and /actuator/health/readiness for Kubernetes to use.
Startup has three options on the JVM, in rising order of effort. The ahead-of-time cache in Java 24 and 25 starts an application from classes loaded and linked in a training run; in the JEP's example, Spring PetClinic started 42% faster. CRaC restores a running JVM from a checkpoint. GraalVM Native Image compiles the application ahead of time and, in GraalVM's words, "starts in milliseconds", at the cost of a longer build and limits on reflection that older applications often hit.
Sizing the JVM for a container
The JVM detects a container's memory and CPU limits by default (UseContainerSupport is on), but by default it gives the heap only 25% of the container's memory (MaxRAMPercentage). A service moved from an 8 GB virtual machine, where someone once set -Xmx6g, into a 2 GB container with the flag removed, ends up with a 512 MB heap and garbage-collects its way to a timeout. Set the percentage on purpose and leave room for metaspace, threads and native memory:
JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=70 -XX:+ExitOnOutOfMemoryError"ExitOnOutOfMemoryError lets the platform replace an instance that ran out of memory instead of leaving it half alive. Java 25's compact object headers cut heap use further on most business systems, which can mean smaller containers for the same load.
Observability before the first cutover
On one server, an engineer could log in and read the log file. With instances that come and go, logs, metrics and traces have to leave the instance as they are produced. OpenTelemetry and Micrometer make this mostly configuration in a Spring Boot application, but dashboards and alerts that tell the team the new deployment is healthy have to exist before production traffic moves, or the first incident is investigated blind.
How to migrate a legacy application to the cloud in stages
A legacy application cloud migration that runs in stages can be stopped and reversed at each one, which a single cutover cannot. The order we use:
- Measure the application where it runs: load profile over a month, response times, resource use, and every system it talks to.
- Build the cost model for at least three years, for the target architecture rather than for today's servers rehosted.
- Upgrade what is out of support, Java and framework first, while the application is still on familiar infrastructure.
- Replatform: containers, configuration from the environment, state out of the instance, a pipeline, observability.
- Move the data with a method chosen from the downtime the business can accept; our data migration strategy guide covers the options from big bang to continuous replication.
- Switch traffic gradually, with the old deployment kept ready to take it back.
- Refactor the parts that need it, one at a time, with the strangler fig pattern once the rest runs in the cloud.
The payoff from step 4 alone can be large. AppDirect moved its marketplace and billing monoliths from Tomcat on EC2 hosts to Kubernetes; the time to deploy a new version fell from four hours to a few minutes, and the company went from between 1 and 30 deployments a week to 1,600 (CNCF case study).
When cloud native is the wrong target
A more distributed architecture is not always a cheaper or faster one.
Prime Video's audio and video monitoring service started as distributed components orchestrated by AWS Step Functions. It hit a hard scaling limit at around 5% of the expected load, and the per-transition charges and data passed between components made it expensive. The team moved all components into a single process on EC2 and ECS, and infrastructure cost fell by over 90% (Prime Video Tech, March 2023). The team's conclusion was that the choice between microservices, serverless and a monolith "has to be made on a case-by-case basis".
Some workloads should leave the cloud. 37signals cut its cloud bill from a $3.2 million a year run rate to $1.3 million by moving seven applications onto its own hardware (37signals, 2024); our enterprise cloud guide covers that case and when the same reasoning applies.
The common mistake is scaling a bottleneck instead of removing it. A UK hotel metasearch engine we worked on ran on a cluster of SQL Server machines where each additional machine raised cost by about 2% and throughput by about 0.1%. More instances, in the cloud or anywhere else, would not have helped. Moving availability search into an in-memory data grid did: the engine went on to serve 300 million queries a day at 80% lower infrastructure cost (case study).
Cloud costs after the move
Managing cloud spend was a top challenge for 85% of organizations in Flexera's 2026 State of the Cloud survey (Flexera sells cost management tools). The causes are rarely mysterious: instances sized for a peak that comes twice a year, environments nobody switches off at night, and storage that only grows.
For Java systems, part of the answer sits in the runtime. Heap settings that match the container, a current JDK with compact object headers, and startup fast enough to scale in aggressively all reduce the number and size of instances. In Azul's 2026 survey of Java professionals, 97% had taken actions to reduce public cloud costs (Azul, a vendor of Java runtimes).
Put the cost per business transaction on the same dashboard as latency and error rate from the first week. A cost that is reviewed once a quarter is a cost that has already been paid.
Choosing cloud application modernization services: questions to ask
If you bring in a partner, the answers to these questions say more than a capability deck:
- Will you measure our application before proposing a target architecture, and what will you measure?
- Can we see a cost model for three years, with the assumptions written down?
- Which of our applications would you not move, and why?
- How does the plan handle the data, and what is the way back at each cutover?
- Who writes the code: the people in this meeting, or a team we have not met?
- What do we receive at the end: code in our repository, runbooks and dashboards our team can operate?
Our cloud migration consulting starts with a thirty-minute scoping call. Within a week you get a written ballpark: which applications to move, in what order and with which strategy, with the cost assumptions written down.