Introduction
Enterprise cloud migrations have crossed a threshold where manual coordination is no longer realistic. Migrations involving hundreds of servers — spread across mixed OS environments, multiple business units, and several target AWS accounts — are now routine. The operational complexity of managing each step by hand has become one of the biggest bottlenecks IT teams face.
The numbers reflect this pressure. Foundry's 2024 survey of 821 global IT decision-makers found cloud migration rates at 63% — up from 57% the prior year — with 34% citing integration and migration challenges as a primary adoption hurdle. McKinsey research puts the stakes higher: up to 75% of cloud migration projects go over budget, and 38% fall behind schedule.
Those pressures make tooling choices critical. AWS provides powerful migration tools, but manually coordinating agent installation, wave scheduling, and cutover validation across 100+ servers is inherently error-prone — and that's the gap the AWS Cloud Migration Factory (CMF) was purpose-built to close.
If your team is planning a migration at scale, understanding how CMF works — and where it fits — could be the difference between a controlled cutover and a costly overrun.
TL;DR
- CMF is an orchestration platform — not a migration engine — that automates large-scale server migrations to AWS for environments with 100+ servers
- Wave-based execution groups servers into batches of 25–35 and automates repetitive tasks like agent installation, validation, and cutover
- CMF reduces operator time for 100 servers across 10 AWS accounts from 500+ minutes to under 5 minutes — a benchmark that illustrates its core value at scale
- Designed for rehosting (lift-and-shift) and re-platforming to Amazon EC2; not intended for small-scale or single-application migrations
What Is the AWS Cloud Migration Factory?
AWS Cloud Migration Factory (CMF) is an AWS-native, serverless orchestration platform designed to coordinate large-scale migrations involving hundreds to thousands of servers. It deploys directly into a customer's AWS environment via AWS CloudFormation templates.
The platform exists because manual migration at scale breaks down fast. Consider a straightforward example: installing replication agents on 100 servers across 10 target AWS accounts, with mixed Windows and Linux environments. Done manually, that process takes over 500 minutes of operator time. CMF automation reduces that to under 5 minutes.
What CMF Is — and Isn't
CMF is the orchestration layer, not the data movement engine. AWS Application Migration Service (MGN) performs the actual block-level replication from source servers to AWS. CMF sits on top of MGN (and other AWS-native tools) to automate and coordinate their execution at scale across a large server fleet.
CMF primarily supports two migration strategies:
- Rehosting (lift-and-shift): Moving servers to AWS with minimal modification, typically to Amazon EC2
- Re-platforming: Migrating to EC2 with some optimization, using CMF's CloudFormation template generation to define target instance configurations
These strategies assume a certain scale. For smaller moves — single applications or environments under 100 servers — CMF's setup overhead isn't justified, and AWS recommends using MGN directly.
How Does AWS Cloud Migration Factory Work?
CMF breaks migration work into three defined stages. Automation scripts handle the bulk of execution within each stage, while operators manage configuration, monitoring, and go/no-go decisions.
Stage 1: Planning, Setup, and Wave Design
Before any migration runs, teams complete portfolio discovery and wave planning. Servers are grouped into migration waves — AWS recommends 25–35 servers per wave — organized by application dependencies, cutover windows, and business criticality. This metadata is imported into the CMF console via CSV or Excel.
CMF deployment uses two CloudFormation templates:
- Primary account template: Deploys the factory core — Lambda functions, DynamoDB tables, API Gateway, Amazon Cognito, CloudFront, and S3
- Target account template: Configures IAM cross-account roles for each destination AWS account
A built-in validation layer checks imported metadata for errors (missing server names, incorrect account mappings) before data is committed. This catches configuration gaps that would otherwise surface mid-execution, before they cause disruption.
Stage 2: Automated Wave Execution
Once waves are configured, operators trigger automation scripts directly from the CMF console. The sequence typically looks like this:
- Install MGN Agents via AWS Systems Manager, connecting to source servers and deploying replication agents simultaneously across all servers in the wave — Windows and Linux both supported
- Start continuous replication: AWS MGN replicates block storage to a staging area in the target account over TCP port 1500, with no disruption to source systems
- Verify replication status using pre-built validation scripts to confirm data is current before proceeding
- Launch test instances from replicated data to validate behavior before any production cutover
Every action triggered from the CMF console is logged in a Jobs page, recording the script name, status, and authenticated user who initiated it. CMF v3 makes this centralized audit log a core feature, giving compliance teams a clear, timestamped record of every migration action without relying on external tooling.
Stage 3: Cutover and Output
When validation passes, CMF orchestrates the cutover timing. For re-platforming scenarios, it can generate CloudFormation templates from the imported server configuration metadata and deploy target EC2 instances directly, removing manual template authoring from the process.
Migration progress across waves, applications, servers, and databases is tracked through optional Amazon QuickSight dashboards, fed by AWS Glue and Amazon Athena. This gives migration leads real-time visibility into wave completion rates and cutover metrics without building custom reporting.
Key Components That Power the Factory
CMF's architecture is fully serverless and deploys within the customer's own AWS account. The core components:
| Component | Role |
|---|---|
| CloudFront + S3 | Delivers the CMF web application |
| API Gateway + Lambda | Handles all API calls and business logic |
| Amazon DynamoDB | Stores migration metadata, server records, and wave configurations |
| Amazon Cognito | Manages user authentication and authorization |
| AWS Systems Manager | Executes automation scripts on source and target servers |
| AWS Secrets Manager | Stores credentials used in automation tasks |
| AWS MGN | Performs continuous block-level replication (the actual data movement) |
Role-Based Access Control
CMF v3 introduced granular RBAC: administrators define which users can trigger which automation actions. Every action is logged against the authenticated user. For large migration teams spread across business units or geographies, this matters: it prevents unauthorized cutover actions and creates a clear accountability chain for post-migration audits.
Custom Automation Scripts
CMF ships with pre-built scripts for the most common rehosting tasks:
- Agent installation on source servers
- Replication verification against target instances
- Post-cutover instance validation
The platform is extensible. Teams can upload custom scripts through the scripts management interface to handle environment-specific requirements — legacy OS configurations, proprietary middleware, or non-standard networking setups. Custom scripts are versioned and scoped per wave, so teams maintain full control over what runs and when.
Where Cloud Migration Factory Fits in Your Migration Journey
CMF delivers value during the execution phase — after portfolio discovery and wave planning are complete, when teams are ready to run repeated, high-volume migration waves. It is not a discovery or assessment tool.
Where CMF Performs Best
- Organizations migrating 100 or more servers
- Environments with mixed Windows and Linux server estates
- Migrations targeting multiple AWS accounts simultaneously
- Programs with time-sensitive cutover windows where manual coordination introduces unacceptable delay or risk
- Large teams where consistent, auditable execution across multiple operators matters
AWS Prescriptive Guidance documents migrations of up to 1,200 servers using CMF, with thousands more migrated across various enterprise programs. The wave-based approach keeps each execution unit manageable — even when the overall program spans hundreds of servers across multiple accounts.
Where CMF May Not Be the Right Fit
For migrations under 100 servers, the setup overhead of deploying CMF typically outweighs its benefits. AWS MGN used directly — with manual coordination — is often sufficient. Matching the right tooling to actual migration scope is what separates efficient programs from over-engineered ones.
Cygnet.One's ORBIT framework addresses this during its initial Observe phase, mapping server counts, OS environments, account structures, and cutover constraints before recommending tooling.
That scoping step determines whether a full factory model or a direct MGN approach is the right fit — and the execution plan is built from that decision, not the other way around.
Conclusion
The AWS Cloud Migration Factory works by wrapping the complexity of large-scale server migration in a repeatable, auditable, wave-based execution model. Without it, coordinating 100+ servers across multiple AWS accounts and OS types becomes a manual coordination problem that compounds with every additional wave.
Understanding where CMF fits — and where it doesn't — helps IT architects design migration programs that match their actual scope. For enterprises managing migration alongside ERP modernization, compliance changes, or finance system upgrades, the tooling choice rarely exists in isolation.
That's where broader transformation expertise matters. Cygnet.One brings 25 years of enterprise implementation work across SAP, cloud modernization, and regulatory compliance programs, helping organizations align migration strategy with adjacent priorities — not just get servers across the finish line.
Frequently Asked Questions
What is the AWS Cloud Migration Factory?
AWS Cloud Migration Factory is an AWS-native, serverless orchestration platform that automates and coordinates large-scale server migrations to AWS. It sits on top of migration tools like AWS MGN to manage wave execution, agent installation, validation, and cutover across hundreds to thousands of servers, cutting operator effort from hundreds of hours to minutes.
When should you use AWS Cloud Migration Factory?
CMF is recommended for migrations involving 100 or more servers. Below that threshold, the setup and configuration overhead of deploying CMF typically outweighs its benefits, and using AWS MGN directly with manual coordination is usually sufficient.
How is AWS Cloud Migration Factory different from AWS MGN?
AWS MGN is the migration engine: it handles continuous block-level replication from source servers to AWS. CMF is the orchestration layer above it, coordinating MGN and other tools across large server fleets — managing wave scheduling, agent installation, validation, and audit logging at scale.
What migration strategies does the Cloud Migration Factory support?
CMF primarily supports rehosting (lift-and-shift) and re-platforming to Amazon EC2. Pre-built automation scripts cover most rehosting tasks, and CMF can generate CloudFormation templates for target EC2 instances to support re-platforming scenarios.
What are the prerequisites for deploying AWS Cloud Migration Factory?
Before deploying CMF, confirm the following are in place:
- Portfolio discovery and wave planning completed
- AWS MGN initialized in all target accounts
- IAM permissions configured for cross-account access
- CMF deployed via CloudFormation templates into primary and target accounts
Can the Cloud Migration Factory be customized for specific environments?
Yes. CMF ships with pre-built scripts for common tasks, but teams can upload custom scripts through the scripts management interface to handle environment-specific requirements. CMF v3 also supports role-based access control, allowing administrators to define granular permissions for large migration teams.
