Where should application modernization start? Map the transition before the rewrite

Age alone does not justify changing a system. If its functions are stable, demand for change is low, and operating cost is predictable, leaving it alone may be the better decision. A newer stack can still be a modernization candidate when small changes take weeks, every deployment shakes the whole service, and incidents cannot be traced.

Legacy describes a condition, not a birthday: the cost of change is constraining the business. That makes Kubernetes or microservices the wrong starting point. The first task is to rediscover what moves together whenever the system changes.

Modernization starts by choosing the unit of change

Cloud migration, modernization, and a full rewrite can overlap, but they are not synonyms.

Microsoft places replatform, refactor, and rearchitect on a continuum of complexity and value, and recommends mixing them by component.¹ Forcing one strategy across a program rebuilds code that already works or hides a structural bottleneck behind a platform move.

Assessment goes beyond a source-code inventory

A repository and server list will miss many of the connections that make change risky. Data ownership, batch jobs, external institutions, identity policy, manual deployment, and human approval paths often hold the real dependencies.

AWS assesses modernization readiness through five lenses: strategic or business fit, functional adequacy, technical adequacy, financial fit, and digital readiness.² Translated into operational questions, they look like this.

When documentation is gone, the running system becomes the source. Trace traffic, logs, delivery configuration, database schemas, and batch schedules to reconstruct real dependencies. Designing the target first merely postpones discovery until the transition is already under way.

One treatment does not fit every component

AWS portfolio guidance classifies applications with the 7 Rs, then combines that choice with dependencies and technical complexity to form migration waves.³ The same discipline helps a modernization program record the reason for each decision before technology fashion takes over.

A decision record needs more than the choice. Record why it is right now and what would trigger another review. Retain does not mean retain forever, and rehost does not mean modernization is complete.

The transitional architecture matters as much as the target

Architecture packs often show two diagrams: current and target. Delivery needs the pages between them. Design for the period when old and new modules both receive requests, the source of truth still lives in the legacy store, and a new API translates an older integration contract.

A transitional architecture should define at least four things.

1. The point that routes each request to the old or new path
2. The source of truth and the direction of replication and reconciliation
3. The compatibility layer between old and new interfaces
4. The last safe point from which the change can be reversed

The target explains direction; the transitional state keeps the service alive. Give each intermediate state an exit condition and a maximum lifetime, or temporary duplication becomes the next legacy system.

Cut waves by value, dependency, and recoverability

“Start with low risk” is incomplete. Moving only an easy internal tool does not test assumptions around the core system. The first wave should matter to the business while keeping the blast radius controllable. Microsoft likewise recommends small modernization phases with success criteria and rollback procedures for each phase.¹

Each wave is a hypothesis test, not a calendar milestone. “The new service is running” is weaker than “it produces equivalent outcomes and can recover within the agreed time when it fails.”

Data cutover is not the last task

Two code versions can run side by side. Data still needs one truth at each point in the transition. Data strategy must therefore begin with boundary design, not near the end of the program.

Read replicas, change data capture, dual writes, and batch migration fail in different ways. Dual writes, in particular, create inconsistency when one store succeeds and the other fails unless the recovery rule is explicit. Decide these points first.

• Which store is authoritative in each phase
• How missing, duplicate, and out-of-order changes are reconciled
• Whether schema changes remain safe for both application versions
• How far new writes can be reversed during rollback
• Who approves retention and deletion of personal or audited data

Do not assume replication lag is zero. Measure it and define an acceptable range. A cutover plan needs reconciliation queries, owners, stop conditions, and post-recovery checks alongside the traffic switch.

Measure changed delivery, not a newer stack

Container count and microservice count are not modernization outcomes. Establish a baseline for the current change flow, then compare the same application before and after each wave.

DORA now describes software delivery performance with five measures: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate.⁴ Add service-level objectives, infrastructure and licence costs, manual approval steps, and incident blast radius to see whether modernization changed operations.

One improving number can hide another cost. More frequent deployment with rising failure and rework is not a clear win. Lower spend with slower recovery moves operational risk into the next quarter. Speed, stability, and cost belong on one scorecard.

Modernization succeeds when the next change gets easier

We documented one monolith split into infrastructure, database, API, and frontend layers, then moved to NKS and GitOps in From a monolith to NKS. Kubernetes was not the core outcome. The work made change points and responsibilities visible again.

A new technical structure does not finish the job. When no one owns the next wave, the improvement backlog slips behind daily operations. Why structural improvement loses an owner covers that ownership gap across assessment, migration, and rearchitecture.

The best sign of completed modernization is not a technology name. It is a system where the team can explain the blast radius of a small change, deploy during a normal weekday, reverse a problem through a known procedure, and leave an architecture the next team can read.

Application Modernization covers assessment and hands-on phased transformation of legacy systems. Cloud & Infrastructure builds the operating foundation, while Product Engineering carries new user-facing products to launch.

References