Cloud modernization and migration

Study guide for Cloud Digital Leader, Unit 4 · Topic 1. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks. Explain why modernization and migration to the cloud are important steps in an organization’s transformation journey, and how each application might have a different path.

Objectives, quoted from the exam guide:

1. Discuss benefits of infrastructure modernization and application modernization by using Google Cloud.
2. Define the main cloud migration terms, including: workload; retire; retain; rehost; lift and shift; replatform; move and improve; refactor; reimagine.

Cloud modernization and migration

Moving something, changing something, and a different answer per application

Migration moves applications, data and infrastructure to the cloud. Modernization transforms them to use the cloud better. And the exam's recurring point: each application gets its own path — retire, retain, rehost, replatform, refactor or reimagine.

Unit four is about modernizing infrastructure and applications, and its first topic sets the vocabulary for everything after it. The guide asks why modernization and migration are important steps in a transformation journey, and how each application might have a different path. Those are two different words, and Google keeps them apart. Cloud migration is the process of moving applications, databases, data storage, and the related networking, security and infrastructure to a cloud computing environment. Cloud modernization, on the other hand, is a strategy for transforming existing applications, data and infrastructure to take better advantage of the benefits of cloud computing. Moving is not the same as changing, and most of this topic is about how much changing each application should get. The first objective asks what modernization buys, for infrastructure and for applications. The second is vocabulary: workload, and the six paths an application can take, together with the nicknames the industry uses for them.

What modernization buys: infrastructure, then applications

One changes where the application runs; the other changes the application

• Infrastructure: approaches from rehost to replatform
• Infrastructure: avoid expensive hardware refresh cycles
• Applications: innovate faster while lowering costs
• Applications: containers, microservices and serverless instead of VMs
• Managed services automate tasks and speed time-to-market

Worked example (synthetic). A retailer's data center hardware is due for replacement next year. Moving its virtual machines to Google Cloud avoids buying the next generation; rewriting its checkout as containers is a separate, later decision.

The first objective asks for the benefits of infrastructure modernization and of application modernization, and the exam expects you to keep them apart. Infrastructure modernization is about the platform an application runs on. Google describes flexible infrastructure modernization approaches from rehost to replatform — so the application itself changes little or not at all. The headline benefit is financial: migrating applications to cloud helps you avoid expensive refresh cycles, the periodic replacement of data center hardware. Google even offers a way to move VMware environments and run those workloads natively on Google Cloud without refactoring the applications. Application modernization changes the application. Google says its application modernization solutions help you innovate faster while lowering costs, with a consistent development and operations experience. The concrete moves are the cloud-native architectures — serverless data platforms, microservices and containerization — and managed services that automate tasks, unlock new functionality and drive faster time-to-market. One example makes the difference vivid: Google's serverless compute platform abstracts away all infrastructure management by automatically scaling up and down from zero, depending on traffic. That is a benefit only an application built for it can collect.

Infrastructure against application modernization

Which layer changes, and what the change buys

Worked example (synthetic). An exam item describes a bank that moves its virtual machines unchanged and asks which benefit it has collected. The graded answer is avoiding a hardware refresh — not faster feature delivery, which needs the application to change.

Side by side, the two kinds of modernization differ in exactly one thing: which layer changes. Infrastructure modernization changes where a workload runs, from rehost to replatform, and leaves the application largely alone — Google's VMware offering runs those workloads natively without refactoring the applications. What it buys is escape from the hardware cycle: migrating applications to cloud helps you avoid expensive refresh cycles. Application modernization changes how the application is built. Google's example is migrating traditional apps away from virtual machines and into native containers, and the benefit it names is innovating faster while lowering costs. The table's value is in the third row. A benefit that depends on the application being rebuilt — faster delivery, scaling from zero — cannot be collected by moving an unchanged virtual machine, however modern the platform underneath it is.

One portfolio, several paths at once

Each workload gets the approach that suits it

Figure: A flow chart in which one application inventory fans out to six applications, each assigned a different path: retire, retain, rehost, replatform, refactor and reimagine. The paths apply at the same time, not in sequence.

Worked example (synthetic). A company is told it must pick one migration strategy for its whole estate. Google's guidance says the opposite: decide which approach works best for each workload.

This is the idea in the topic summary — how each application might have a different path — drawn out. Google's hybrid and multicloud guidance says you can decide which approach works best for each workload or application stack, and describes the various migration and modernization paths as approaches that can be simultaneously applied to different workloads, driven by the business and technical requirements of each. The step that decides the paths is application rationalization: going over the application inventory to determine which applications should be retired, retained, rehosted, replatformed, refactored or reimagined. The example application names here are synthetic, but the shape is the point. A portfolio is not migrated with one strategy; it is sorted, and each branch runs at its own pace. Google also frames migration itself as a multi-phase process — assessment, planning, migration, and optimization or modernization — so modernization can follow a migration rather than having to happen at the same moment.

The six paths an application can take

Retire, retain, rehost, replatform, refactor, reimagine

Worked example (synthetic). A company finds a reporting tool nobody has opened in two years. That is retire, not rehost: moving an unused application to the cloud only moves its cost.

The second objective is vocabulary, and the six core terms come from one Google source: its guidance on application rationalization, which lists exactly these outcomes. Retire means decommission the application and compute at source — it does not move at all, it stops. Retain means keep the application as it is, hosted in the current environment. Those two are the paths that are not migrations, and the exam likes to test that they exist. The other four are migrations of increasing depth. Rehost moves workloads from a source environment to a target environment with minor or no modifications or refactoring. Replatform lifts the existing workloads and then optimizes them for the new cloud environment. Refactor modifies the workloads to take advantage of cloud capabilities, not just to make them run. The rationalization guidance words the same three more briefly — rehost migrates to similar compute elsewhere, replatform upgrades the application and re-installs it on the target, and refactor makes changes to move the application towards cloud-native traits. And reimagine is re-architect and rewrite. The guide also asks you to define workload. Google's cloud migration page describes workloads as resources running in the cloud that consume some type of resource, such as computing power or storage capacity — the unit that each of these six decisions is made about.

Lift and shift, lift and optimize, move and improve

Three nicknames, and which term each one belongs to

• Rehost is lift and shift
• Replatform is lift and optimize, in Google's current guide
• Refactor is move and improve
• Reimagine appears in Google's guide as rebuild: decommission and rewrite

Worked example (synthetic). An item describes moving containers into Google Kubernetes Engine after a first move, and calls it "move and improve". Google's current guide calls that replatform — lift and optimize — and keeps "move and improve" for refactor.

The guide pairs each migration term with a nickname, and this is where candidates lose marks, because two Google vocabularies are in play. Google's migration guide in the Architecture Center names the types with their nicknames side by side: rehost is lift and shift, replatform is lift and optimize, and refactor is move and improve. Notice what that does to the guide's list, which places move and improve straight after replatform. On Google's current page, move and improve belongs to refactor, and replatform's nickname is lift and optimize. This deck teaches Google's current pairing and flags the difference, so an item that uses either phrasing still makes sense to you. Reimagine is the other term that shifts: the rationalization guidance calls it re-architect and rewrite, while the migration guide's nearest term is rebuild, in which you decommission an existing app and completely redesign and rewrite it as a fully cloud-optimized app. Different label, same idea: the old application is not moved, it is replaced by a new one.

The migration ladder: effort against benefit

Each step up costs more work and collects more of the cloud

Figure. Four cards arranged left to right from least to most change: rehost, which is easiest but leaves workloads unoptimized; replatform, which takes more work; refactor, which requires new skills; and reimagine, which rewrites the application entirely.

Worked example (synthetic). A team with no cloud experience and a fixed deadline rehosts first. Google calls that commonly a first step in a larger transformation — the ladder can be climbed later.

Read left to right, the four migration paths form a ladder, and every rung trades effort for benefit. Rehost is the bottom rung. Google says rehost migrations are the easiest to perform because your team can continue to use the same set of tools and skills — but after a rehost, the workloads running in the target environment aren't optimized for the cloud. Replatform lifts and then optimizes; Google's example is moving to a cloud-based microservice architecture or containers in Google Kubernetes Engine, and it notes that replatform migrations take more work to accomplish than rehost migrations. Refactor modifies the workloads to take advantage of cloud capabilities, and Google says a refactor migration also requires that you learn new skills. At the top, reimagine replaces the application with a rewrite. The ladder does not have to be climbed in one go. Google's cloud migration page calls rehosting commonly a first step in a larger digital transformation project, which is exactly how an organization under time pressure moves now and modernizes later.

Choosing the path, one application at a time

The conditions Google attaches to each path

Figure: A decision flow chart. If an application is no longer needed, retire it. If it must stay where it is, retain it. If it is not meeting its goals, reimagine it. If it needs a major update or is unsupported as it is, refactor it. If the organization wants cloud strengths beyond simply running, replatform it. Otherwise rehost it.

Worked example (synthetic). A payroll system's source code cannot be modified and the business cannot switch it off. Google's rule is explicit: if you cannot refactor a workload and cannot decommission it, you must rehost.

This figure turns the vocabulary into a decision, using the conditions Google attaches to each path. Start by asking whether the application is still needed; if not, retire it — decommission it and the compute at source. If it must stay where it is, retain it. If the application is not meeting its goals — Google's examples are that you don't want to maintain it, it's too costly to migrate another way, or it's not supported on Google Cloud — the answer is a rewrite, which the migration guide calls a rebuild and the rationalization guidance calls reimagine. If a major update to the workload is necessary in addition to the updates needed to migrate, Google names refactor. If the organization wants the core strengths of the cloud rather than just a new place to run, replatform. And rehost is ideal when a workload can operate as-is in the target environment, or when there is little or no business need for change. One rule overrides the tree, and it is worth memorizing word for word: if you cannot refactor a workload to migrate and cannot decommission the workload, you must use a rehost migration.

What this topic actually tests

Three discriminations, two objectives

Moving or changing? migration moves; modernization transforms. Which layer? infrastructure modernization avoids hardware refresh; application modernization innovates faster. Which path, for THIS application? retire and retain do not migrate; rehost, replatform, refactor and reimagine migrate with increasing change.

Close on the three discriminations this topic tests. First, moving against changing: migration moves applications, data and infrastructure to the cloud, while modernization transforms them to take better advantage of it. Second, which layer changes: infrastructure modernization, from rehost to replatform, avoids expensive hardware refresh cycles and leaves the application largely alone; application modernization rebuilds the application with containers, microservices and serverless, and is what lets an organization innovate faster while lowering costs. Third, the path for each application: retire and retain are decisions not to migrate, and rehost, replatform, refactor and reimagine migrate with increasing depth of change, effort and benefit. Remember that Google applies these paths simultaneously, workload by workload, and that its current guide attaches move and improve to refactor. The rest of Unit 4 — compute, serverless, containers, application programming interfaces and hybrid cloud — is the toolkit these paths draw on.

Official sources for this topic

• Cloud Digital Leader exam guide — Section 4
• What is cloud migration? — Google Cloud
• Modernization vs. migration for data workloads — Google Cloud Blog
• Infrastructure modernization — Google Cloud
• Application modernization — Google Cloud
• Application rationalization — Google Cloud Blog
• Migrate to Google Cloud: Get started — Cloud Architecture Center
• Architectural approaches to adopt a hybrid or multicloud architecture