All Blogs



app modernization scaled

Why is application modernization deferred by many organizations embarking on their cloud journey?

While the official guidance by AWS recommends that applications should be re-architected as part of a cloud migration, a compromise between the business and its technical leadership often results. This compromise curbs the more aspirational goals of the cloud adoption framework often defaulting exclusively to a “lift and shift” migration strategy.

The business drivers for this compromise are financial and strategic:

  • The immediate cost savings realized by eliminating data centers.
  • The immediate cost savings realized by reducing redundant IT staff.
  • Conversion of IT costs from capex to opex.
  • Refocusing IT staff to deliver solutions that directly support their core business strategy.
  • After the last datacenter is shut down and the business is enjoying the immediate value capture from a more accelerated migration path,
  • application modernization is the next logical investment.

A lift and shift migration defers technical debt as well as cost savings.

Some of the costs to a lift and shift strategy are more difficult to quantify. Service disruption due to scalability issues can create opportunity costs in the form of lost revenue or worse, a loss of reputation. Deficient or even suboptimal architectures impacting a business critical application can be a career defining moment. The process of modernizing applications also has the benefit of upskilling technology staff, enabling them to apply cloud native architectures that speed time to delivery for innovative “greenfield” business solutions.

Application modernization is needed to fully exploit the economic and technological benefits cloud adoption promises.

What is application modernization?

Application modernization in the context of cloud generally means the re-architecting of existing applications to fully leverage cloud native services, especially managed cloud services.

Modern architectures can deliver:

  • Scalability to meet future growth in demand.
  • Dynamic elasticity to cost effectively handle peak or unpredictable loads.
  • Cost and maintenance efficiency by leveraging on demand, serverless compute.
  • Robustness and operational resiliency by decoupling services and by leveraging managed services.
  • Increased speed of future solution delivery.

Common architectural patterns of application modernization

Each application potentially brings unique considerations and challenges, but some common architectural guidance is presented here to aid technologists in understanding how application modernization is implemented.


Multi-use databases that were lifted and shifted may be running standalone on EC2 instances. This self-managed configuration still requires dba support for backups, disk space and health monitoring. Licensing issues may be a motivating factor as companies seek to fully consume existing licenses. Migrating self-managed databases to fully managed database services provides better durability and reliability as well as eliminating database infrastructure support needs.

N-tiered Architectures

Many legacy applications implement a tiered architecture often consisting of a data persistence layer, a business logic layer, and an interface.

There are limited migration paths for the data persistence layer. If the database is self-managed running on an EC2 instance or even if it was originally migrated to an RDS instance, a clustered relational database that can scale horizontally like Aurora Serverless may be appropriate.

At the business logic layer, heavy components written in Java or C# that are stateful and tightly coupled to the other application tiers are likely to appear. This architecture does not scale. A modern architecture might implement this as a microservices architecture or a stateless application hosted in an autoscaling group behind a load balancer. Serverless and event-driven architectures utilizing Lambdas, SQS, and application triggers may also be used.

Microservices Architectures

The Service Oriented Architectures (SOA) that rose to prominence in the 2000s has been replaced by microservices architecture theory. Bulky monolithic services are decomposed into separate, more granular services where each service does a lot less. This paradigm shift is motivated by the single responsibility principle, which states that “every module, class, or function should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated.” While a microservice may group functionality together where appropriate this provides insight into the guiding tendency to decouple previously coupled services.

A consequence of microservice architecture is that requests are processed asynchronously, making applications more responsive, and allowing any service disruptions to recover gracefully.

Batch vs Streaming Architectures

Another common pattern for application modernization is the conversion of batch to streaming data architectures. This is often driven by business cases requiring a shorter time to answer than what is currently possible with a batch architecture. Streaming architectures decouple publishing from consuming, adding asynchronous access and flexibility to any downstream data processing.

Containerization & DevOps

Containerization is an imperative in the application modernization context. What containerization allows is the full separation of concerns: infrastructure, application services, and data.

Defining infrastructure as code ensures that the infrastructure the application runs on can be reproduced with 100% fidelity while managing any modifications through traditional software configuration management practices. Containerizing the application code allows it to be deployed to various infrastructures, including on premises as part of a hybrid cloud.

Implementing CI/CD pipelines for the application code ensures that the application is fully decoupled from its infrastructure, unit testing and regression testing can be automated, and if desired, releases also can be scheduled and deployments automated.

The cloud ecosystem and the use of these different strategies, services, and tools means that better monitoring, logging, and alerting is easily achievable. Better capabilities in this area means fewer IT resources are needed to manage an expanding portfolio of applications, freeing resources to solve the next business problems.

Developing an application modernization strategy

The underpinning of any technology strategy is the business case. Not every application will be a candidate for modernization as the costs to modernize can exceed the value added to the business. Luckily there are a few resources and frameworks to guide this analysis.

In 2000, Gartner published research often referred to as “the 5 Rs” (Rehost, Refactor, Revise, Rebuild, or Replace) to assist in the classification and prioritization of applications as part of a cloud migration effort. Although the paper is 10 years old, many of the concepts still apply. Another approach is formally referred to as the Applications Portfolio Analysis (APA) and it consists of classifying applications into three buckets: utility, enhancement, and frontier.

Paraphrasing this guidance, priority should be given to applications that drive the core business. This could include a product or service that generates revenue or directly supports revenue generation. The usefulness of certain legacy applications may allow for them to be decommissioned after a sunsetting period. The functionality of other legacy applications can be replaced by new offerings rather than be migrated.

The last part of an application modernization strategy is execution. The business can seek to source the talent and resources internally, hire directly from the current labor market, or leverage a 3rd party integrator. Application modernization in the cloud context is a complex challenge, especially when aggressive timelines and strict budgets are constraints. The technology staff at most enterprises despite being one or two years into their cloud adoption journey will likely not be properly experienced to execute an ambitious application modernization effort. The daily grind of existing operational maintenance issues and development initiatives may make it difficult or risky to reassign them. Most business savvy technology leaders will recognize quickly that leveraging a 3rd party integrator is the right strategy.