Cloud Migration: Rehost, Replatform, or Redesign?

Migration strategy is often presented as a set of labels: rehost, replatform, refactor, re-architect, replace, or retire. Those labels are useful shorthand, but they are not decisions by themselves. The right path depends on business deadlines, technical debt, dependencies, licensing, data gravity, operational skill, resilience requirements, and how much change the organization can absorb at once.

The Professional Cloud Architect exam and the Google Professional Cloud Architect role both reward this trade-off thinking. An architect should be able to choose a migration path that improves the system enough without turning the migration into an uncontrolled rewrite.

A good plan begins with discovery and dependency mapping, then chooses a path per workload. Enterprises rarely have one migration strategy for everything.

Rehost when speed and compatibility dominate

Rehosting moves a workload with minimal application change. It can reduce data-center dependency quickly, preserve familiar operating behavior, and create breathing room before deeper modernization.

A structured cloud migration planning is useful because rehosting still requires network, identity, security, sizing, backup, monitoring, cutover, and rollback decisions. ‘Lift and shift’ does not mean ‘copy and hope.’

Rehost is strongest when the application is stable, change risk is high, time is limited, or the organization needs to exit hardware or a facility before it can justify code changes.

Replatform when managed services remove real operational burden

Replatforming changes selected infrastructure layers without redesigning the whole application. Examples include moving a self-managed database to a managed database, replacing a manual load balancer with a managed service, or containerizing an application while preserving its core architecture.

The goal is to remove undifferentiated operations while keeping application change bounded. This can produce meaningful reliability and maintenance gains with less risk than a complete rewrite.

Evaluate compatibility carefully. Extensions, drivers, file-system assumptions, authentication, background jobs, and maintenance behavior can make a seemingly small platform change larger than expected.

Redesign when the current architecture blocks the business

A deeper redesign is justified when the current system cannot meet important goals: independent scaling, faster deployment, global availability, resilience, new data volume, security boundaries, or a major change in product direction.

Patterns such as serverless architecture can reduce infrastructure work when the workload fits them, but redesign should be tied to a specific limitation. ‘Cloud native’ is not a business requirement.

Modernization has an opportunity cost. While engineers rebuild a mature system, they are not delivering other product work. The expected operating or business benefit should be large enough to justify that investment.

Retire and replace are first-class options

Some systems should not move. Discovery often reveals unused applications, duplicate tools, obsolete reports, and workloads whose business process has already moved elsewhere. Retiring them is the cheapest migration.

Replacing a custom application with a SaaS or managed product can also be rational when the capability is not differentiating. The migration challenge becomes data, identity, integration, and process change rather than infrastructure.

Architects should resist the instinct to preserve every technical asset simply because someone once paid to build it.

Dependencies determine migration waves

Workloads are connected by databases, shared identity, DNS, file shares, APIs, batch exchanges, network routes, and human processes. Moving one application without its critical dependencies can increase latency or create a fragile hybrid state.

Map dependency direction and sensitivity. Some connections can tolerate cross-environment latency for months; others must move together. Migration waves should group workloads around those realities rather than arbitrary department boundaries.

The operating lessons in cloud-native application architecture become useful when deciding which dependencies should remain tightly coupled and which interfaces deserve separation during modernization.

Data movement is often the critical path

Applications can be redeployed quickly compared with large databases and file estates. Estimate transfer time, synchronization method, change rate, cutover window, validation, encryption, and rollback before promising a migration date.

For databases, decide whether the target can replicate from the source and how long dual-running is acceptable. For object data, verify checksums and metadata. For regulated data, confirm location and access controls before copying production information.

A migration is not complete when bytes arrive. The data must be consistent enough for the business process to resume.

Design the hybrid period intentionally

Most programs spend time with systems split between old and new environments. That period needs architecture: routing, DNS, identity federation, logging, monitoring, support ownership, certificate management, firewall change, and cost control.

Hybrid dependencies should be temporary where possible and visible in the plan. An undocumented temporary connection can become a permanent production dependency that nobody wants to own.

The same reliability thinking used for high availability and fault tolerance applies during migration. The transition state may have more failure modes than either the source or the target, so critical paths deserve extra testing.

Use measurable exit criteria for each wave

A migration wave should have success criteria beyond ‘servers are running in Google Cloud.’ Measure application latency, error rate, backup success, security controls, operational ownership, cost, and user acceptance. Compare them with the pre-migration baseline.

Define rollback criteria before cutover. If data reconciliation exceeds a threshold or a critical integration fails, the team should know whether to roll back, continue in degraded mode, or pause for repair.

After stabilization, remove obsolete infrastructure and connectivity. Paying for both environments indefinitely can erase the financial case for migration.

Cutover planning should account for data divergence, not just infrastructure readiness. When a source system continues to accept writes during replication, define the point at which writes stop, how the final changes are reconciled, and which system becomes authoritative after the switch. A rollback is simple only while the old environment still contains the complete current state; once users write new data in the target, returning may require reverse replication or a carefully controlled reconciliation. The same applies to DNS, caches, message producers, batch jobs, and third-party integrations that may continue using the old endpoint after the main application moves. Measure these tails during rehearsal. A migration wave is safer when the team knows exactly which dependencies must be frozen, drained, redirected, or validated and how long each step takes. That evidence should shape the migration strategy as much as the theoretical benefits of rehosting, replatforming, or redesigning.

Choose the path that removes the most important constraint

A useful portfolio table lists each workload, business criticality, dependencies, technical health, migration deadline, target benefit, expected path, estimated change effort, data complexity, and modernization opportunity. That makes the reasoning visible across hundreds of applications.

The same application can also use more than one path. A web tier may rehost first, a database may replatform to a managed service, and a background batch process may later be redesigned around events. Strategy does not need to be ideologically pure.

Revisit the decision after the first migration wave. Cloud operating experience changes what teams are capable of, and early assumptions about cost, performance, and skill may prove wrong. A portfolio plan should learn.

Rehost, replatform, and redesign are therefore best treated as degrees of change. Use the smallest degree that removes the current business constraint, preserves a safe migration, and creates a credible next step. Migration succeeds when the organization ends with a system it can operate better—not merely the same problems running in a different building.

Migration economics should be tracked per wave. Rehosting may deliver a fast data-center exit but preserve licensing and operational cost, while replatforming may require more project effort and reduce recurring toil. Compare one-time change cost with expected multi-year operating impact so the program does not select the fastest path for every workload by default.

Use production-like rehearsal for the hardest cutovers. Replicate data, test DNS and routing changes, run smoke tests, confirm monitoring, measure synchronization lag, and practice rollback. A migration plan that has never been rehearsed is relying on assumptions at the exact moment the organization has the least tolerance for surprise.

Organizational readiness can also sequence waves. Early migrations should build reusable identity, networking, monitoring, and deployment patterns that later teams can consume. Moving the most complex application first may create unnecessary risk if the platform foundation and support model are still immature.

After each wave, capture what changed in the decision model. Perhaps rehosting took longer than expected because of firewall dependencies, or a managed database removed more operational effort than forecast. Use those lessons to update estimates for the remaining portfolio instead of repeating the same assumptions across hundreds of workloads.

Security baselines should move with the workload rather than wait until after cutover. New cloud identities, firewall rules, secrets, encryption settings, logging, and administrative roles should be reviewed as part of the migration wave. Otherwise a program can meet its schedule by creating a temporary security posture that quietly becomes permanent.

Application performance needs a before-and-after baseline too. Capture normal latency, throughput, error rates, batch duration, and resource consumption before moving. After cutover, those measures make it possible to distinguish a migration regression from an old problem that simply followed the application to the cloud.

Keep a retirement checklist for source infrastructure. Decommission old servers, revoke replication accounts, remove temporary routes, release licenses, close firewall rules, and archive required evidence. The financial and security benefits of migration are incomplete while the original environment remains active ‘just in case.’

A migration decision should also identify what must remain reversible. Early waves benefit from choices that can be rolled back or changed as the team learns, while irreversible data or contract commitments deserve stronger evidence. Reversibility keeps a program from turning its first cloud assumptions into permanent constraints.