Cloud Migration
Cloud migration without the post-mortem.
Cloud migration done right is a three-phase program with disciplined assessment, wave-based execution, and FinOps operating from day one. Done wrong, it's the kind of project that shows up in quarterly earnings call apologies. This page documents the pattern we use on real engagements.
Why most cloud migrations cost more than they should
The migration projects that end up as case studies of what not to do share three characteristics. First, they start with execution before assessment. Teams pick a cloud provider before they understand what needs to move, then spend the next 18 months discovering workloads that don't fit the chosen architecture. Second, they treat migration as a lift-and-shift exercise across the whole portfolio. Some workloads really should move as-is; most benefit from at least replatforming; a few need refactoring and a few should never move at all. The decision has to be made workload by workload. Third, they defer FinOps thinking until after the bill arrives. By then the architectural decisions that drove the bill are already baked in.
We start every migration with assessment because the assessment is what makes the rest of the program safe. The reference frameworks we work from are the AWS Well-Architected Framework, Microsoft Azure Cloud Adoption Framework, and Google Cloud Architecture Framework. Every engineer on our cloud practice holds at least one hyperscaler certification, most hold two or three.
The 6 R's: what to do with each workload
Gartner's 6 R's framework has become the industry-standard vocabulary for migration disposition decisions. Every workload in scope gets categorized into one of the six based on business value, technical fit, regulatory constraints, and cost. This decision happens during the assessment phase and sequences the rest of the program.
Retain
Keep the workload on-premises or in its current environment. Some workloads never belong in public cloud: specific regulatory constraints, hard-real-time requirements, or legacy dependencies that would cost more to untangle than to leave alone.
Retire
Decommission. A meaningful share of enterprise workloads in any migration project turn out to have zero business consumers once you look. Retiring them is cheaper than migrating them and simplifies the rest of the program.
Rehost
Lift and shift with minimal changes. Appropriate for workloads that need to move quickly (data center exit deadline, M&A integration) where the cloud target can accommodate the existing architecture without extensive redesign.
Replatform
Lift with targeted changes to benefit from cloud-native services. Example: moving a database onto a managed service (RDS, Cloud SQL, Azure SQL) without rewriting the application. Common sweet spot for mid-market migrations.
Repurchase
Replace with a SaaS alternative. The on-premises email server becomes Microsoft 365. The self-hosted CRM becomes Salesforce. The in-house HR system becomes Workday. Eliminates the operational burden entirely for that workload.
Refactor
Rearchitect for cloud-native patterns. Break the monolith into services, adopt managed data services, redesign for scale and resilience. Highest value but highest cost. Usually reserved for workloads where the business case is strong.
Landing zone design: the foundation that has to be right
The landing zone is the cloud environment your workloads land in. Getting it right on the first pass is the difference between a clean migration and 18 months of rework. The landing zone covers account and subscription structure, identity and access, network design, security baseline controls, logging and monitoring, and the CI/CD patterns that will deploy everything that follows.
For AWS, the reference is AWS Control Tower with the Landing Zone Accelerator. For Azure, it's the Azure Landing Zones reference architecture, typically the enterprise-scale variant. For GCP, it's the Google Cloud security foundations blueprint combined with Cloud Foundation Fabric. In all three cases, we implement infrastructure-as-code from the start so the landing zone is reproducible, auditable, and can evolve through pull requests rather than console clicks.
The three-phase migration model
Every migration we run follows a three-phase structure with documented exit criteria between phases. This is the pattern that delivers predictable outcomes on mid-market migrations.
Phase 1 — Assessment & Design (4-8 weeks)
- Full application inventory and dependency mapping
- Workload-by-workload disposition decision (one of the 6 R's)
- Target cloud selection (AWS, Azure, GCP, or multi-cloud architecture)
- Landing zone design: accounts/subscriptions, networking, identity, security baseline
- Migration sequencing: wave planning with rollback paths
- Business case and TCO model with 1, 3, and 5 year views
- Compliance and data residency verification
Phase 2 — Execution (3-12 months depending on scope)
- Landing zone buildout and baseline controls
- Wave-based migration of workloads per the sequencing plan
- Dual-run validation for each workload before cutover
- Data migration with verified integrity at source and target
- Integration reconnection and end-to-end testing
- Cutover with documented rollback criteria and tested rollback path
- Post-cutover stabilization and incident response readiness
Phase 3 — Optimization & Operate (ongoing)
- FinOps discipline: right-sizing, reserved capacity, waste elimination
- Architecture review quarterly against the cloud provider Well-Architected frameworks
- Continuous security posture management (CSPM)
- Disaster recovery testing on a defined cadence
- Cost anomaly detection and alerting
- Operational handoff to the managed services team (or retained client team)
- Quarterly business reviews with documented outcomes
FinOps from day one
Cloud waste compounds. An over-provisioned instance costs 2x of a right-sized one every hour of its life. An orphaned EBS volume costs every day no one deletes it. An idle load balancer costs whether or not a single request goes through. The compounding runs both directions: small architectural decisions made during migration either enable or preclude the efficiency you'll want in year two.
The FinOps Foundation Framework defines the discipline of running cloud with business-aware cost management. We implement three FinOps-aligned practices during migration. First, tag-based cost allocation from day one, so finance can see which team or project drives which line item. Second, reserved capacity planning for workloads with stable baseline, typically committing to 40-60% of steady-state usage on 1-year reserved instances or equivalents. Third, automated cost anomaly detection alerting on unexpected spend shifts before the monthly bill arrives. Most clients see 20-35% cloud bill reduction in year one with active FinOps discipline, with the compounding benefit over years two and three.
Security and compliance during migration
Compliance requirements travel with the data. Moving regulated workloads to cloud doesn't relax HIPAA, PCI-DSS, SOC 2, ISO 27001, or CMMC obligations. What changes is the control implementation. The assessment phase validates that the target cloud provides the equivalent controls the compliance regime requires, identifies gaps, and designs the compensating controls into the landing zone before any regulated workload moves.
The security practice that's non-negotiable during migration is Cloud Security Posture Management. Every account and subscription gets CSPM coverage from day one so configuration drift, public exposure of sensitive resources, and policy violations are caught before they become incidents. This pairs naturally with our Zero Trust Architecture approach: identity-first access, microsegmentation in the cloud fabric, and continuous validation against the NIST SP 800-207 tenets. For regulated industry specifics, see our healthcare, financial services, and manufacturing pages.
Disaster recovery and business continuity
One of the underappreciated benefits of cloud migration is how much easier disaster recovery becomes. On-premises DR typically involves a secondary data center, replication licensing, annual failover testing that terrifies everyone, and recovery point objectives that are more aspirational than tested. Cloud DR can deliver better RPO and RTO at lower cost, with testing that actually runs on a documented cadence.
The patterns we implement depend on the tier of workload. Tier 1 workloads (revenue-critical, regulated, customer-facing) typically run active-active across availability zones with cross-region replication for regional failover. Tier 2 workloads run pilot-light architectures with automated failover. Tier 3 workloads use backup-and-restore patterns with documented recovery procedures. Every tier gets quarterly tested DR validation, not annually, because an untested DR plan is a wish rather than a plan.
Post-migration operations
Migration ends the day the last workload cuts over. The real work is the 3-5 years of operation after that. We operate migrated environments for clients who want a managed model and hand off to internal teams for clients who want to retain operations. Either way, we document the operational model, the runbooks, the escalation paths, and the quarterly review cadence during the migration itself so there's no "now what" moment after cutover.
Our managed IT services layer covers ongoing cloud operations with 24/7 monitoring, patch management, backup verification, change control, and cost optimization. For security operations, our managed detection and response and SOC as a service run in the cloud environments we build, often as the natural extension of a migration engagement.
Related reading
- Cloud migration playbook (blog) — expanded step-by-step execution detail.
- Managed IT services — the operational layer that runs migrated environments.
- Zero Trust architecture — the security model we apply in cloud landing zones.
- Healthcare HIPAA cloud migration case study — a regulated migration engagement end-to-end.
Frequently asked questions
How long does a typical mid-market cloud migration take?
For a 50-200 workload enterprise, the realistic end-to-end timeline is 9-18 months. Assessment and design takes 4-8 weeks. Execution takes 6-14 months depending on wave count, change-freeze windows, and application complexity. Workloads on the 'rehost' path move fastest; 'refactor' workloads are the long tail of any program.
How do we decide between AWS, Azure, and GCP?
The decision is rarely a single cloud. For most mid-market organizations, the answer is a primary cloud aligned to existing investment (Microsoft shops usually land on Azure, Google Workspace shops often on GCP, pure AWS shops often stay on AWS), with a secondary cloud used for specific workloads. Multi-cloud is real but adds operational complexity, so we recommend it only when specific workloads justify the cost.
What's the biggest mistake we see in cloud migrations?
Skipping assessment. Migration projects that start with 'we'll figure it out as we go' produce the cost overruns, extended timelines, and data loss incidents you read about in post-mortems. A properly conducted assessment with real dependency mapping is 6-8 weeks of work that saves 6-12 months on the overall program.
How much does cloud migration typically cost?
For a mid-market enterprise (50-200 workloads), migration professional services land in the $300K-$1.5M range depending on scope, the mix of 6 R's disposition decisions, and how much refactoring is included. Ongoing cloud run cost is separate and depends on the architecture choices made during migration. A well-executed migration typically pays back the professional services cost in 18-30 months via data center exit and right-sized cloud operations.
Can we migrate without downtime?
For most workloads, yes. The pattern is dual-run: the workload runs in both environments simultaneously during the transition, traffic is gradually shifted to the new environment, and the old environment is retired only after sustained clean operation on the new one. Some workloads (certain databases, tightly coupled integrations) require planned cutover windows, but those are the exception rather than the rule.
How does compliance work during migration?
Compliance requirements travel with the data. HIPAA, PCI-DSS, SOC 2, ISO 27001, and CMMC all have cloud-equivalent controls that have to be in place before regulated workloads move. The assessment phase validates that the target cloud can meet the compliance requirements, identifies gaps, and designs the controls into the landing zone baseline. See our industry pages for specific compliance mappings.