Cloud migration strategy is often summarized with labels such as rehost, replatform, and refactor. Those labels are useful only when they express a real decision about how much change the organization is willing to make before, during, and after migration.
Google Cloud Migration Center describes a broader set of paths that can include rehost, replatform, refactor or re-architect, replace, and retire. For a Professional Cloud Architect, the important skill is choosing a path workload by workload rather than declaring one modernization strategy for an entire portfolio.
Rehost minimizes application change
Rehosting moves a workload to cloud infrastructure with relatively little change to the application architecture.
A traditional virtual machine application might move to Compute Engine with similar operating system, middleware, and database assumptions. Network addresses, storage, backup, monitoring, and authentication still need redesign, but the application code remains largely intact.
Rehost is valuable when time matters, source code is difficult to change, vendor support constrains the platform, or the migration program first needs to exit a data center.
Its weakness is that legacy operating costs often move with the workload. The organization may still patch servers, manage capacity, and support architecture designed for an on-premises environment.
Rehost should therefore be considered a valid end state for some workloads and a temporary landing zone for others.
A disciplined rehost still changes infrastructure assumptions. IP addresses, DNS, firewall rules, load balancers, backup destinations, monitoring, and identity integrations must be redesigned for Google Cloud. Treating rehost as a literal VM copy can reproduce on-premises fragility while giving the migration team false confidence that little planning is required.
Replatform changes the runtime without rewriting the business system
Replatforming keeps the application’s basic architecture but moves selected responsibilities to managed cloud services.
A self-managed database might move to Cloud SQL. An application running on manually maintained servers might move to a managed container platform. A messaging component might be replaced by a managed service while the surrounding application remains intact.
This can remove operational toil without requiring a full redesign.
The risk is underestimating compatibility. A managed database may differ in extensions, filesystem access, administrative privileges, backup behavior, or connection limits. A managed runtime may change local storage, scaling, or networking assumptions.
Replatforming works best when each changed dependency is tested as a product migration, not treated as a simple hosting change.
Operational procedures change too. A managed database may no longer allow host-level agents or privileged filesystem access. Managed runtimes may rotate instances, scale automatically, or separate configuration from local disk. Runbooks, backup procedures, and incident ownership should be rewritten alongside the technical migration.
Refactor changes the application to use a new architecture
Refactoring or re-architecting changes the workload more substantially.
A monolith may be decomposed into services. Stateful local processing may move to managed data stores. Batch work may become event-driven. Application components may be redesigned for autoscaling, failure isolation, and managed identity.
This path can create the greatest long-term cloud benefit, but it also carries the highest delivery risk.
A refactor combines migration with software development. Requirements can change, defects can be introduced, timelines can expand, and teams may discover hidden coupling only after work begins.
That is why “cloud native” should not automatically mean “refactor everything before migration.”
Refactoring is strongest when the expected value is measurable: reduced release coupling, higher availability, lower operational cost, better scaling, faster feature delivery, or removal of an unsupported technology. If the team cannot name the improvement and how it will be measured, the refactor risks becoming an open-ended modernization program.
Business deadlines change the correct strategy
The same application can have different correct migration paths under different constraints.
If a data center lease ends in six months, rehosting may be the only strategy that gets the workload out safely.
If the workload is stable but expensive to administer, replatforming one or two infrastructure components may create most of the value.
If the application blocks product growth, has severe scaling limits, and is actively developed, refactoring may justify the additional work.
Migration strategy is therefore a portfolio decision under constraints. Architecture purity is secondary to business outcome.
Google recommends discovery and assessment before migration planning so workloads, dependencies, and candidate modernization paths are understood.
Dependency mapping prevents false simplicity
Applications rarely migrate alone.
A server may depend on a database, file share, directory service, SMTP relay, monitoring agent, license server, partner endpoint, scheduled job, or another internal application.
Rehosting the server without those dependencies can create a workload that boots successfully but cannot perform useful work.
Dependency mapping should identify technical connections and operational dependencies such as backup, patching, support ownership, and security review.
Migration waves can then group workloads that should move together and separate workloads whose risk should not be combined.
Wave design should also consider business calendars. Payroll, quarter-end finance, retail peak season, and regulatory reporting periods can make an otherwise low-risk technical cutover unacceptable. Migration planning is therefore both dependency management and change-management scheduling.
This is one of the most important reasons not to choose strategy from a spreadsheet containing only server names.
Data migration can dominate the timeline
Compute is often easier to move than data.
Large databases and file repositories introduce transfer duration, synchronization, cutover, validation, and rollback questions. A rehosted application may still need a carefully staged data migration.
Replatforming a database can add engine-version and compatibility work. Refactoring can change the data model itself, making migration part of application transformation.
The migration plan should define:
- source of truth during transition,
- replication or transfer method,
- expected outage,
- validation procedure,
- rollback point,
- data retention after cutover.
A workload is not migrated merely because its new compute environment is ready.
Cutover strategy should state whether the move is big-bang, blue/green, canary, or parallel-run. The correct method depends on how traffic and data can be synchronized. Systems with difficult rollback should receive more pre-cutover validation and a narrower change window because “restore the old VM” may not be sufficient once production writes have occurred in the new environment.
Security and operations should improve during migration
Migration creates an opportunity to remove unsafe historical practices.
Long-lived service credentials can move toward managed identity. Broad network access can be narrowed. Logging and monitoring can be standardized. Backup policies can be made explicit. Infrastructure can be represented as code rather than undocumented manual configuration.
These improvements do not require a full refactor.
A rehost can still adopt better IAM, centralized logging, modern backup, and controlled network boundaries. A replatform can reduce the number of systems the team patches. A refactor can redesign failure handling and authorization more deeply.
The migration path should identify which operational improvements are mandatory for cutover and which can safely follow later.
Use a staged modernization path when uncertainty is high
Migration strategies can be sequential. Define a stopping point after each stage so the workload can remain stable if the next modernization step no longer has a compelling business case.
A workload might be rehosted to Compute Engine to meet a deadline, then replatform its database after cloud operation stabilizes, then refactor selected components when business value justifies it.
This avoids combining infrastructure migration, database migration, and application rewrite into one irreversible release.
It also gives teams better information. Real cloud telemetry may reveal that the expected scaling problem does not exist or that a different dependency is the true bottleneck.
A staged roadmap should mark each later modernization step as optional until its value is reconfirmed. Otherwise a sensible rehost becomes contractually tied to a refactor whose assumptions were made before the workload ever ran in Google Cloud.
Google Cloud architecture connects migration choices to reliability, cost, security, and operating-model decisions. A staged modernization plan should still be driven by workload evidence, dependency risk, and business priority.
Choose the minimum change that achieves the required outcome
A useful decision rule is:
Rehost when speed, compatibility, or risk reduction requires minimal application change.
Replatform when managed services can remove meaningful operational burden without requiring a full application redesign.
Refactor when the current architecture prevents business, reliability, security, or scale objectives and the organization can fund software change.
Replace when a commercial or SaaS capability can satisfy the business need better than maintaining the current application.
Retire when the workload no longer justifies migration at all.
Google Cloud architecture study reinforces broad architectural thinking, but migration success comes from making the smallest justified change for each workload. A good cloud program modernizes where the value is real and resists rewriting systems simply because migration created an opportunity to do so.
After each wave, compare actual cost, incident rate, deployment effort, and support load with the assumptions used during assessment. That feedback should change later waves. If replatforming consistently delivers most of the benefit with less disruption than expected refactors, the migration factory should adapt rather than defending the original taxonomy. Portfolio migration is strongest when it learns: early workloads validate landing-zone, networking, database, identity, and operational patterns before the organization applies them to harder systems and higher-risk cutovers with tighter business deadlines and dependencies.