90–120 Day Playbook: Cloud Migration Strategy by Workload for IT Teams
Back to Blog

90–120 Day Playbook: Cloud Migration Strategy by Workload for IT Teams

September 9, 202613 min read

90–120 Day Playbook: Cloud Migration Strategy by Workload for IT Teams

Engineers monitoring a cloud workload migration
Engineers monitoring a cloud workload migration

A cloud migration strategy maps every workload to one of the 7 Rs and moves it through a three-phase lifecycle: Assess, Mobilize, and Migrate & Modernize. The immediate next step isn't picking a cloud provider. It's running a portfolio inventory and dependency map, because that document decides which R applies to each system. Get the 7 Rs framework and a Cloud Center of Excellence in place before you touch a production workload, and plan on a 90–120 day playbook for a well-scoped first wave.

TL;DR:

  • Prioritize dependency mapping and establishing a Cloud Center of Excellence before migrating production workloads to avoid cost surprises and security gaps.
  • Use the seven R strategies selectively, aiming to rehost for quick wins and reserve refactoring for workloads that justify long-term effort and cost savings.
  • Follow a phased approach: assess and build the migration foundation first, then automate and validate in scalable waves, to reduce the risk of failure.
  • Schedule dependency-based migration sequences starting with non-production environments, moving to simple applications, and ending with mission-critical systems to ensure stability.
  • Conduct comprehensive testing—including security and disaster recovery—before cutover and set clear rollback procedures to protect against unexpected issues.

Table of Contents

The 7 Rs: What Each Cloud Migration Strategy Means

Most failed migrations trace back to one mistake: treating every application the same way. The 7 R's of cloud migration, a framework IBM helped popularize and now widely used across enterprise IT, exists specifically to stop that.

Here's what each R actually means, and when it earns its place on your roadmap:

  • Retire — Decommission the workload. It's dead weight, redundant, or nobody remembers why it's running. Common in portfolios where a notable portion of apps have zero active users.
  • Retain — Leave it where it is, for now. Applies to systems with compliance restrictions, recent capital investment, or dependencies too tangled to touch this cycle.
  • Rehost — Lift and shift, same architecture, new infrastructure. Fastest path to the cloud, minimal code change, but you carry over any existing inefficiency.
  • Relocate — Move the whole infrastructure stack (often a VMware environment) into the cloud with no re-architecture. Faster than rehosting individual apps, useful for data center exits.
  • Repurchase — Swap the custom or legacy tool for a SaaS equivalent. Makes sense when the workload isn't a competitive differentiator.
  • Replatform — Move to the cloud with targeted upgrades, like swapping a self-managed database for a managed service. Middle ground between speed and modernization.
  • Refactor/Rearchitect — Rebuild for cloud-native patterns: microservices, containers, serverless. Highest effort, highest long-term payoff.

The mistake teams make most often is rehosting workloads that actually needed refactoring, a mistake avoidable with the right migration plugins for Strapi. It clears the migration deadline but locks in years of unnecessary cloud spend, because a poorly architected app costs the same to run wherever it lives. As a rule of thumb, rehost buys you weeks, replatform buys you months of runway, and refactor is a multi-quarter investment you make only when the workload justifies it.

Assess, Mobilize, Migrate: The Three Phases That Cut Migration Risk

The 7 Rs tell you what to do with each workload. The Assess, Mobilize, Migrate & Modernize lifecycle tells you when, and skipping a phase is where most cloud transition plans quietly fall apart.

  1. Assess — Build the workload inventory, map dependencies, run a TCO comparison, and define the KPIs that will prove success later. This phase produces the business case that gets your migration funded, not just approved.
  2. Mobilize — Stand up the Cloud Center of Excellence, build the landing zone (networking, identity, security baseline), write the operational runbooks, and train the teams who'll execute waves. Mobilize is also where cost guardrails like tagging standards and budget alerts get enforced, before they're needed rather than after.
  3. Migrate & Modernize — Build the migration factory: repeatable, automated patterns for moving workloads at scale, with validation baked into every wave. Early waves test the factory; later waves scale it.

Each phase de-risks the next. Skip Assess and you migrate blind, discovering critical dependencies mid-cutover. Skip Mobilize and you migrate without guardrails, which is how a six-figure cloud bill surprises a CFO in month two. Following the Azure Cloud Adoption Framework's sequencing logic here saves rework you can't easily undo once workloads are live.

How Do You Choose the Right Migration Strategy Per Workload?

Every workload needs a discovery record before it gets assigned an R. At minimum, capture: business owner, criticality tier, upstream and downstream dependencies, data classification, downtime tolerance, and whether the app sits inside a planned modernization window.

From there, decision rules do most of the work:

  • Low criticality, low complexity, no active development: Retire or Retain.
  • High criticality but stable architecture, tight deadline: Rehost now, revisit later.
  • Entire data center on a lease deadline: Relocate as a bulk move.
  • Commodity function (email, CRM, ticketing) with no custom logic: Repurchase.
  • Moderate complexity, some technical debt, but not mission-critical enough for a rebuild: Replatform.
  • High-value, high-traffic, or scaling-constrained workload: Refactor.

Effort and payoff scale together. Rehosting a mid-size app can be relatively quick with a small team; refactoring the same app into microservices requires a longer timeframe but cuts infrastructure costs and unlocks independent scaling for the long term.

Pro Tip: Score every workload on a simple 1 to 5 grid for "business criticality" against "technical complexity." Anything low on both is your quick win. Anything high on both goes last, after your migration factory has a few waves of practice behind it.

Mapping Dependencies and Planning Migration Waves

Dependency mapping is where discovery tools earn their budget line. Automated discovery scans reveal network traffic patterns, database calls, and API dependencies that no spreadsheet or team interview will fully surface. Cross-reference that technical map against business dependencies too. An app might have zero code dependencies but still can't move independently because finance closes the books through it every month.

Sequencing follows a fairly consistent pattern across successful cloud transition plans:

  1. Migrate non-production environments first. Dev and test workloads carry low risk and let the team rehearse the process.
  2. Move quick wins next. Standalone apps with minimal dependencies build momentum and prove the migration factory works.
  3. Group interdependent systems into a single wave rather than splitting them across separate windows.
  4. Save the most critical, most interconnected systems for last, once the team has multiple successful waves behind it.

Schedule with buffers, not exact dates. A wave planned for a two-week window should carry at least a few days of slack for the inevitable dependency nobody flagged during Assess. And decide downtime tolerance per workload rather than as a blanket policy. A near-zero-downtime approach using continuous replication costs more in tooling and complexity; a scheduled downtime cutover costs more in business disruption. Match the choice to what the business actually tolerates, not to what's technically easiest.

Setting Up Governance: Cost Control and the Cloud Center of Excellence

A CCoE isn't a committee that reviews decisions after they're made. It's a small central team, drawn from security, networking, applications, finance, and business stakeholders, that publishes the blueprints and runbooks every migration squad reuses. Forming it during Mobilize, not after the first wave goes sideways, prevents the siloed decisions that quietly inflate cloud bills.

Security controls belong in the same phase: identity and access management, network segmentation, encryption standards, and compliance checkpoints all need to exist before workloads land, not get retrofitted after.

  • Enforce a tagging standard from wave one, since untagged resources are nearly impossible to cost-attribute later.
  • Set budgets and anomaly alerts per environment, not just at the account level.
  • Review rightsizing on a fixed cadence, monthly at minimum during active migration.
  • Track a small set of KPIs (cost per workload, latency, error rate) against pre-migration baselines.

Pro Tip: Give the CCoE veto power over which team can start a new wave. It's the cheapest guardrail against a team migrating faster than governance can keep up.

Data Migration Methods and the Testing Gates You Can't Skip

Data movement has three broad patterns, and picking the wrong one for the workload is a common source of failed cutovers. Bulk transfer moves a full snapshot at once and works for smaller, less-active datasets. Continuous replication keeps source and target in sync in near real time, which is what makes near-zero-downtime cutovers possible for high-transaction systems. Staged sync sits between the two: periodic batch updates that narrow the final cutover window without the cost of full replication tooling.

Throughput matters more than most teams plan for. A multi-terabyte database moved over a standard internet link can take days; dedicated network links or offline transfer appliances change that math considerably.

Testing can't be an afterthought squeezed into the last week. A workable matrix covers five categories, each with its own sign-off:

  • Smoke tests — Confirm the migrated system starts and responds at all.
  • Functional tests — Verify business logic behaves identically to the source system.
  • Load and performance tests — Confirm the new environment handles real traffic, not just a demo load.
  • Security scans — Catch misconfigurations before they become incidents.
  • DR dry-run — Prove the disaster recovery plan actually works in the new environment, not just on paper.

The 12-step checklist approach that TechTarget outlines treats testing and an exit strategy as equally important, and that pairing is worth taking seriously. Every migration plan needs a repatriation option in case a workload genuinely doesn't belong in the cloud.

Choosing a Cutover Model and Planning Your Rollback

Cutover strategy depends on how much risk the business can absorb during the switch. Blue/green keeps both environments running and flips traffic at once, giving you a near-instant rollback if something breaks. Canary shifts a small percentage of traffic first, which catches problems before they hit everyone. Phased cutover moves user groups or modules over time, spreading risk but extending the exposure window. Big-bang cutover moves everything at once, which is fast but leaves little room for correction.

Whichever model you choose, the runbook needs the same essentials: named roles for every step, exact timing windows, a DNS or IP-switching plan, a communications tree, and a documented fallback.

  • Define rollback triggers before cutover day, not during it (a specific error rate or latency threshold works better than "if something feels wrong").
  • Rehearse the rollback at least once in a non-production environment.
  • Keep the old environment running until the new one clears its validation gates.

Post-Migration Optimization: What to Check and Fix First

The migration isn't finished when the workload boots in the cloud. It's finished when performance, cost, and security all clear their baselines.

Start with verification: compare KPIs against pre-migration numbers, confirm SLAs are actually being met under real traffic, and run a security posture check against the same standards you'd apply to any production system.

Optimization follows immediately, not months later:

  • Rightsize compute within the first two weeks, once real usage patterns are visible.
  • Turn on autoscaling for workloads with variable demand instead of provisioning for peak load year-round.
  • Match storage class to actual access patterns. Infrequently accessed data sitting in premium storage is one of the most common silent cost leaks.
  • Commit to reserved capacity only after usage patterns stabilize, typically after the first full billing cycle.

Well-Architected reviews shouldn't be a one-time event. AWS's own migration framework ties long-term migration success to security, reliability, and cost pillars reviewed on a recurring basis, not just checked off at go-live. Feed lessons from each wave back into the runbooks before the next one starts. That's what actually compounds a migration factory's speed over time. For workloads that still need architectural work after landing, an application modernization strategy is the natural next project.

Inside a 90 to 120 Day Migration Playbook

A well-scoped migration wave, not a full enterprise portfolio, can realistically move from kickoff to stable production inside 90 to 120 days when the migration factory is already built and the wave's dependencies are well understood.

A typical window breaks down roughly like this:

  • Weeks 1 to 3: Discovery, dependency mapping, and the business case sign-off.
  • Weeks 4 to 8: Landing zone build, CCoE governance rules finalized, migration runbooks written.
  • Weeks 9 to 14: Migration execution in waves, with validation gates between each.
  • Weeks 15 to 17: Optimization, KPI verification, and handover to operations.

Success depends on the client side showing up too: a named business owner per workload, IT staff freed from other priorities during the wave, and finance signed off on the cost model before migration starts, not after the first bill lands.

What I'd Prioritize If I Were Sponsoring This

Most migrations don't fail on technology. They fail on communication gaps, dependencies nobody mapped, and cost surprises that hit finance before IT can explain them. If you're sponsoring a migration, prioritize three things in order: a real workload inventory before any vendor conversation, a CCoE before wave one starts, and automation built into the migration factory from the first workload, not retrofitted after wave three.

— YS

How Yslootahtech Turns This Framework Into a Working Migration

Yslootahtech gives IT leaders something most migration guides can't: a team that builds the landing zone, writes the runbooks, and executes the waves, instead of leaving you to translate a framework into working infrastructure alone. Every engagement starts from the same discovery and dependency mapping work covered above, applied to your actual portfolio rather than a generic template.

Yslootahtech
Yslootahtech

If your team is staring at a workload inventory and unsure which R applies to what, or your CCoE exists on paper but nobody's enforcing it, that's the gap Yslootahtech's application development and cloud engineering teams close. For workloads that need a rebuilt front end or a full website development refresh as part of the move, that work runs alongside the migration rather than as a separate project later. Review the full migration process guide for a deeper walkthrough, or schedule a discovery call to map your first migration wave.

Sources

Recommended

Back to all articles

© 2026 جميع الحقوق محفوظة

Footer Logo