AWS Migration Hub: The Architect's Deep Dive
How Migration Hub's discovery data model, home-region aggregation, and orchestration layer tie together dozens of independent migration tools into one tracked portfolio.
Picture an air traffic control tower that doesn’t fly a single plane itself — it doesn’t own the aircraft, doesn’t hire the pilots, doesn’t fuel the engines — but without it, hundreds of independently operated flights would have no shared picture of who’s where, who’s delayed, and who’s about to conflict with someone else’s flight path. AWS Migration Hub plays exactly that role for enterprise cloud migrations. At a beginner level, it’s described as “a dashboard that tracks your migration.” At the architecture level — where this tutorial operates — it’s a metadata aggregation and status-tracking plane sitting above a dozen independently operating migration and discovery services, each of which does the actual work of moving or assessing a workload. Understanding what Migration Hub owns, what it merely aggregates, and how its data model ties disparate tools together is essential before you design a large-scale migration program around it.
1Internal Architecture: An Aggregation Plane, Not a Migration Engine
Migration Hub performs no migrations itself. Its architectural role is to define a shared “application” data model and status schema that other AWS services write into and read from.
The services Migration Hub sits above
Application Discovery Service (ADS) inventories on-premises servers, processes, and network dependencies. Migration Hub Strategy Recommendations assesses that inventory and proposes a migration strategy per workload. AWS Database Migration Service (DMS) and AWS Application Migration Service (MGN, the successor to Server Migration Service) perform the actual data and server migration. AWS Migration Hub Orchestrator sequences multi-step migration workflows across these tools. Refactor Spaces supports incremental application modernization after a lift-and-shift. Migration Hub itself does not replace any of these — it defines the “Application” grouping construct that lets you see a server discovered by ADS, a database being migrated by DMS, and a compute instance being migrated by MGN, all as parts of one logical business application with one consolidated status.
Migration Hub is the shared whiteboard in a war room, not any one of the moving crews. The database crew, the server crew, and the networking crew all update their own section of the board independently; Migration Hub’s value is that everyone in the room — including the CIO who never touches a single migration tool directly — can look at one board and see the whole picture.
Application Discovery Service
Inventories on-premises servers, running processes, and network connections via agents or agentless collectors.
Strategy Recommendations
Machine-learning-assisted assessment engine that proposes a migration strategy per discovered workload.
Application Migration Service (MGN)
Performs continuous block-level replication and cutover for server migrations — the successor to Server Migration Service.
Database Migration Service
Handles schema conversion (with the Schema Conversion Tool) and ongoing or one-time database replication.
Migration Hub Orchestrator
Sequences multi-step, multi-tool migration workflows using reusable or custom workflow templates.
Refactor Spaces
Provides routing infrastructure for incrementally strangling functionality out of a migrated monolith post-cutover.
flowchart TD
ADS[Application Discovery Service] --> HUB[Migration Hub Data Model]
SR[Strategy Recommendations] --> HUB
MGN[Application Migration Service] --> HUB
DMS[Database Migration Service] --> HUB
ORCH[Migration Hub Orchestrator] --> HUB
RS[Refactor Spaces] --> HUB
HUB --> CONSOLE[Unified Application Status Console]
HUB --> API[Migration Hub API]
Teams sometimes expect Migration Hub to move data or servers if they simply enable it. It performs no migration on its own — every actual migration action happens in DMS, MGN, or a third-party tool that integrates with the Migration Hub API; Migration Hub only aggregates the status those tools report.
2Discovery Data Flow: Agent-Based vs. Agentless Collection
The quality of every downstream decision — strategy recommendation, cost estimate, migration sequencing — depends entirely on the fidelity of the discovery data feeding it.
Agent-Based Discovery
- Deploys a lightweight discovery agent onto each on-premises server.
- Captures process-level detail: running processes, network connections between specific processes, and performance metrics like CPU and memory utilization.
- Higher fidelity, but requires agent installation and maintenance across the fleet.
Agentless Discovery
- Deploys a single agentless collector as a VM, typically into VMware environments, requiring no per-server installation.
- Captures VM-level inventory and basic utilization, but not process-level network dependency mapping.
- Faster to stand up across a large VMware estate, at the cost of dependency-mapping granularity.
Network dependency mapping — knowing that Server A talks to Server B on port 5432 — is only available at meaningful granularity from agent-based discovery. If your migration wave planning depends on grouping servers that must move together, agentless discovery alone will not give you the data to do that reliably.
Collector Deployment
Agents or the agentless collector are deployed across the on-premises estate and registered against the target AWS account’s home region.
Continuous Data Collection
Collectors report inventory, performance metrics, and (for agent-based) network connection data on a recurring interval, not as a one-time snapshot.
Grouping Into Applications
Discovered servers are manually or semi-automatically grouped into logical “Applications” — Migration Hub’s core organizing construct — based on the dependency data collected.
Strategy Assessment
Grouped applications are fed into Strategy Recommendations, which proposes a per-workload migration strategy informed by both the discovery data and any imported third-party assessment data.
Status Tracking Through Cutover
As the actual migration proceeds in MGN, DMS, or a partner tool, status updates flow back into the shared Application record, giving the consolidated view its ongoing accuracy.
3Strategy Recommendations and the Seven R’s
The assessment engine behind Strategy Recommendations doesn’t just categorize workloads — it produces a defensible, data-driven starting point for a decision that used to be almost entirely manual.
| Strategy | Typical Trigger |
|---|---|
| Rehost | Workload is stable, low architectural complexity, migration speed prioritized over optimization |
| Replatform | Some managed-service substitution possible (e.g., self-managed DB to RDS) without major re-architecture |
| Repurchase | Discovered software maps to an available SaaS equivalent, often for commodity or licensed COTS systems |
| Refactor / Re-architect | Business-critical workload where long-term agility justifies deeper modernization investment |
| Relocate | VMware-based workloads moved via VMware Cloud on AWS with minimal change |
| Retain | Workload has dependencies, compliance constraints, or ROI that don’t justify migration yet |
| Retire | Discovery reveals genuinely unused or redundant systems identified through low utilization signals |
The recommendation engine weighs discovered utilization patterns, detected technology stack (operating system, database engine, middleware), and — where imported — third-party configuration management database (CMDB) data, to score each workload against these strategies. Because this is a scored recommendation rather than an authoritative decision, mature migration programs treat the output as a structured starting hypothesis for architecture review, not a final answer to be executed without human validation.
4Home Region and Cross-Region Aggregation
Migration Hub introduces the “home region” concept specifically because discovery and migration activity often spans multiple AWS regions, and someone still needs one consolidated view.
When you first use Migration Hub, you designate a home region — the single region where the consolidated Application-level tracking data is stored and queried from. The actual migrated workloads can land in different target regions entirely (a European workload migrating into eu-west-1 while a North American one migrates into us-east-1), but their status metadata is aggregated back into the home region’s Migration Hub view. This is architecturally similar to the Trusted Advisor organizational rollup pattern: aggregation happens centrally, but the underlying work — the actual replication, the actual cutover — still executes in the target region where the resources live.
flowchart LR
subgraph Home["Home Region (e.g. us-east-1)"]
HUB[Migration Hub Console + Data Model]
end
subgraph R1["Target Region A"]
MGN1[MGN Replication + Cutover]
end
subgraph R2["Target Region B"]
DMS1[DMS Replication]
end
MGN1 -- Status Updates --> HUB
DMS1 -- Status Updates --> HUB
The home region cannot be changed without effectively starting the tracked migration history over in a new region’s Migration Hub instance. Choosing a home region should be a deliberate, early decision — typically aligned to where your migration program’s coordination team primarily operates — not an afterthought discovered mid-program.
5Migration Hub Orchestrator: Workflow Sequencing
Real-world migrations rarely reduce to a single tool call — they’re multi-step workflows with dependencies, and Orchestrator exists specifically to encode and repeat those workflows reliably.
Orchestrator lets a migration architect define a workflow template — a sequenced set of steps that might include pre-migration validation, triggering MGN replication, running a database schema conversion through DMS, executing a custom validation script via Systems Manager, and finally performing cutover — as a reusable template rather than a one-off runbook followed manually by an engineer. Templates can branch, incorporate manual approval gates, and be applied consistently across dozens or hundreds of similar workloads (for example, “all workloads matching the standard 3-tier web application pattern”), turning what was previously inconsistent runbook execution into a repeatable, auditable workflow engine.
Wave-Based Migration at Scale
A migration program moving 200 similar 3-tier applications defines one Orchestrator template encoding validation, replication, and cutover steps once, then applies it across every wave, rather than having each engineer improvise the same multi-tool sequence independently with inconsistent results.
6Refactor Spaces: Post-Migration Modernization
A rehost-first migration strategy defers modernization — Refactor Spaces exists to make that deferred modernization structurally easier once the workload is already running in AWS.
Refactor Spaces provisions a routing layer — built on Amazon API Gateway and a transit VPC — in front of a migrated monolith, allowing individual routes to be incrementally redirected to new, purpose-built microservices as they’re built, without a disruptive big-bang cutover. This directly supports the common enterprise pattern of “rehost now, refactor later”: Migration Hub Strategy Recommendations may flag a workload for eventual refactoring, but the actual refactor doesn’t have to block the initial migration — Refactor Spaces gives that later refactor a structural on-ramp.
Refactor Spaces is like renovating one room of a house at a time while everyone keeps living in it — a smart router in the hallway sends you to the old room or the newly renovated one depending on which room you asked for, so the house never has to be fully vacated for the renovation to happen.
7Advantages, Disadvantages, and Trade-offs
Advantages
- Consolidates status across an inherently heterogeneous toolchain into one Application-level view executives and program managers can read without touching individual tools.
- Strategy Recommendations converts a largely manual assessment exercise into a scored, data-driven starting point.
- Orchestrator turns ad-hoc migration runbooks into repeatable, auditable workflow templates at wave scale.
- No additional cost for Migration Hub’s core tracking functionality itself — you pay for the underlying services (MGN, DMS, data transfer) it coordinates.
Disadvantages / Trade-offs
- Discovery data quality is entirely dependent on agent coverage and deployment discipline; gaps produce misleading Application groupings and strategy scores.
- Home region choice is effectively permanent for a given migration program’s tracked history (Chapter 4).
- Third-party or non-integrated migration tools require custom API integration to appear in the consolidated view at all.
- Strategy Recommendations output still requires expert architecture review — treating it as a final answer risks systematically wrong modernization decisions at scale.
8Performance and Scalability for Large Portfolios
Enterprise migrations frequently involve thousands of discovered servers — at that scale, the discovery-to-grouping pipeline becomes a throughput and data-quality concern in its own right.
At large scale, manually grouping thousands of discovered servers into logical Applications is impractical; programs typically import network dependency data and apply semi-automated clustering (grouping servers with dense mutual network connections) before human review, rather than grouping purely by hand. Similarly, Orchestrator’s template-based approach is specifically what makes wave-based execution tractable at hundreds of applications — without it, each wave would require bespoke runbook authoring that doesn’t scale linearly with program size.
9Security Model and Discovery Agent Trust Boundaries
Discovery agents and collectors operate with privileged visibility into on-premises infrastructure, which makes their credential handling and network egress a first-order security design question.
Discovery agents authenticate to AWS using credentials scoped narrowly to the Application Discovery Service data-submission API — they do not require broad account-level permissions, and they operate as an outbound-only connection from the on-premises network to AWS, avoiding the need to open inbound firewall rules. The agentless collector, running as an on-premises VM with read access to the virtualization platform’s management API (such as vCenter), carries a correspondingly higher trust requirement, since it needs credentials capable of enumerating the entire virtual estate it inventories.
Rotate and scope the vCenter (or equivalent) service account used by the agentless collector as narrowly as the platform allows — read-only inventory access is sufficient, and that credential should never be reused for any write-capable automation elsewhere in the virtualization environment.
10Monitoring, Status Tracking, and Program Reporting
A migration program’s status reporting is only as good as how consistently the underlying tools push accurate state into the shared Application record.
Migration Hub’s status model tracks each Application through discovery, planning, in-progress migration, and completed states, with the underlying migration tool (MGN or DMS) responsible for pushing accurate status transitions as the actual work progresses. For programs that need historical trend reporting — burn-down of applications remaining per wave, week over week — the Migration Hub API can be polled on a schedule to export status snapshots into a durable store, similar to the export pattern used for Trusted Advisor and Control Tower drift history, since Migration Hub itself does not retain long-range historical trend charts natively.
Executive Wave Burn-Down Reporting
A large migration program exports Migration Hub Application status daily into a data warehouse, building a weekly burn-down chart per wave that program leadership reviews, independent of any single migration engineer’s manual status updates.
11Design Patterns and Anti-Patterns
Problem
Grouping discovered servers into Applications by guesswork or naming convention alone, without validating against actual network dependency data from agent-based discovery.
Why It’s Harmful
Incorrect grouping leads to cutover sequencing that migrates a database server in one wave while the application server that depends on it moves in a later wave, causing avoidable downtime that has nothing to do with the migration tooling itself.
Correct Approach
Deploy agent-based discovery specifically for workloads where dependency accuracy materially affects wave sequencing, and validate proposed Application groupings against the collected network connection data before finalizing wave plans.
Problem
Executing Strategy Recommendations output directly as a migration plan without architecture review.
Why It’s Harmful
The recommendation engine scores based on discoverable technical signals; it cannot see undocumented compliance constraints, planned application retirements, or business-context factors that materially change the correct strategy for a given workload.
Correct Approach
Use Strategy Recommendations output as a structured input to a human architecture review board, not as an auto-executed decision, per the guidance in Chapter 3.
Problem
Similar workloads keep requiring the same multi-tool migration sequence, reinvented manually each time.
Approach
Invest early in Orchestrator workflow templates for your most common workload archetypes (Chapter 5); the upfront template-authoring cost pays back quickly once a program executes more than a handful of similar migrations.
12Best Practices and Real-World Examples
Run Discovery Before Planning
Allow discovery collectors to run for a full business cycle (typically 2–4 weeks minimum) to capture representative utilization patterns before finalizing strategy decisions.
Choose Home Region Deliberately
Align home region to your coordination team’s location and expected long-term program duration, per Chapter 4.
Validate Groupings With Network Data
Cross-check Application groupings against actual discovered dependencies rather than organizational assumptions.
Template Common Workload Archetypes
Build Orchestrator templates for repeated patterns before wave execution begins at scale.
Global Enterprise Data Center Exit
A multinational enterprise closing physical data centers on a fixed timeline uses Migration Hub as the single program-tracking surface across dozens of regional migration teams executing in parallel, each using MGN and DMS independently but reporting into one home-region view.
M&A-Driven Migration Consolidation
A company that has acquired several smaller businesses uses discovery and Strategy Recommendations to build a defensible, data-driven case for which acquired systems to consolidate, retire, or migrate — turning an otherwise political decision into one grounded in observed utilization and dependency data.
13Frequently Asked Questions
No — it coordinates and aggregates status across them, per Chapter 1. DMS and MGN (or a partner tool) still perform the actual migration work; Migration Hub provides the shared Application data model and consolidated view.
Yes, if the partner tool integrates with the Migration Hub API to push status updates — the aggregation model isn’t limited to native AWS services, but it does require that integration to exist for a tool’s progress to show up in the consolidated view.
Agentless discovery gives fast, broad VM-level inventory; agent-based discovery adds process-level network dependency mapping essential for accurate wave sequencing, as discussed in Chapter 2 — most large programs use agentless for breadth and agent-based selectively for workloads where dependency accuracy matters most.
No — home region only determines where Migration Hub’s tracking data lives; actual migrated workloads can land in any target region, with status aggregated back to the home region, per Chapter 4.
No — treat it as a scored starting hypothesis requiring architecture review, not an auto-executed decision, as covered in Chapters 3 and 11.
14Summary and Key Takeaways
Migration Hub’s architectural identity is that of an aggregation and orchestration plane sitting above a genuinely heterogeneous toolchain — discovery, assessment, replication, and workflow sequencing all happen in separate specialized services, and Migration Hub’s job is to give a program-wide view without owning any of that underlying execution itself. Its value compounds with discovery data quality, deliberate home-region and Application-grouping decisions, and disciplined use of Orchestrator templates at wave scale — and it degrades quickly when treated as a fully automated decision engine rather than a structured, reviewable input to human architecture judgment.
Key Takeaways
- Migration Hub performs no migration itself — it aggregates status and defines the Application data model shared across ADS, Strategy Recommendations, MGN, DMS, Orchestrator, and Refactor Spaces.
- Discovery data quality drives everything downstream — agent-based discovery is required for reliable network dependency mapping, which agentless discovery cannot provide.
- Strategy Recommendations is a scored starting hypothesis, not a final decision — architecture review remains essential before execution.
- Home region is effectively a permanent choice for a program’s tracked history, even though target migration regions can differ freely.
- Orchestrator’s real value is repeatability — templating common workload archetypes is what makes wave-based execution tractable at hundreds of applications.
- Refactor Spaces exists for the “later” in rehost-now-refactor-later, giving deferred modernization a structural on-ramp instead of requiring a second disruptive cutover.
- Long-range program reporting requires your own export pipeline — Migration Hub does not natively retain deep historical trend data.