4.1 Cloud Modernization and Migration
Key Takeaways
- Infrastructure modernization replaces aging physical hardware with elastic, on-demand cloud capacity, shifting CapEx to OpEx and offloading hardware maintenance; application modernization decomposes monoliths into microservices, containers, and serverless units to ship features faster.
- The 6 Rs of migration are Retire, Retain, Rehost (lift and shift), Replatform (move and improve), Refactor, and Reimagine—each mapping a different level of change, effort, and cloud benefit.
- Rehost (lift and shift) is the fastest path out of an aging data center for specialized or legacy apps that cannot be safely modified; it preserves the existing OS and runtime and is usually a starting point, not the end state.
- The right strategy per workload is driven by business value, technical debt and risk, and constraints such as regulatory residency rules, vendor lock-in, and team skills.
- A portfolio approach tiers applications into move-fast, modernize, investigate, and sunset buckets so quick wins free up budget for higher-value refactors.
Why Modernization and Migration Matter
Quick Answer: Modernization is the deliberate redesign of how an organization builds and runs IT so it can move faster, scale elastically, and pay only for what it uses. Migration is the journey of moving workloads from on-premises data centers to the cloud. Each application takes a different path because apps differ in business value, technical debt, and risk tolerance.
Modernization and migration are related but distinct projects. Infrastructure modernization replaces aging physical hardware—servers, storage arrays, network gear, and the data-center facilities that house them—with elastic, on-demand cloud infrastructure. The benefits are operational: no capital-intensive hardware refresh cycles, no over-provisioning for peak demand, no maintenance windows for firmware patches, and the ability to scale horizontally in minutes instead of months. Application modernization decomposes long-lived monolithic applications into smaller, independently deployable units—containers, microservices, and serverless functions—so teams can ship features faster, scale components independently, and adopt modern practices like continuous integration and continuous delivery (CI/CD).
The two reinforce each other: modernized infrastructure gives you the elastic capacity that modernized apps need, and modernized apps take advantage of that capacity without wasting it. Organizations that modernize only infrastructure gain cost savings but miss velocity; organizations that modernize only apps gain agility but are blocked by brittle on-premises foundations.
Benefits of Modernizing on Google Cloud
| Benefit | Infrastructure modernization | Application modernization |
|---|---|---|
| Cost | Shift CapEx to OpEx; pay per use; sustained-use and committed-use discounts | Smaller footprint per service; scale-to-zero eliminates idle spend |
| Velocity | Provision resources in minutes, not months | Independent deploys; CI/CD; faster feedback loops |
| Scale | Autoscaling and global load balancing built in | Microservices scale independently by demand |
| Reliability | Managed services with built-in high availability and SLAs | Fault isolation across services; graceful degradation |
| Talent | Off-load hardware ops to Google; redeploy staff to higher-value work | Developers focus on code, not servers |
A typical transformation starts with quick wins—rehost or replatform the easy workloads to capture cost and reliability gains immediately—then sequences the higher-value refactors once teams have cloud experience and freed-up budget. Google Cloud accelerates this by offering managed services at every layer (Compute Engine, Cloud SQL, GKE, Cloud Run, Cloud Functions) so each application can move to the lowest-management-overhead option that still meets its requirements.
The Migration Strategy Spectrum: The 6 Rs
Not every workload takes the same path to the cloud. Google and industry analysts describe six standard migration strategies—often called the 6 Rs—that map each application to the right level of change.
| Strategy | Definition | Effort | Cloud benefit | Best-fit scenario |
|---|---|---|---|---|
| Retire | Decommission the application entirely. | Low | Eliminates licensing, hardware, and ops cost | Redundant, unused, or already-replaced apps; shelfware |
| Retain | Keep the application on premises (revisit later). | None | No immediate investment; risk deferred | Apps with regulatory/data-residency blocks, upcoming vendor renewal, or no business case yet |
| Rehost (lift and shift) | Move the application to the cloud with little or no code change. | Low–medium | Fast migration; immediate infrastructure savings; baseline for later optimization | Legacy or specialized apps that can't be refactored easily; tight deadlines; "move first, optimize later" |
| Replatform (move and improve) | Move with small changes to take advantage of cloud capabilities (e.g., swap self-managed MySQL for Cloud SQL). | Medium | Reduced ops overhead without a full rewrite; some cloud-native benefits | Apps that can adopt managed services with minimal code change |
| Refactor | Re-architect the application—often splitting a monolith into microservices—to be cloud-native. | High | Maximum agility, scalability, and cost efficiency | Strategic, high-value apps that drive competitive advantage |
| Reimagine | Reinvent the application or business model using cloud-native paradigms (e.g., a batch process becomes a real-time ML-driven service). | Highest | Transformational business outcomes | Core differentiators where the cloud enables a new product or revenue model |
The 6 Rs are not a one-time decision: an application commonly starts as rehost for speed, is later replatformed to a managed service to cut ops load, and is eventually refactored into microservices (some of which become serverless) once the team understands its domain boundaries. The goal is to sequence work so each step unlocks the next.
Why Different Applications Take Different Paths
The right strategy for each workload is a function of three inputs:
- Business value — How much competitive advantage does the app deliver? A customer-facing revenue app is worth refactoring; an internal reporting tool may only need replatforming.
- Technical debt and risk — How fragile is the code, and how hard is it to change? A tangled legacy monolith with no automated tests may be safer to rehost first and refactor later, once the team has added test coverage.
- Constraints — Regulatory data-residency rules, vendor lock-in, licensing terms, and team skills all limit the feasible options.
A typical portfolio assessment classifies apps into tiers: a move-fast tier (rehost or replatform this quarter), a modernize tier (refactor over the next 1–2 years), an investigate tier (retain pending a decision), and a sunset tier (retire). Sequencing matters: quick wins free up budget and attention for the harder, higher-value refactors, and early cloud experience builds the team confidence needed for the bigger re-architectures.
Exam trap: "Lift and shift" and "move and improve" are Google's own phrasings for rehost and replatform. The exam may use either pair of terms interchangeably—know both. Also remember that retire and retain are legitimate strategies, not a cop-out: retiring a redundant app saves more money than any migration, and retaining a regulated app that cannot yet move is the correct, risk-aware decision.
An organization wants to migrate a mission-critical, customer-facing monolith to take maximum advantage of cloud-native scalability. Which strategy is most appropriate?
A team runs a self-managed MySQL database they want to move to the cloud with minimal code changes while reducing operational overhead. Which strategy fits best?
What is the primary benefit of infrastructure modernization compared with application modernization?
An internal HR tool is rarely used, duplicates functionality in a SaaS product the company already licenses, and carries steady maintenance cost. What is the most appropriate migration strategy?