AWS Services
AWS Migration Hub
Understand AWS Migration Hub as a migration planning and tracking layer, including current availability caveats, discovery, application grouping, migration progress, DMS and MGN relationships, and SAA-C03 context.
After this, you will understand
Migration Hub helps learners see that migration programs need inventory, grouping, progress tracking, and planning visibility, not only migration engines.
AWS Migration Hub is a central planning and tracking layer for migrations, not the tool that actually copies every server or database.
Learners choose Migration Hub as if it performs the migration instead of recognizing DMS, MGN, DataSync, or other services as the engines.
Use Migration Hub knowledge to understand portfolio tracking and orchestration questions, while checking current AWS availability before recommending it for new customers.
Think before readingWhat is the clean distinction between Migration Hub and MGN?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- AWS Migration Hub
- Current availability caveat
- Migration planning and tracking
- Application portfolio visibility
- Server and database grouping
- Home Region
- Strategy Recommendations
- Orchestration and refactoring-related capabilities
- Relationship to AWS DMS and AWS Application Migration Service
- Exam traps and service boundaries
1. Plain-English Mental Model
AWS Migration Hub is a migration control room.
The simple model is:
many migration tools -> central tracking and application view -> migration program visibility
It is not the engine that copies all data. DMS migrates databases. Application Migration Service replicates and launches servers. DataSync transfers file and object data. Migration Hub sits above those kinds of tools to help teams discover, group, plan, and track migration work.
The important current-status note: AWS documentation now says AWS Migration Hub is no longer open to new customers as of November 7, 2025 and points customers toward AWS Transform for similar capabilities. This page is still useful because older courses and migration discussions mention Migration Hub, but learners should treat it as a lower-priority current exam/service-selection topic unless the official exam scope or a scenario explicitly names it.
2. Why This Service Exists
Large migrations are coordination problems.
A company may have hundreds of servers, dozens of databases, hidden dependencies, shared services, unknown owners, and multiple migration waves. One team may use Application Migration Service for servers. Another may use DMS for databases. Another may use manual modernization. Executives still ask a simple question: what is moving, what is blocked, and which applications are ready?
Without a central view, migration state lives in spreadsheets, tickets, chat threads, and tool-specific dashboards. That breaks when leadership needs portfolio visibility or when dependencies cross team boundaries.
Migration Hub exists to organize migration planning and tracking around applications rather than isolated servers.
For SAA-C03, understand the concept, but know that the currently in-scope Migration and Transfer services emphasize Application Migration Service, DataSync, DMS, Snow Family, and Transfer Family.
3. The Naive Approach And Where It Breaks
The naive migration program is:
spreadsheet -> manual updates -> weekly status meeting -> stale truth
This breaks because migration state changes daily. A server may be replicated, a database may lag, a dependency may be discovered, an owner may be missing, or a wave may slip.
Another naive approach is looking only at servers. Applications are made of servers, databases, queues, DNS records, file shares, jobs, credentials, and operational runbooks. Moving one server does not mean the application is migrated.
A third mistake is treating Migration Hub as the migration tool. It is better understood as the tracking, planning, and visibility layer. The actual movement is performed by services such as MGN, DMS, DataSync, or other migration mechanisms.
4. Core Primitives
An application grouping represents the resources that belong to an application migration effort.
Discovery data helps inventory servers and understand dependencies before migration planning.
Migration status updates can come from integrated tools such as AWS Application Migration Service and AWS Database Migration Service according to AWS documentation.
A home Region stores Migration Hub tracking data. AWS documentation notes that the tracking data is stored in the selected home Region, while migration targets can be in supported Regions for the chosen migration tools.
Strategy Recommendations helped assess migration and modernization paths.
Migration Hub Orchestrator provided workflow templates and tracking for migration workflows.
Refactor Spaces supported incremental application refactoring patterns.
Current AWS guidance for new customers should be checked because Migration Hub availability changed in late 2025.
5. Architecture Use Cases
Use the Migration Hub concept when a company needs portfolio-level migration tracking:
server migration + database migration + app grouping -> central migration status
Use application grouping to avoid treating infrastructure components as unrelated tasks.
Use discovery and strategy planning to identify which workloads should be rehosted, replatformed, refactored, retired, or retained.
Use tracking when multiple tools are involved and teams need a single view of migration progress.
For new architecture recommendations in 2026, verify whether AWS Transform or other current AWS migration tooling is the supported path for similar planning and transformation capabilities.
7. Security Model
Migration Hub security involves IAM permissions, discovery data, migration metadata, tool integrations, and account or Region configuration.
Migration metadata can be sensitive. Server names, application groupings, dependency maps, and migration status reveal internal architecture.
Use least-privilege IAM for people and tools that read or update migration state.
If discovery agents or collectors are used in a migration program, secure their credentials and network access.
CloudTrail can record API activity. Organizations should treat migration planning data as operationally sensitive, especially during merger, acquisition, data center exit, or regulated workload programs.
The service does not replace security design for the migrated workloads. IAM, VPC design, encryption, logging, and compliance controls still belong to each target architecture.
8. Reliability And Resilience
Migration Hub-style tracking improves program reliability by reducing blind spots. It does not make workloads more resilient by itself.
The reliability benefit is coordination: knowing which components are migrated, which are blocked, and which dependencies remain.
A migration dashboard can still be wrong if teams do not update data, if integrations are incomplete, or if application groupings are inaccurate.
For real cutovers, reliability still depends on tested runbooks, rollback plans, backup, replication lag, DNS strategy, application health checks, and operations readiness.
Use tracking as a decision support tool, not as proof that the application works after migration.
9. Performance And Scaling
Migration Hub is not a data plane performance service.
It does not make a database replicate faster, a server cut over faster, or a file transfer complete faster. Those performance characteristics belong to DMS, MGN, DataSync, network connectivity, and target services.
Its scaling problem is organizational: many applications, many teams, many tools, and many statuses.
The architecture question is whether central tracking reduces coordination cost enough to justify the process and tooling.
When exam wording asks for migration performance, look for the actual transfer or replication service. When it asks for central visibility across migrations, think of Migration Hub-style capabilities.
10. Cost Model
Migration Hub-style cost is mostly about program management, discovery tooling, related migration services, and the workloads being migrated.
The direct tracking layer may not be the main cost driver. DMS replication, MGN staging resources, DataSync transfers, target EC2/RDS/S3 resources, network connectivity, testing environments, and staff time usually matter more.
Poor tracking can create hidden cost: duplicate work, missed dependencies, failed cutovers, longer migration waves, and extended data center contracts.
Current AWS Transform pricing and supported features should be checked separately for new customers, because Migration Hub availability has changed.
12. SAA-C03 Exam Signals
"Track migration progress across multiple tools" historically points to AWS Migration Hub.
"Group servers into applications for migration visibility" points to Migration Hub-style planning.
"Choose a migration strategy or assess portfolio readiness" can point to strategy recommendation tooling, but verify current AWS service naming in modern material.
"Replicate servers to AWS for lift and shift" points to AWS Application Migration Service, not Migration Hub.
"Migrate databases" points to AWS DMS, not Migration Hub.
"Transfer file data to S3, EFS, or FSx" points to DataSync, not Migration Hub.
13. Common Exam Traps
Do not choose Migration Hub as the service that performs server replication.
Do not choose Migration Hub as the service that performs database CDC.
Do not ignore current AWS documentation: Migration Hub is not open to new customers as of November 7, 2025.
Do not over-prioritize Migration Hub for current SAA-C03 prep. The official in-scope Migration and Transfer list highlights Application Migration Service, DataSync, DMS, Snow Family, and Transfer Family.
Do not treat a migration tracking dashboard as proof of application readiness.
15. Related Topics
Review AWS Application Migration Service and AWS Database Migration Service as the migration engines most likely to appear in decision questions.
Next, study AWS Organizations because migration programs often span accounts, teams, and governance boundaries.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.