Your datacenter contract ends in 42 days and is set for decommission. Over twenty percent of your VMs run operating systems that lost support before the COVID-19 pandemic began and haven't received security updates in nearly a decade. Documentation is incomplete due to corporate restructuring. Releasing these systems isn't always an option - they're running revenue-critical applications, and system modernization is not an option by customer definition.
This isn't hypothetical. It's the reality CloudZone recently navigated for a leading AI company: ±25 VMs across two Israeli data centers, a hard December 31st deadline, legacy Windows/Linux OS versions, and significant knowledge gaps due to organizational changes.
The project succeeded not by pursuing technical perfection, but by aligning pragmatic approaches with real-world constraints.
Not every VM fits the same migration pattern. We developed three parallel paths based on OS compatibility and business constraints:
AWS Application Migration Service provides automated, continuous replication for supported operating systems. Minimal downtime, built-in validation, test launches before production cutover. We executed in four migration waves, grouped by functionality, technology stack, migration strategy, and complexity.
Legacy OS versions incompatible with MGN (vendor link) were exported as OVF files to S3. This isn't failure- it's strategic pragmatism. S3 preservation provides compliance retention, recovery optionality, and costs a fraction of maintaining datacenter space.
VM Import/Export enables you to import virtual machine (VM) images from your existing virtualization environment to Amazon EC2, and then export them back. This enables you to migrate applications and workloads to Amazon EC2, copy your VM image catalog to Amazon EC2, or create a repository of VM images for backup, this mitigation option supportes alternative OS stack (vendor link).
Reserving cloud-native refactoring for high-value systems where investment is justified. Make this a post-migration opportunity, not a pre-migration requirement.
The critical insight: These paths aren't sequential stages where you "fail down", they're parallel strategic choices aligned with business constraints and risk tolerance.
We evaluated different technologies (including AWS's latest Agentic Transport, MGN, VM Import, OVF Backups, EVS, VMC, etc.), Glass box transparency approach, and side-to-side collaboration with customer focal, AWS, and Matrix experts taking the best decisions aligned to requirements and constraints.
Active Directory: The Trust Relationship Approach
This represents our most differentiated value, delivering a tailored approach. From assessment and planning to execution and post-optimization, with Max agility to customer change requests, during the project lifecycle.
Most AD migration content focuses on user migration via ADMT. But legacy applications don't work this way; service accounts are hardcoded in configuration files, connection strings, and Windows services across dozens of systems. Finding and updating every reference takes time which you don't have.
Our Journey:
Strategic impact: Shifting approach to self-managed AD.. In retrospect actually simplified customer IT operation, as existed forest and domains where re-used, preserved SIDs, no domain join changes required post MGN, fully compatible with MGN (no identity remediation required, existing GPOs/service accounts, LDAPs are preserved, no app impact, full operational control (customer request).
We architected four distinct VPCs connected via Transit Gateway:
Test failures in Labs don't impact production. You validate functionality, networking, and authentication before actual cutover windows. Labs VPC test launches revealed network connectivity assumptions, DNS dependencies, and permission issues, resolved before production impact.VPN vs. Direct Connect: Timeline Drives Decision
We chose Site-to-Site VPN over Direct Connect due to timeline constraints. Direct Connect requires weeks to provision and upfront capital investment. VPN offered rapid provisioning (days), sufficient bandwidth for MGN replication, and operational expense versus capital expense. For time-constrained migrations with defined end states, VPN delivers faster results.
Documentation gaps equal migration risk. If nobody can answer "What happens if this VM stops for 30 seconds?", you have a knowledge problem. In our project, partial knowledge due to reorganizations emerged as a more significant risk factor than OS compatibility.
Contractual datacenter exit dates are non-negotiable. Map backward from the hard deadline and accept "good enough" over "perfect" in architecture decisions when timeline compression demands it.
Not just "old", specifically incompatible with AWS MGN. Set expectations early: legacy OS requires mature assessment - vendor support, security hardenings, licensing, target resources (e.g. hypervisors, shared pool vs dedicated hosts), IT expertise, committed SLAs, etc)
Clear RACI boundaries prevent surprises. We made customer ownership (e.g., MGN agent installation) strategic, it forced early engagement with workload owners, surfacing hidden dependencies before cutover when addressing them is less costly.
Lital Hakim (Project Mgr):
How do you prevent "perfection" from becoming the enemy of the deadline?
Answer: We enforce a strict backward-mapped timeline from the exit date, prioritizing "good enough" for migration over "perfect" for architecture to ensure no VM is left behind.
Mhinkyu Kim (Cloud DevOps Mgr):
What is the biggest technical risk when migrating "32-bit fossils"?
Answer: It’s often not the OS itself, but undocumented dependencies, for example, AWS MGN does not include 32-bit (x86) network drivers in its conversion package, Nitro-based instances do not support 32-bit guest OS, etc.
Why can't I just import my OVA directly to EC2?
AWS VM Import validates that the instance can boot and establish network connectivity. Legacy VMs with VMware-only drivers will fail this check, forcing you to use the snapshot-import and helper-instance workaround to manually inject AWS drivers offline.
Should I use Nitro or Xen-based instance types for legacy VM migrations?
Start with Xen-based instances (t2, m4, r4) for legacy OS migrations. Nitro instances (t3+, m5+, r5+) require ENA and NVMe drivers that older operating systems may not support, even after driver injection.
Avital Silverstone (Cloud DevOps):
Why choose Self-Managed AD on EC2 instead of AWS Managed Microsoft AD?
We opted for a self-managed solution to ensure a zero-impact migration. By extending our existing domain into AWS, we avoided changing SIDs, rejoining servers, or modifying applications. This allowed us to meet our DC shutdown deadline safely without the risks of a full identity redesign.
What obstacles might we face during the MGN agent deployment?
While most servers synced perfectly, we hit three specific hurdles that required manual intervention:
The datacenter exit succeeded:
The strategic insight: The best migration isn't the most technically elegant- it's the one that meets business objectives within real-world constraints.
Legacy OS preservation via S3 was pragmatic risk management. Trust-based AD architecture enabled business continuity while maintaining modernization optionality. Organizations that succeed make tradeoffs consciously, strategically, with a clear-eyed assessment of constraints.
If your organization faces aging infrastructure, hard deadlines, incomplete documentation, and business continuity requirements, the path forward isn't wishing for better circumstances. It's building a strategy that works within your actual circumstances.
CloudZone specializes in time-critical infrastructure migrations where standard playbooks don't apply. Our AWS Premier Partner status, Migration Competency, and 150+ AWS certifications mean we bring proven architectural patterns refined across enterprise migrations.
Schedule a migration discovery workshop →
Your datacenter contract ends in 42 days and is set for decommission. Over twenty percent of your VMs run operating systems that lost support before the COVID-19 pandemic began and haven't received security updates in nearly a decade.
As organizations increasingly adopt generative AI, Most teams discover the cost problem after they've already deployed. Here's how to get ahead of it. Teams working with Google Cloud Vertex AI often discover that without a structured approach, costs can scale quickly and unpredictably.
In the Amazon Aurora ecosystem, I/O (Input/Output) is often the silent budget killer. Every read and write operation adds up, and in the Standard configuration, those millions of requests create a bill that is as volatile as it is expensive.
