The Problem

Lift-and-shift is not a migration strategy

Most hybrid migrations fail quietly — not with an outage, but with a project that stalls at 60% because connectivity, identity, or data sync was never designed, only assumed.

01

Lift-and-shift failures

Moving VMs as-is without re-architecting hits performance and cost walls the moment real load arrives — cloud isn't a faster data center.

02

Connectivity as an afterthought

A VPN bolted on after migration planning becomes the bottleneck and single point of failure for every hybrid workload.

03

Identity silos

On-prem Active Directory and cloud IAM living separately means two logins, two audit trails, and a cleanup project nobody scheduled.

04

Data gravity

Large datasets can't move overnight. Without a sync strategy, migration stalls waiting for a copy job that was never going to finish in the maintenance window.

The Blueprint

A three-tier bridge between on-prem and cloud

On-premises, connectivity and landing zone, and public cloud are kept as distinct tiers — so the migration path is explicit at every wave, not improvised.

FIG. 01 — HYBRID-MIGRATION-REV2 SCHEMATIC 3-TIER / WAVE-BASED CUTOVER MODEL
TIER 1 — ON-PREMISES EXISTING ESTATE VMware / Physical Servers Core Apps & Databases IDENTITY & NETWORK Local Active Directory / DNS On-Prem Firewall / LAN DATA & BACKUP Backup Infrastructure Primary Data Stores TIER 2 — CONNECTIVITY & LANDING ZONE DEDICATED LINK Direct Connect / ExpressRoute Site-to-Site VPN (backup path) LANDING ZONE Accounts / Subscriptions Guardrails & Network Design IDENTITY FEDERATION Azure AD Connect / ADFS AWS IAM Identity Center TIER 3 — PUBLIC CLOUD MIGRATED WORKLOADS Rehosted / Replatformed Apps Cloud-Native Services DATA LAYER Managed Databases Object / Block Storage MIGRATION TOOLING CloudEndure / Azure Migrate Replication Agents MIGRATION WAVE FLOW — ON-PREM TO CLOUD CUTOVER On-Prem App Replication Agent Landing Zone (Staged Env) Validation & Test Cutover (DNS / LB) Identity Federation Rollback Path Identity is federated before the first workload moves; the on-prem environment stays live as a rollback path until each wave is validated in production. CONNECTIVITY & RESILIENCE Redundant Dedicated Links · BGP Failover to VPN · Private Endpoints · Split-Horizon DNS · Encrypted Transit MIGRATION REF: Wave Planning (5 Rs) · Dependency Mapping · CMDB Sync · Cost Modeling · Cutover Runbooks
Sync data traffic (gRPC / HTTP)
Async traffic (events / streaming)
Management / control plane
Tier boundary
Design Decisions

Six decisions that make or break a hybrid migration

In order — the sequence architects actually work through when planning this.

01

Classify every workload before you move it

Rehost, replatform, refactor, retire, or retain — the 5 Rs. Moving a workload without deciding which applies is how lift-and-shift turns into a stalled project.

02

Build connectivity before migration starts

With a redundant path — Direct Connect or ExpressRoute as primary, VPN as failover. A single link is not a migration foundation.

03

Federate identity first

One login across on-prem and cloud before any workload moves — not a cleanup project scheduled for after go-live.

04

Migrate in waves, not a big bang

Start with low-risk, stateless workloads to prove the pattern, then move toward stateful, dependency-heavy systems.

05

Plan data sync direction and cutover window explicitly

Asynchronous replication until the final cutover, then a defined, tested switchover — not an open-ended copy job.

06

Keep a rollback path for every wave

Until it's validated in production. The on-prem environment stays live as insurance, not decommissioned on day one.

Reference Stack

Technology choices by tier

Illustrative — final selection depends on existing platform investments, team skillset, and cloud vs. on-prem constraints.

Tier 1 — On-Premises
VMware vSphere
Windows / Linux Servers
Active Directory
Veeam / Commvault
Tier 2 — Connectivity
Direct Connect / ExpressRoute
Site-to-Site VPN
Landing Zone (Terraform)
Azure AD Connect / IAM Identity Center
Tier 3 — Public Cloud
EC2 / Azure VM / Compute Engine
RDS / Azure SQL
S3 / Blob Storage
CloudEndure / Azure Migrate
Foundation Services
CloudWatch / Azure Monitor
Cost Management
CMDB
Change Management
What This Is Designed to Deliver

Engineering targets, not marketing claims

We haven't published a client case study for this pattern yet — these are the outcomes this architecture is engineered to hit, based on established infrastructure practice.

A note on the numbers below: these are industry-recognized engineering benchmarks for well-architected systems of this kind, not results from a specific Vakratron deployment. We'll publish real project data as engagements complete.
Wave-Based
Phased migration reduces cutover risk vs. a single big-bang event
Redundant
Dual-path connectivity removes the single point of failure for hybrid traffic
Day-One
Federated identity — one login from the start, no post-migration cleanup project
Validated
Data sync tested before cutover — a defined migration window, not an open-ended copy
FAQ

Common questions from platform teams

Rehost vs. replatform vs. refactor — how do we decide?
By workload criticality, technical debt, and business timeline. Rehost buys speed for low-risk workloads; refactor pays off for systems that will run in the cloud for years. We map every workload against this before planning waves.
Do we need Direct Connect / ExpressRoute, or is VPN enough to start?
VPN can carry an initial wave of low-bandwidth workloads. Once production traffic or bulk data replication is involved, a dedicated link becomes necessary for both throughput and reliability.
How long does a typical hybrid migration take?
Highly dependent on workload count and complexity — a mid-sized estate (100–300 VMs) typically runs 4–9 months across assessment, connectivity setup, and wave-based migration.
What happens to workloads we can't move (retain)?
They stay on-prem with the same identity federation and monitoring extended to them, so they're managed as part of the same hybrid environment, not an orphaned legacy island.
How do you handle the network cutover moment itself?
Through a tested runbook — DNS TTLs lowered in advance, traffic shifted via load balancer or DNS cutover, with the on-prem path kept warm as immediate rollback for a defined validation window.

Planning a move off on-premises infrastructure?

We design and run hybrid cloud migrations for enterprise and government teams — bring your existing estate, and we'll build the wave plan with you.

Continue Reading

More reference architectures