The decision to migrate workloads from on-premises data centres to a hybrid cloud model is one of the most consequential infrastructure decisions an enterprise can make. Done strategically, it unlocks elastic scale, reduces operational burden, and gives engineering teams access to managed services that would take years to build in-house. Done poorly, it produces unexpected cloud bills, degraded performance, and a tangle of partially-migrated systems that are harder to operate than what existed before.
This framework — developed through hundreds of enterprise migrations — gives you a structured, repeatable approach to on-premises to cloud migration that minimises risk while maximising speed.
Phase 1: Discover and Assess
You cannot migrate what you do not understand. The discovery phase builds a comprehensive inventory of your current estate and classifies every workload against a set of migration criteria.
Application Portfolio Analysis
For each application, capture:
- Architecture: Monolith, microservices, client-server, mainframe
- Dependencies: Databases, message queues, shared file systems, third-party APIs
- Data classification: Public, internal, confidential, regulated (PII, PHI, PCI)
- Performance profile: CPU/memory utilisation, storage IOPS, network throughput
- Availability requirements: RTO/RPO, SLA, business criticality
- Licence constraints: Vendor licence portability to cloud
- Team ownership: Who is accountable for this workload
The 7 Rs Migration Framework
Classify each workload using the industry-standard 7 Rs:
- Retire: Decommission applications no longer needed
- Retain: Keep on-premises — compliance, latency, or dependency constraints
- Rehost (Lift & Shift): Move to cloud VMs with no code changes
- Replatform (Lift & Reshape): Minor optimisations — move to managed database, containerise
- Repurchase (Drop & Shop): Replace with a SaaS alternative
- Refactor / Re-architect: Redesign for cloud-native patterns (microservices, serverless)
- Relocate: Move entire VMware environments using VMware HCX or similar
Phase 2: Design the Landing Zone
A cloud landing zone is a pre-configured, secure, multi-account environment that provides the foundation for all migrated workloads. It must be built before you migrate a single workload. Key components:
- Account/subscription structure: Separate accounts per environment (prod, staging, dev) and per business unit to contain blast radius and enforce cost boundaries
- Network topology: Hub-and-spoke with a transit gateway or Virtual WAN. Dedicated subnets for workloads, management, and DMZ. VPN or Direct Connect to on-premises
- Identity federation: SSO from on-premises Active Directory to cloud IAM. Role-based access with least privilege enforced by policy
- Security baseline: Cloud security posture management (CSPM), centralised logging (CloudTrail/Azure Monitor), threat detection (GuardDuty/Defender), and encryption at rest and in transit enabled by default
- Cost governance: Tagging policy enforced by policy-as-code. Budget alerts at account and team level
Phase 3: Establish Connectivity
Hybrid cloud requires reliable, low-latency connectivity between on-premises and cloud. Options in order of preference:
- Dedicated interconnect (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect) — highest bandwidth, lowest latency, predictable performance, not subject to internet congestion. Recommended for production workloads
- SD-WAN overlay — aggregates multiple internet or MPLS links with traffic shaping and failover. Lower cost than dedicated lines for lower-bandwidth requirements
- Site-to-site VPN — encrypted tunnel over the internet. Lowest cost, highest latency variability. Suitable for dev/test or as a backup to dedicated interconnect
Always implement redundant connectivity paths. A single link outage should never prevent on-premises systems from reaching cloud-hosted dependencies.
Phase 4: Migrate in Waves
Never migrate everything at once. Organise workloads into migration waves ordered by risk and value:
- Wave 0 — Non-critical experiments: Migrate dev/test environments first. Build cloud operations muscle with zero business risk
- Wave 1 — Low-complexity, low-criticality: Simple applications with few dependencies. Build confidence and refine the migration runbook
- Wave 2 — Medium complexity: Applications requiring replatforming. May involve database migration, containerisation, or managed service adoption
- Wave 3 — Business-critical: Core systems. By now, the team has migrated dozens of workloads and the process is well understood
- Wave 4 — Regulated and legacy: Workloads requiring special handling — mainframes, vendor-locked databases, heavily regulated data
Migration Tooling
- AWS MGN / Azure Migrate: Agent-based continuous replication for lift-and-shift migrations
- CloudEndure / Carbonite: Block-level replication for near-zero-downtime cutovers
- AWS DMS / Azure DMS: Database migration with minimal downtime using change data capture
- Velero: Kubernetes workload backup and migration between clusters
Phase 5: Validate and Cut Over
For each workload migration:
- Run parallel operation — old and new environments serving traffic simultaneously
- Compare outputs: database query results, API responses, report outputs must be identical
- Load test the cloud environment at 150 % of expected peak
- Execute the cutover during a low-traffic window
- Maintain rollback capability for a minimum of 72 hours post-cutover
- Decommission on-premises resources only after two weeks of stable cloud operation
Phase 6: Optimise Post-Migration
Migration is not the finish line — it is the starting point for continuous optimisation:
- Rightsizing: Cloud workloads often start over-provisioned. Review CPU and memory utilisation weekly for the first month and downsize accordingly
- Reserved capacity: Purchase Reserved Instances or Savings Plans for steady-state workloads to save 30–60 % versus on-demand pricing
- Managed services adoption: Replace self-managed databases, queues, and caches with cloud-managed equivalents to reduce operational overhead
- FinOps practice: Assign cloud costs to teams. Hold monthly cloud spend reviews. Eliminate idle resources automatically
Frequently Asked Questions
How do I decide which workloads to migrate to cloud first?
Prioritise workloads using the 7 Rs framework. Start with non-critical development and test environments to build operational confidence. Then progress to low-complexity production workloads before tackling business-critical or regulated systems. Avoid migrating tightly-coupled legacy applications early — these typically require refactoring and should come in later waves.
What is lift and shift cloud migration?
Lift and shift (also called Rehost) moves an application from on-premises to cloud virtual machines with no changes to the application code or architecture. It is the fastest migration pattern and is appropriate for applications that are too complex to refactor immediately but need to be off on-premises hardware. The trade-off is that lift-and-shift workloads do not benefit from cloud-native features like auto-scaling and managed services.
How do you estimate the cost of a cloud migration?
Cloud migration costs include: migration tooling and services, connectivity (Direct Connect or ExpressRoute), team training, potential application refactoring, and the ongoing cloud run cost. Use cloud pricing calculators to estimate run cost. For the migration itself, budget 1–3x the first year’s cloud run cost as a one-time migration investment. The payback period is typically 18–36 months.
What is a cloud landing zone and why do I need one?
A cloud landing zone is a pre-configured, secure, multi-account cloud environment that provides the networking, identity, security, and governance foundations for all migrated workloads. Building it before you migrate ensures that every workload lands in a consistent, compliant environment rather than accumulating technical debt from ad-hoc account configurations.
How long does an enterprise cloud migration take?
A complete enterprise migration — from initial assessment to final on-premises decommissioning — typically takes 18–36 months depending on estate size and complexity. A focused migration of 10–20 applications can complete in 3–6 months. Organisations that try to rush migration without proper assessment and landing zone design consistently overspend and experience more incidents.
Can we keep some workloads on-premises permanently?
Absolutely — and for many organisations this is the right answer. Workloads that are latency-sensitive, subject to strict data sovereignty requirements, economically better on owned hardware (high-utilisation, steady-state), or deeply tied to physical infrastructure (IoT, manufacturing systems, laboratory equipment) should remain on-premises. A well-designed hybrid cloud architecture accommodates these workloads alongside cloud-hosted ones.
Conclusion
A successful on-premises to hybrid cloud migration is 20 % technology and 80 % process, governance, and people. Organisations that invest in proper discovery, build a solid landing zone, and migrate in disciplined waves consistently deliver better outcomes — faster timelines, lower costs, and fewer incidents than those that try to move fast without a framework.
OpsNexus provides end-to-end migration services from initial assessment through to post-migration optimisation. Contact us to discuss your migration roadmap.
