A legacy system is an existing application or technology that must keep running while its development, deployment, or architecture changes. It may be a monolithic application on VMs, but not every legacy workload should be containerized or rewritten. The practical goal is to improve operations without interrupting the application that the business still needs. section 16.1 section 16.2.1
Choose a modernization path for each application or component:
- Identify the target and assess whether it suits containerization. Use Migrate for Anthos when suitable; containerize manually when the application is too complex for that route. section 16.2.1
- Build, test, and deploy through a CI/CD pipeline. Add automated tests and observability so teams can find problems without relying on access to a dedicated VM. section 16.1 section 16.2.1
- Operate the application through Anthos for configuration, security, and connectivity. Refactor toward microservices when appropriate, rather than making a complete rewrite the first step. section 16.2.1 section 16.6
- Move applications not yet suited to containers to Compute Engine if they are in scope for later modernization. Leave out-of-scope systems in their current form and secure connections to them with Anthos Service Mesh. section 16.2.1
A three-tier Java application
A monolithic Java application running on WebSphere or WebLogic is a candidate for an application-server change—but only after checking whether its source uses proprietary server features. If it does not, an open-source server such as Apache Tomcat or JBOSS may remove unnecessary licensing costs while the deployment is rebuilt. A framework change, such as a move to Spring Boot, is a separate redesign decision. section 16.2.1
Containerization can reduce VM management and bring a legacy application into the same Day 2 operations as cloud-native workloads, including observability and uniform policy management. Greater workload density and elastic scaling can also reduce infrastructure cost. These are reasons to modernize incrementally, not reasons to assume every system needs the same destination. section 15.1.7 section 15.1.2 section 16.6
