Application modernization should stop before complexity outruns capability

A smaller modernization step can be the more mature engineering decision when it leaves a system useful, deployable, observable, and supportable in production. Moving farther toward cloud-native architecture can produce worse results when the team and operating model cannot support what they introduce. For CTOs, the central decision is therefore which capability to add next while keeping each intermediate production state coherent.

Modernization starts with the constraint

That decision matters because most modernization work in 2025 concerns established systems. A typical target is a 10-to-20-year-old back-end monolith running .NET Framework 4.x on Windows Server, processing payroll or orders against a database that has gone more than a decade without restructuring. The Konveyor State of Application Modernization Report (2024) found that 59% of modernization budgets go to existing legacy applications and infrastructure.

That focus on existing systems changes what should count as modernization in 2025–2026. Konveyor found that 68% of organizations define modernization as improving CI/CD pipelines, while security, reliability, and scalability are each drivers for more than 70%. Those priorities give CTOs concrete reasons to fund risk reduction and resilience even when application boundaries stay unchanged. A modernization plan can be substantial while preserving the existing architecture.

Within those estates, organizations must also decide where to begin. Konveyor puts core back-end applications first at 41%, followed by data and analytics at 35%. For an old payroll or order-management system, the practical question is how to make production safer and change easier without creating more operational difficulty than the team can absorb. The same test changes how cloud migration should be judged.

Cloud migration depends on operating capability

That test matters because DORA 2024 gives a reason to evaluate cloud migration by operating capability rather than by the amount of infrastructure moved. Organizations using cloud infrastructure without meeting NIST’s five cloud characteristics show decreased organizational performance compared with organizations that remain on-prem. Incremental change is valuable when the resulting state works coherently in production.

NIST’s five characteristics explain the finding: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. DORA found that flexible cloud infrastructure directly increases organizational performance, so the benefit depends on obtaining these operating properties. A cloud account and cloud-hosted machines alone do not create them.

Consider a team that moves its existing virtual machines to AWS while keeping the previous operating process. Without auto-scaling, infrastructure as code, or automated provisioning, capacity stays rigid and infrastructure changes stay manual. The organization now pays cloud costs and works through an unfamiliar control plane while retaining the limitations it intended to remove. The infrastructure location changed, but the team’s ability to operate it did not improve accordingly.

That gap between location and capability defines the proper role of rehosting. Rehosting moves an application unchanged to cloud infrastructure, which can be useful when a data-center lease is expiring, infrastructure must be consolidated, or a compliance deadline requires a move. Under those constraints, changing infrastructure first can be a defensible temporary state because it solves the immediate problem while limiting application change.

Rehosting becomes problematic when the organization treats that temporary state as the destination. The move changes infrastructure without supplying the automation and elasticity that make cloud useful, leaving the organization exposed to the DORA failure mode. A sound intermediate state has two requirements: it must solve a current business or operational constraint, and the team must be able to run it effectively. Those requirements apply just as strongly to containers, platforms, and microservices.

Build the delivery and operating baseline before changing the architecture

Because architecture adds operating demands, the first capability gap to close is often delivery. CI/CD, infrastructure as code, automated testing gates, and automated deployments establish a repeatable path from a code change to production. If a release still depends on someone clicking through a deployment wizard or using SSH to copy files into production, splitting the same application across services multiplies that fragile process.

That repeatable path also needs reproducible infrastructure. Terraform and CloudFormation can put infrastructure changes through a controlled process alongside application delivery. Testing gates catch regressions before deployment, while automation removes manual release steps. Together, these capabilities make later architecture changes manageable because the team can change and recover systems consistently.

Consistent delivery needs an operating counterpart. Observability means having metrics, logs, and traces that let engineers understand a running system across components. Before decomposition, a practical readiness test is whether the team can identify the service responsible for a latency spike within 60 seconds. If finding the responsible component already takes substantial investigation, distributing execution across more processes and network boundaries will make production diagnosis harder.

That diagnostic burden matters because organizations already report complexity as their leading modernization challenge. Konveyor found complexity cited by 48% overall and by 58% of organizations in early modernization stages. Dependency discovery, data migration, and preserving stability all become harder as more moving parts are introduced. Architecture should consume operational maturity rather than be expected to create it.

The same dependency applies to platform engineering. DORA 2024 found that internal developer platforms can improve productivity and organizational performance, but poorly constructed platforms can lower change stability and deployment throughput. A platform that imposes unreliable workflows or rigid toolchains can become another delivery bottleneck. Establishing CI/CD and containerization first gives platform engineering stable processes to standardize and improve.

Even with that foundation, sequencing will vary by organization. System age, team capacity, and the planning horizon change the appropriate decision; a 12-month plan can rationally produce a different architecture from a 36-month plan for the same application. Tool availability should follow that decision because tools implement an approach rather than define the problem. The next modernization move should answer a workload constraint first.

Choose the smallest architecture change that solves the current constraint

With the operating foundation clear, a workload-level decision starts by asking what actually has to change: infrastructure, runtime and deployment, application code and pipeline, or architecture and team boundaries. Those correspond to rehosting, replatforming, refactoring, and decomposition. Each can produce a useful intermediate state because each addresses a different class of problem.

When runtime and deployment are the constraint, replatforming preserves application logic while changing how the system runs and is deployed. A team can take an existing .NET Framework monolith and run it in Windows containers on Amazon ECS or Amazon EKS, gaining a more consistent deployment unit and an easier path toward automated delivery. For a monolith whose business behavior remains sound but whose operations are painful, this can remove the immediate obstacle without requiring a code rewrite.

When application code or the delivery pipeline becomes the constraint, refactoring goes further. A team might migrate from .NET Framework to .NET 6 or .NET 8, produce Linux container images, manage infrastructure through Terraform or CloudFormation, and add automated tests and deployments. That can be a significant modernization outcome while preserving one application boundary. If the real difficulty lies in the domain model, however, upgrading the framework will leave that structural problem in place.

When independent deployment has concrete organizational value, decomposition becomes appropriate. Multiple teams working in separate business domains may need their own release cycles, at which point bounded domains can become independently deployable microservices or serverless functions. Three developers maintaining one system have no such advantage simply from introducing microservices. A well-structured monolith serving two teams can outperform poorly bounded microservices serving those same teams.

Once decomposition is justified, domain-driven design provides a way to decide where separation belongs. Teams identify bounded contexts, meaning business areas with coherent models and responsibilities, before extracting services. Production observability then tests whether those boundaries actually behave independently under real workloads. A service boundary that looks clean in code but repeatedly requires coordinated production changes has failed an important part of that test.

Poorly chosen boundaries can instead create a distributed monolith, a system split into separate deployable components that remain tightly coupled in operation. Those boundaries add network calls, service discovery, and distributed tracing, while releases still require teams to coordinate changes across services. The organization has acquired the operating complexity of distribution without gaining independent delivery. CI/CD and observability are prerequisites because distribution expands the failures and dependencies that engineers must deploy, detect, and diagnose.

For systems that need gradual extraction, the Strangler Fig pattern keeps the legacy application operational while traffic moves progressively to new services. New capabilities can go into new services, existing functions can be retired incrementally, and the older application can eventually disappear as its responsibilities shrink. The production system stays useful throughout the process, so decomposition proceeds through functioning states rather than depending on one future cutover.

Data can require a separate sequence because coupling application and database moves creates additional migration risk. One workable route is to leave the database on-prem during the initial application move, then separate schemas incrementally by domain. That allows the application migration and database restructuring to be validated independently. Long-lived shared schemas remain difficult, but their difficulty does not require both changes to happen simultaneously.

The same workload test applies to serverless architecture. Isolated components with event-driven processing, bursts, high throughput, or large traffic variation can fit serverless functions because capacity does not have to remain provisioned during quiet periods. Techstack’s fundraising platform uses AWS Lambda for high-throughput donation processing, accommodating donation spikes without maintaining idle capacity between them. Techstack sells technology and modernization services, so it has a commercial interest in presenting its implementation choices as effective.

An order-management system implemented entirely as Lambda functions presents a different workload and can create excess complexity. Serverless is one selective architecture option whose value depends on the component being moved. The relevant question is whether the execution and traffic characteristics justify functions for that component.

After the architecture choice comes tooling. AWS App2Container and AWS Microservice Extractor can help teams execute these choices for .NET workloads, just as Amazon ECS, Amazon EKS, and AWS Lambda can host different resulting architectures. AWS benefits commercially when organizations adopt its migration tools and cloud services, so these products should be evaluated as implementations of an already chosen approach. Selecting tooling after identifying the workload constraint keeps a convenient migration tool from deciding service boundaries or forcing a decomposition the organization cannot yet operate.

Tipalti and Techstack show different useful intermediate states

The broader move toward incremental change appears in a 2026 AWS Architecture Blog case about Tipalti. AWS, which benefits commercially from adoption of Amazon EKS and its other cloud services, described how the payments automation company moved a legacy .NET Framework 4.7 monolith into Windows Server 2019 Core images running on Amazon EKS. Tipalti used five migration phases and validated each phase, avoiding a full rewrite and production outages. The case presents incremental containerization as an alternative to big-bang rewriting.

Tipalti’s unit of progress shows why that approach can be substantial. The existing monolith could be containerized in stages and tested as a running production system before further change, while decomposition could wait until there was a reason to undertake it. A containerized monolith can be a deliberate modernization state when it improves deployment and operations and can be supported reliably. Architectural distribution is only one possible later choice.

A different kind of intermediate state appears in Techstack’s client work. A client had several legacy monoliths serving different business functions, and breaking all of them apart would have required years. Techstack connected the systems into one ecosystem using a 9-dots menu pattern while leaving the underlying monoliths intact. Users received a single entry point, and the client avoided a multi-year rewrite.

That integration case also illustrates Techstack’s stated decision process. Techstack’s approach begins by assessing the system, selecting an approach workload by workload, delivering incrementally, and introducing observability from the start. As a technology and modernization services provider, Techstack has a commercial interest in clients adopting this kind of modernization approach. In the client example, that sequence improved the unified user experience before the organization committed to rewriting functioning systems.

The two cases share a criterion: the intermediate production result is useful. Tipalti changed runtime and deployment through a five-phase containerization effort, while Techstack changed integration and the user entry point while preserving multiple applications underneath. Their mechanisms differ, but each produced a usable outcome before deeper architectural change.

AI can accelerate modernization work

The same emphasis on sequencing applies to AI-assisted modernization because automation changes how quickly teams can perform preparatory work. Konveyor 2024 found that more than 75% of organizations use AI in application modernization, with practical uses including dependency mapping, identifying refactoring candidates through code analysis, and generating tests. These tasks can reduce discovery and preparation work around an old codebase.

That help is especially relevant to a large .NET Framework application with weak test coverage. AI can generate baseline tests around critical paths before engineers refactor the code, giving them more evidence about regressions as changes proceed. It can also expose dependencies that need investigation before modules move. Those outputs improve the evidence available for the next engineering decision.

The decision itself still depends on architectural consequences. Engineers must decide which capabilities deserve extraction, when shared data should be divided, and whether a component’s workload makes serverless appropriate. AI can accelerate discovery, analysis, and test creation once the team understands the work it is considering. Architectural justification still comes from the workload, team, and operating requirements.

Measure modernization by production progress

Those architecture decisions become useful only when the operating cadence exposes their production value early enough to survive organizational constraints. A modernization initiative should get a working modernized component into production within three months; cutovers planned 18 months into the future are unlikely to survive budget reviews. Quarterly delivery gives leaders evidence that investment is changing a running system while leaving room to adjust the next step.

That cadence turns modernization into continuing engineering work with repeated production evidence. Teams can keep improving CI/CD and observability and decompose parts of a system as independent deployment becomes valuable, instead of waiting for a two-year clean cutover. Each production release then tests whether the organization can support the capability it has introduced under real operating conditions.

Production evidence should ultimately connect to users. DORA 2024 identifies user-centricity as the strongest predictor of organizational performance. Faster feature delivery, better reliability, and lower latency give teams concrete outcomes against which to judge modernization spending and decide what engineering change should come next.

In conclusion

For executives, the success of application modernization should not be measured by how far a system moves toward a cloud-native ideal. It should be measured by whether each investment improves the organization’s ability to deliver, operate, and change that system while producing a useful production outcome.

That makes modernization a sequencing decision as much as a technology decision. CI/CD, infrastructure as code, observability, containerization, refactoring, and decomposition each solve different constraints and introduce different operating demands. The right next step is the smallest one that addresses a meaningful constraint without creating complexity the organization cannot yet support.

This approach also gives leadership clearer investment checkpoints. Rather than funding a multi-year transformation whose value depends on a final cutover, executives can require measurable production progress within months and use reliability, delivery speed, user outcomes, and operating cost to decide what comes next. Some systems may eventually justify microservices or serverless architectures; others may deliver greater value as well-operated monoliths.

The goal is not to modernize every system as far as possible. It is to build the capabilities the business needs, in an order the organization can sustain.