πŸ“– The Beginner's Guide to Enterprise Cloud Migration

Table of contents

🧭 The four phases

What: Every large migration moves through Discovery (what do we have?), Planning (what do we do with each thing?), Execution (move it) and Operations (run it in the cloud). The Cloud Architect coordinates Business Systems Analysts (BSAs β€” people who translate between business needs and IT), developers, QA (Quality Assurance testers), Ops (operations/infrastructure engineers), network teams and executives.

Why & when

Skipping Discovery means migrating servers nobody uses. Skipping Planning means paying refactor prices for lift-and-shift value. Skipping Operations planning means a successful cutover followed by a chaotic Monday. Use the phases as gates: do not start the next until the previous has a signed output.

How:

  1. Discovery: inventory servers (CMDB = Configuration Management Database, the list of all IT assets), collect 30–90 days of utilisation, map dependencies.
  2. Planning: build the business case, classify by the 6 Rs, size the team, build the landing zone design.
  3. Execution: landing zone β†’ pilot β†’ waves of replication and cutover.
  4. Operations: hypercare, cost optimisation, security posture, decommission.

Analogy: Moving house. First you inventory what you own (Discovery), decide what to keep/sell/bin (Planning), hire the truck and move on a date (Execution), then unpack and change your address everywhere (Operations).

πŸ’° Business case & TCO

What: TCO (Total Cost of Ownership) adds up every cost of running servers over several years. On-prem is mostly CapEx (Capital Expenditure β€” buying hardware up front, plus cooling, power, real estate). Cloud is OpEx (Operating Expenditure β€” pay-as-you-go per hour). The business case compares them and asks the CFO (Chief Financial Officer) for money.

Why & when

Nothing moves without funding. Build the case at T-12 to T-9 months. The CFO will probe assumptions, so document them. The single biggest lever is not migrating waste: β€œzombie” servers (β‰ˆ0% CPU for 90 days) should be retired, not rented in the cloud.

How:

  1. Export the CMDB and 90-day CPU/memory telemetry.
  2. Flag zombies (<1% CPU) and end-of-life (EOL) systems for retirement.
  3. Model 5 years: on-prem refresh spikes vs cloud hourly Γ— (1 βˆ’ reserved discount).
  4. Add dual-running costs, egress, licensing, training.
  5. Write assumptions explicitly; present savings % against the company's hurdle rate.

Analogy: Comparing owning a car (buy it, insure it, garage it, replace it in 5 years) with a ride-share subscription β€” and first noticing you own three cars you never drive.

Try the TCO simulator β†’

πŸ—‚οΈ The 6 Rs

What: Six strategies for each application. Rehost (Lift & Shift: copy the VM as-is using AWS Application Migration Service β€” MGN β€” or Azure Migrate). Replatform (Lift, Tinker & Shift: small change for big benefit, e.g., Oracle on a VM β†’ Amazon RDS or Azure SQL managed database). Refactor (re-architect, e.g., monolith β†’ Kubernetes microservices). Repurchase (Drop & Shop: replace with SaaS such as Microsoft 365). Retire (switch off). Retain (keep on-prem for now β€” mainframe, latency, compliance).

Why & when

Large migrations start mostly Rehost because the data-centre exit date is fixed and Rehost is 10–15Γ— cheaper per server than Refactor. Modernise after landing, where compute is elastic and experiments cost pennies. Classify at T-9 to T-6 months using two axes: technical debt and business value.

How:

  1. Plot each app: debt (old OS, unsupported DB, no tests) vs value (revenue, users).
  2. Low debt β†’ Rehost. Managed equivalent exists β†’ Replatform. High value + high change rate β†’ Refactor (few!). Commodity β†’ Repurchase. Unused β†’ Retire. Anchored β†’ Retain.
  3. Sum cost and effort; check against budget and deadline; iterate.

Analogy: Moving house again: most boxes go in the truck unchanged (Rehost), the old fridge is replaced by the landlord's (Replatform), the kitchen gets remodelled after you move in (Refactor), you subscribe to a streaming service instead of moving the DVD shelf (Repurchase), half the garage goes to the tip (Retire), and the piano stays with your parents for now (Retain).

Try the 6 Rs board β†’

🚚 Moving petabytes

What: A petabyte (PB) is 1,024 terabytes. Moving 5 PB over a 10 Gbps (gigabits per second) private link β€” AWS Direct Connect or Azure ExpressRoute β€” takes 50+ days at realistic utilisation. Alternatively ship physical appliances: AWS Snowmobile (a 100 PB truck) or several Azure Data Box Heavy units (β‰ˆ1 PB each).

Why & when

Physics: 10 Gbps β‰ˆ 75 TB/day at 70% utilisation β†’ 5 PB β‰ˆ 68 days. Use the truck for bulk/historic data and the wire for the continuously changing delta. Decide at T-6 months because appliances have lead times.

How:

  1. Compute days = (PB Γ— 1024 TB) Γ· TB-per-day; compare with the deadline.
  2. If too slow, order appliances; book the loading dock; plan the 3-day local copy.
  3. Ship with chain of custody; ingest in the cloud; verify checksums; wipe devices.
  4. Run incremental sync over the wire until cutover.

Analogy: Emailing 5,000 photos one at a time versus posting a hard drive.

Try the transfer simulator β†’

πŸ”€ Cutover weekend

What: Cutover is the moment users switch from old to new. Developers update CI/CD (Continuous Integration/Continuous Delivery) pipelines and change database connection strings from IPs to cloud DNS names. Ops run Terraform IaC (Infrastructure as Code) and the final delta sync. QA run data-integrity, smoke and load tests. Network Ops flip the DNS GTM (Global Traffic Manager) CNAME record so the website name points at the cloud.

Why & when

Sequencing matters: data must be consistent before DNS moves. Named go/no-go gates (Friday CAB approval, Saturday QA sign-off) make rollback a planned decision. Schedule in the lowest-traffic window the business accepts.

How:

  1. Fri 18:00 Go/No-Go #1; 20:00 stop traffic.
  2. Dev: pipelines + connection strings. Ops: terraform apply; Sat 02:00 final delta.
  3. QA: row counts/checksums, smoke, load (p95 ≀ 300 ms).
  4. Sat 09:30 Go/No-Go #2 β†’ 10:00 DNS switch (TTL 60 s).
  5. Sun 12:00 business sign-off β†’ hypercare.

Analogy: Changing planes mid-flight β€” you prepare everything, then switch in one coordinated moment with a parachute (rollback) ready.

Run Migration Weekend β†’

πŸ›’ Globex case study

What: A fictional e-commerce company with a Java monolith on 40 VMware hosts, a lease ending in 18 months and $2M/hour outage cost. The story follows BSAs finding hidden dependencies, developers containerising, QA baselining and Ops implementing CSPM (Cloud Security Posture Management β€” tools that continuously check cloud configuration for risks).

Why & when

Case studies make abstract rules concrete. Read it before planning your own waves; every pitfall in the story is one you will meet.

How: Scroll the page; each chapter animates; click components for detail.

Analogy: A documentary about one family's house move rather than a moving-company brochure.

Read the story β†’

🧱 IaaS, PaaS, SaaS & hypervisors

What: A hypervisor (VMware ESXi, Microsoft Hyper-V, AWS Nitro) is software that splits one physical server into many virtual machines (VMs). IaaS (Infrastructure as a Service) rents you VMs β€” you manage the operating system. PaaS (Platform as a Service) rents you a managed database or runtime β€” the provider patches OS and engine. SaaS (Software as a Service) rents you the finished application β€” you manage identity and data policy only.

Why & when

Each step up removes toil but reduces control. IaaS for wave-1 speed; PaaS where a managed equivalent exists; SaaS for commodity. The β€œshared responsibility model” defines who secures what β€” misunderstanding it causes breaches.

How:

  1. ESXi/Hyper-V β†’ EC2/Azure VM via block-level replication (MGN/Azure Migrate).
  2. Oracle RAC β†’ RDS/Azure SQL via DMS (Database Migration Service) + schema conversion.
  3. Exchange β†’ Microsoft 365 via hybrid mailbox moves; retire the farm.

Analogy: Owning a house (on-prem), renting an apartment (IaaS), staying in a serviced apartment (PaaS), booking a hotel (SaaS).

Try the whiteboard β†’

πŸ‘₯ The 25-person team

What: A Migration Center of Excellence (MCoE) β€” a core team that owns patterns, tooling and delivery. 2 Enterprise Cloud Architects (landing zone, IAM β€” Identity and Access Management β€” guardrails, Transit Gateway routing), 3 PMs/Scrum Masters (T-minus plan, stand-ups, CAB β€” Change Advisory Board), 8 Migration Engineers (agents, sync, Terraform/Bicep), 4 BSAs (dependencies, owners, outage windows), 4 QA/Automation (integrity, load, connectivity), 4 Day-2 SREs (Site Reliability Engineers β€” post-cutover operations).

Why & when

Throughput is set by migration engineers; quality by QA ratio; Day-2 stability by SREs. Mobilise after CFO approval; rebalance as waves finish.

How: Size engineers from servers Γ· months Γ· ~35 servers per engineer-month; keep QA at 1 per 2–3 engineers; never go below 1 architect or 2 SREs.

Analogy: A film crew β€” a few directors, many camera operators, and someone must own post-production or the film never ships.

Allocate the team β†’

πŸ›οΈ SteerCo & governance

What: The Executive Steering Committee (SteerCo) of CIO (Chief Information Officer), CFO and CISO (Chief Information Security Officer) makes go/no-go decisions, accepts risk and releases budget. The CISO needs on-prem firewall rules (Palo Alto, Cisco) translated into cloud NSGs (Network Security Groups) and a WAF (Web Application Firewall). The CIO needs a burn-down chart (servers remaining vs time). The CFO needs spend vs progress.

Why & when

Executives decide in their own language: risk, time, money. Meet monthly plus before each major wave. Risk acceptance is legitimate if written, owned and time-bound.

How: Present security parity β†’ schedule β†’ spend; record decisions and actions; escalate through workstream lead β†’ PMO β†’ SteerCo β†’ Board.

Analogy: A planning committee for a building: the safety inspector, the schedule manager and the treasurer all have a veto.

Convene SteerCo β†’

⏱️ T-minus timeline

What: A countdown plan from T-12 months (Discovery with Movere/Cloudamize), T-6 (landing zone + 50-server pilot), T-4 weeks (replication starts), T-0 (48-hour cutover: Fri 8 PM stop traffic, Sat 2 AM delta, Sat 10 AM DNS, Sun 12 PM sign-off), T+1 to T+14 days (hypercare war room).

Why & when

Working backwards from a fixed date exposes dependencies and lead times. Publish at T-9 months; re-baseline after the pilot.

How: Fix T-0 per wave; lay out predecessor tasks; add a dress rehearsal at T-1 week; keep a 2-week hypercare buffer.

Analogy: A rocket launch countdown β€” every team has a call-out at a fixed T-minus time.

Scrub the timeline β†’

πŸ“Š Comparison tables

The 6 Rs compared

StrategyChange to appCost / serverSpeedRiskExample
RehostNone$FastestLowESXi VM β†’ EC2 via MGN
ReplatformSmall$$FastMediumOracle VM β†’ RDS
RefactorLarge$$$$SlowHighMonolith β†’ EKS microservices
RepurchaseReplace$MediumLowExchange β†’ M365
RetireRemoveΒ’FastestLowZombie servers
RetainNone0N/ALowMainframe

Wire vs truck for 5 PB

MethodCapacityTime for 5 PBBest forWatch out
10 Gbps Direct Connect / ExpressRouteβ‰ˆ75 TB/day @70%β‰ˆ68 daysDeltas, live replicationProvisioning lead time; shared bandwidth
AWS Snowmobile100 PB per truckβ‰ˆ18 daysMassive archivesSite survey, power, escort
Azure Data Box Heavy Γ—51 PB eachβ‰ˆ18 daysMulti-PB bulkDock booking, 40 GbE ports

Shared responsibility

You manage…On-premIaaSPaaSSaaS
Hardware & hypervisorβœ”β€”β€”β€”
Guest OSβœ”βœ”β€”β€”
Middleware / DB engineβœ”βœ”β€”β€”
Applicationβœ”βœ”βœ”β€”
Identity & dataβœ”βœ”βœ”βœ”

πŸ§ͺ Interactive explorer

Click a concept chip. The flow diagram and step list rebuild for that concept and animate.

Pick a chip above.

    🎯 Decision guide

    If you remember nothing else

    • Is there a fixed exit date? β†’ Rehost the majority; modernise after landing.
    • Is the data > 1 PB and the deadline < 90 days? β†’ Truck for bulk, wire for delta.
    • Does a managed equivalent exist (RDS, Azure SQL)? β†’ Replatform the database.
    • Is it commodity (mail, HR, CRM)? β†’ Repurchase as SaaS.
    • Has nobody logged in for 90 days? β†’ Retire.
    • Has the CISO seen the NSG/WAF design? β†’ If not, you are not ready to cut over.
    • Is QA < 98% or p95 > 300 ms at Saturday 09:30? β†’ Rollback. Try again next weekend.

    πŸ”€ Glossary

    BSA

    Business Systems Analyst β€” bridges business and IT; maps dependencies and owners.

    CMDB

    Configuration Management Database β€” inventory of servers, apps and relationships.

    CapEx / OpEx

    Capital vs operating expenditure β€” buy up front vs pay as you go.

    TCO

    Total Cost of Ownership β€” all costs over the asset's life.

    MGN / Azure Migrate

    AWS Application Migration Service / Azure's migration suite β€” block-level VM replication tools.

    Landing zone

    Pre-built cloud foundation: accounts, networks (VPC/VNet), IAM guardrails, logging.

    Hub-and-spoke

    Network design: a central hub VPC/VNet for shared services connected to many spoke networks via Transit Gateway / vWAN.

    NSG / WAF

    Network Security Group (cloud firewall rules) / Web Application Firewall (blocks web attacks).

    CSPM

    Cloud Security Posture Management β€” continuous misconfiguration scanning.

    CAB

    Change Advisory Board β€” approves production changes.

    GTM / CNAME / TTL

    Global Traffic Manager; a DNS alias record; Time To Live β€” how long DNS answers are cached.

    Hypercare

    Intensive post-cutover support period (here 14 days) with a 24/7 war room.

    IaC

    Infrastructure as Code β€” Terraform/Bicep files that create cloud resources repeatably.

    p95 latency

    The response time that 95% of requests beat β€” a standard performance gate.

    SRE

    Site Reliability Engineer β€” runs and improves production systems.

    Strangler pattern

    Gradually replace a monolith by routing one capability at a time to new services.