Discovery vs. Tracking vs. Strategy vs. Orchestration

Discovery (powered by AWS Application Discovery Service) is the inventory-gathering layer — it finds out what servers, applications, and dependencies exist on-premises before anyone has decided what to do with them. Tracking is Migration Hub’s core dashboard function: once servers are grouped into “applications,” it shows a single status per application — Not Started, In Progress, or Complete — regardless of which underlying tool is doing the actual work. Strategy Recommendations is an analysis layer that looks at discovered inventory plus a completed questionnaire and recommends, per application, one of the seven migration strategies (the “7 R’s”). Orchestration (Migration Hub Orchestrator) is a workflow-automation layer that sequences the actual migration steps — snapshotting, replicating, cutting over — across multiple AWS services according to a reusable template. A team can use any subset of these four independently; Migration Hub doesn’t require you to adopt all of them to get value from any one.

The Home Region Constraint

Migration Hub requires designating a single home region per AWS account — the region where all discovery data, application groupings, and status metadata are aggregated and displayed, regardless of which region the workloads themselves are actually being migrated into. This is a one-time, largely irreversible choice made early in setup; changing it later effectively means starting the aggregated view over. Intermediate teams frequently discover this constraint the hard way when a second team in the same organization spins up Migration Hub in a different region and ends up with two disconnected views of the same migration program.

The 7 R’s Strategy Framework

Migration Hub’s Strategy Recommendations feature classifies every application into one of seven categories: Retire (decommission, it’s no longer needed), Retain (keep it on-premises for now, migrate later or never), Rehost (“lift-and-shift,” moved as-is with minimal change, typically via Application Migration Service), Relocate (move a VMware environment as a whole into AWS without re-provisioning individual hosts), Repurchase (replace with a SaaS or different commercial product), Replatform (move with some optimization, like swapping a self-managed database for RDS, without changing core architecture), and Refactor/Re-architect (redesign the application to be cloud-native, typically the highest effort and highest long-term payoff). Migration Hub doesn’t invent this framework from nothing — it’s AWS’s long-standing migration methodology — but Strategy Recommendations is the specific feature that applies it automatically, at scale, across hundreds or thousands of discovered servers, rather than requiring a consultant to assess each one manually.

Applications as the Unit of Tracking

Migration Hub does not track individual servers as its primary unit — it tracks applications, which are simply named groupings of one or more discovered servers that a team decides belong together (a three-tier web app’s web server, app server, and database server, for instance). This grouping is manual or semi-automated (Strategy Recommendations can suggest groupings based on network dependency data), and it matters because the dashboard’s Not Started/In Progress/Complete status is computed at the application level, aggregating the status of every server within it — which means an application isn’t marked Complete until every one of its constituent servers has reported completion from whichever migration tool moved it.

Migration Hub Import: Bringing External Tools Into the Picture

Not every migration tool an organization already owns has a native Migration Hub integration, and AWS deliberately doesn’t require abandoning existing tooling to get value from the Hub. Migration Hub Import lets a team either upload a CSV following a defined template or call the underlying APIs directly to register on-premises server inventory that wasn’t collected through Application Discovery Service — perhaps because a prior discovery exercise was already done with a different tool, or because the source environment doesn’t support agent-based or agentless collection. Imported data behaves like discovered data for grouping and tracking purposes once it’s in, but it’s the team’s responsibility to keep it current, since there’s no agent silently refreshing it in the background the way there is with native discovery.

Relocate as a Distinct Strategy

Among the 7 R’s, Relocate deserves particular attention because it’s frequently confused with Rehost. Rehost moves individual servers, typically re-provisioning each one as a new EC2 instance. Relocate specifically applies to VMware Cloud on AWS scenarios, where an entire VMware environment — hosts, VMs, and networking configuration largely intact — is moved into AWS without re-provisioning each guest individually, preserving the existing VMware management tooling and operational processes the team already relies on. Migration Hub’s Strategy Recommendations distinguishes between these two because the decision driver is usually operational continuity (Relocate) versus a deliberate chance to modernize the underlying infrastructure (Rehost), not a difference in the target workload itself.

flowchart LR
    subgraph SRC[On-Premises / Source Environment]
      SRV[Servers & VMs]
      DB[(Databases)]
      FILES[File Shares]
    end
    subgraph DISC[Discovery Layer]
      AA[Discovery Agent]
      ADC[Agentless Discovery Connector]
    end
    SRV --> AA
    SRV --> ADC
    AA --> ADS[Application Discovery Service]
    ADC --> ADS
    ADS --> MH[Migration Hub
Home Region Aggregator]
    MH --> SR[Strategy Recommendations]
    MH --> DASH[Tracking Dashboard]
    MH --> ORCH[Migration Hub Orchestrator]
    ORCH --> MGN[Application Migration Service
Rehost]
    ORCH --> DMS[Database Migration Service]
    ORCH --> DS[DataSync
File Data]
    MGN -->|Status Updates| MH
    DMS -->|Status Updates| MH
    DS -->|Status Updates| MH
    PART[Partner & Custom Tools] -->|Migration Hub Import API| MH
    

On the discovery side, servers are inventoried by one of two mechanisms: the Discovery Agent, a lightweight software agent installed directly on Windows or Linux servers that captures detailed performance metrics, running processes, and network connections; or the Agentless Discovery Connector, a VM appliance deployed into a VMware environment that collects inventory and utilization data at the hypervisor level without touching individual guest operating systems. Both feed into AWS Application Discovery Service, which is the actual data-collection and storage backend — Migration Hub’s console is, for discovery purposes, largely a presentation layer over Application Discovery Service’s data.

The Migration Tool Layer

Migration Hub integrates natively with AWS Application Migration Service (MGN) for rehost migrations (continuous block-level replication of servers into AWS, with a lightweight cutover), AWS Database Migration Service (DMS) for database migrations (supporting homogeneous and heterogeneous engine migrations with schema conversion via the related Schema Conversion Tool), and AWS DataSync for bulk file and object data transfer. Each of these services runs its own migration independently and simply reports progress back to Migration Hub — Migration Hub has no direct control over the replication or cutover mechanics of any of them.

Migration Hub Orchestrator

Layered above the individual tools, Migration Hub Orchestrator provides reusable, templated workflows that sequence multi-step migrations — for example, a rehost template that automates installing the MGN replication agent, monitoring replication lag, running a test launch, and executing cutover, all as a tracked, resumable workflow rather than a manual runbook a migration engineer follows by hand. Orchestrator supports custom workflow templates for organizations with their own standardized migration process, in addition to AWS-provided templates for common patterns like VMware rehost or SAP migrations.

Migration Hub Refactor Spaces

A separate component, Migration Hub Refactor Spaces, addresses a different problem entirely: incrementally breaking apart a monolithic application into microservices without a risky big-bang cutover. It provisions an environment-and-routing layer — an API Gateway and a transit gateway-backed network — that lets specific routes or paths of an existing monolith be redirected to a new microservice one at a time, while the rest of the traffic continues to the original monolith unchanged. This is squarely a Refactor/Re-architect strategy tool, and it’s the one piece of the Migration Hub family that isn’t really about moving existing servers at all, but about restructuring an application’s internal architecture over time, with Migration Hub’s tracking still able to reflect the application’s overall migration status as each route is progressively moved.

Resource Groups and Tagging Integration

Migration Hub leans on AWS Resource Groups and standard resource tagging to help teams organize target-side AWS resources by migration wave, application, or business unit once workloads land in AWS. Tagging discipline established during migration planning — a consistent migration-wave or source-application tag applied to every provisioned resource — pays off well beyond the migration itself, since it becomes the basis for post-migration cost allocation and operational ownership reporting that many programs need anyway.

Migration Hub’s dashboard status is not computed by Migration Hub observing the migration directly — it’s computed by migration tools reporting into Migration Hub via a defined API contract. Every integrated tool (MGN, DMS, DataSync, and any third-party or custom tool) calls the Migration Hub UpdateMigrationProgress and NotifyApplicationState APIs at key points in its own workflow — replication started, replication caught up, cutover initiated, cutover complete. Migration Hub simply stores and displays whatever the latest reported state is; it performs no independent verification that a server genuinely finished migrating.

Why This Matters for Custom and Partner Tools

Because status reporting is API-driven rather than automatically inferred, any migration tool that doesn’t natively integrate with Migration Hub — a legacy in-house script, or a partner tool without a built-in integration — simply won’t appear on the dashboard unless someone explicitly calls the Migration Hub Import API (or uploads a CSV template through the console) to push status updates in. This is a deliberate, open design: AWS doesn’t require you to abandon existing tooling to get a unified view, but it does require every tool in the mix to actively participate in reporting.

Discovery Data Refresh Cycle

Discovery Agents and the Agentless Discovery Connector don’t stream data continuously in true real time; they collect performance and inventory data at defined intervals (agents typically every fifteen minutes for performance metrics, with configuration and network-connection data collected periodically as well) and upload it in batches to Application Discovery Service, which Migration Hub then reflects. An intermediate operator planning a discovery phase should budget at least two to four weeks of continuous agent runtime before relying on the collected data for capacity planning, since utilization patterns (peak CPU, memory, disk I/O) need enough sampling across business cycles — end-of-month processing, weekly batch jobs — to be representative rather than a single quiet snapshot.

A practical rule of thumb: start with Discovery whenever the source environment’s inventory isn’t already well documented — most enterprise migrations underestimate their own server count and inter-application dependencies until an agent-based discovery phase corrects the picture. Use Strategy Recommendations once discovery data is reasonably mature, to avoid manually assessing hundreds of applications one by one. Use the Tracking Dashboard from day one regardless of tooling maturity, since it costs nothing extra to point existing migration activity at it. Adopt Orchestrator specifically when a migration pattern (VMware rehost, for instance) will be repeated across dozens or hundreds of servers and a consistent, auditable workflow is worth more than ad-hoc scripts.

When Not to Reach for the Full Suite

Smaller migrations — a handful of applications, a well-understood environment already documented in an existing CMDB — often don’t justify a full discovery-first engagement at all. In those cases, teams reasonably skip Application Discovery Service entirely, import a manually curated application list directly through Migration Hub Import, and go straight to Tracking and, optionally, Orchestrator. The full discovery-through-strategy pipeline earns its overhead specifically at the scale where manual assessment becomes impractical; forcing it onto a ten-application migration mostly adds process weight without a proportional accuracy benefit.

The Aggregation-vs-Control Trade-off

Because Migration Hub deliberately avoids owning the actual execution mechanics of any migration, it trades a degree of control for a degree of flexibility: it can sit above almost any tool an organization already has, but it can never guarantee execution quality the way a tool that directly controls replication and cutover can. Teams sometimes expect Migration Hub to behave like a single, all-controlling migration platform and are surprised to learn that troubleshooting a stalled replication still means going into MGN or DMS directly — Migration Hub will simply, faithfully, show you that something is stalled.

Discovery Depth as a Cost of Accuracy

A related trade-off sits inside the discovery phase itself: agentless discovery is fast to deploy and low-friction, but it produces shallower data — utilization at the VM level, without the process-level and network-connection detail an installed agent captures. Strategy Recommendations and dependency mapping are both meaningfully more accurate with agent-based data, but rolling agents out across thousands of servers takes real time and coordination with server owners. Programs under time pressure often accept the shallower agentless view for the majority of the estate and reserve agent-based discovery for the specific applications where a wrong strategy recommendation would be most costly to correct later — a deliberate, not accidental, trade-off between speed and depth.

Migration Hub itself is a fully managed AWS service with no customer-provisioned capacity, and the console and APIs are designed to handle large discovery datasets and high volumes of status-update calls without customer-side tuning. The scaling concerns intermediate operators actually encounter live in the layers Migration Hub sits above, not in Migration Hub’s own aggregation logic.

Discovery Agent Fleet Scale

Rolling out Discovery Agents across a fleet of several thousand on-premises servers is an operational exercise in its own right — deployment automation (via existing configuration management tooling), staggered rollout to avoid overwhelming a proxy or firewall egress path, and monitoring for agents that silently stop reporting. Application Discovery Service comfortably scales to enterprise-sized fleets, but the human and network-bandwidth logistics of getting an agent correctly installed and reporting from every server is consistently the actual bottleneck in large discovery phases, not the service’s ingestion capacity.

Strategy Recommendations at Portfolio Scale

Strategy Recommendations is explicitly designed to run its assessment across an entire discovered portfolio in one pass rather than requiring per-application manual triggering, which is what makes it viable for a program with hundreds or thousands of applications — the alternative, a consultant manually reviewing each application against the 7 R’s framework, simply does not scale to that volume within a reasonable program timeline.

Orchestrator Concurrency

Migration Hub Orchestrator supports running many workflow instances concurrently, one per server or application being migrated, which is the pattern large rehost waves use — a template is defined once and then instantiated across dozens of servers in a single migration wave, with each instance tracked and resumable independently if a specific server’s replication needs troubleshooting without blocking the rest of the wave.

Network Bandwidth as the Real Ceiling

For rehost migrations in particular, the actual throughput ceiling almost never turns out to be an AWS-side service limit — it’s the available bandwidth on the connection between the source data center and AWS, whether that’s a Direct Connect link, a site-to-site VPN, or, for very large one-time transfers, physical data transfer via AWS Snowball. Migration Hub’s dashboard will faithfully show a server sitting in “In Progress” for days if the underlying replication is bandwidth-constrained; recognizing that this is a network capacity-planning problem, not a Migration Hub or even an MGN problem, is a distinction intermediate operators need to make quickly during a stalled migration wave rather than escalating it as a service issue.

As a fully managed control-plane service, Migration Hub’s own availability is operated by AWS, and there is no trail or failover concept customers configure directly for the Hub itself. Reliability concerns at the intermediate level center on the health of the reporting chain and the resilience of the discovery data collection, not on Migration Hub’s uptime.

Reliability of the Status-Reporting Chain

Because dashboard accuracy depends on every integrated tool correctly calling the reporting API, the weakest link in Migration Hub’s effective reliability is usually a custom or partner integration that fails silently — a script that updates status on success but has no error handling for a failed API call, leaving a server’s status frozen at “In Progress” indefinitely even after the underlying migration tool itself completed or failed. Production migration programs treat “is the dashboard status stale” as its own monitoring concern, independent of whether the underlying migration tool is healthy.

Durability of Discovery Data

Discovery data collected by Application Discovery Service is retained and durable for the life of the discovery engagement, but it is not automatically exported or backed up outside the service by default — teams running long, multi-phase migrations sometimes periodically export discovery and dependency data (via the Application Discovery Service export API) into their own reporting store, both as a durability safeguard and to enable analysis tooling that Migration Hub’s console doesn’t natively provide.

You may likeAWS Savings Plans→

Resilience Across a Multi-Month Program

Migration programs frequently run for many months, and reliability at that timescale is less about any single service outage and more about organizational continuity of the tracking data itself — team turnover, changed application ownership, and re-scoped migration waves are all far more likely to degrade the usefulness of the Migration Hub dashboard over a long program than any technical failure. Mature programs assign explicit, named ownership to keeping application groupings and strategy assignments current as circumstances change, treating this as an ongoing program-management responsibility rather than a one-time setup task completed at kickoff.

Protecting Discovery Data

• IAM policies scoped to Application Discovery Service and Migration Hub actions should be limited to the specific migration team, since the aggregated dependency map effectively reveals the organization’s entire application architecture, including which systems talk to which — valuable reconnaissance information if it fell into the wrong hands.
• Discovery Agent credentials (the keys agents use to authenticate to Application Discovery Service) should be scoped tightly and rotated, since a compromised agent credential could be used to inject false inventory data or, at minimum, expose real inventory data to an unauthorized caller.
• The Agentless Discovery Connector’s VMware credentials deserve particular attention, since the connector typically requires read access across the vCenter environment to collect utilization data — scoping that service account to the minimum vCenter permissions needed for discovery, rather than a full administrator account, limits blast radius if the connector VM itself is compromised.

Cross-Account and Multi-Account Migration Programs

Large migrations frequently span a source on-premises environment and multiple target AWS accounts (one per business unit or environment tier). Migration Hub supports a home region, single-account aggregation model natively; visibility across multiple target accounts typically requires either designating one account as the shared Migration Hub home and granting cross-account IAM roles for the tools operating in other accounts to report into it, or accepting a genuinely fragmented view per account. Organizations standardizing on AWS Organizations for their broader account structure generally choose the former, treating Migration Hub’s home account similarly to a centralized logging or security account.

Data Residency and Regional Considerations

Because the home region determines where discovery metadata and status information are stored and aggregated, organizations with data residency requirements — a regulatory obligation to keep certain categories of data within a specific geography — need to factor that constraint into the home region decision itself, not just into where target workloads ultimately run. This occasionally creates tension for global organizations whose natural “closest” region for a given business unit doesn’t match the home region chosen for the overall program, a trade-off usually resolved by keeping the aggregated dashboard in the program’s primary region while documenting that discovery data for regionally-constrained applications is handled through a separate, compliant process.

Least-Privilege IAM for Migration Roles

A typical migration program involves several distinct IAM roles with meaningfully different privilege needs: a discovery-operations role limited to Application Discovery Service actions, a migration-execution role scoped to the specific target resources MGN or DMS needs to provision, and a program-management role limited to read access across the Migration Hub dashboard and Strategy Recommendations output. Collapsing these into a single broad “migration admin” role for convenience is common under program time pressure, but it works against the principle that a temporary, time-boxed migration effort shouldn’t leave behind IAM roles with far more standing privilege than any individual migration task actually required.

Migration Hub’s console provides its own status dashboard, but production migration programs typically layer additional monitoring around three distinct concerns: discovery health, status-reporting freshness, and migration-tool-specific progress metrics.

Discovery Health Monitoring

Application Discovery Service exposes agent health status (connected, not connected, health status like “healthy” or “unhealthy” based on recent check-ins) that migration teams monitor to catch agents that have stopped reporting due to a network change, a credential expiry, or the agent process crashing on the source server. A simple scheduled check against this status, alerting when a previously healthy agent goes silent for more than its expected reporting interval, closes the gap Migration Hub itself doesn’t proactively alert on.

Cross-Tool Progress Metrics via CloudWatch

The underlying migration tools — Application Migration Service and Database Migration Service in particular — publish their own detailed CloudWatch metrics: replication lag, throughput, and error rates for MGN; task status, latency, and validation results for DMS. Because Migration Hub’s own status field is coarse (Not Started, In Progress, Complete), teams needing finer-grained operational visibility — “how far behind is this replication right now” — go directly to these tool-specific CloudWatch metrics rather than expecting Migration Hub’s dashboard to surface that level of detail.

Building a Program-Management Reporting Layer

Because Migration Hub’s console is built for operational status-checking rather than executive reporting, many programs export data via the Migration Hub and Application Discovery Service APIs into a QuickSight dashboard or a spreadsheet-based weekly report — tracking trend metrics like applications migrated per week, applications stalled beyond an expected duration, and portfolio completion percentage against the program plan. This reporting layer is explicitly a build-it-yourself addition; Migration Hub provides the underlying data but not this kind of program-level trend visualization natively.

flowchart TB
    subgraph PROG[Migration Program Account Structure]
      HOME[Migration Hub Home Account
Chosen Home Region]
      TGT1[Target Account: Prod Workloads]
      TGT2[Target Account: Non-Prod Workloads]
    end
    ONPREM[On-Premises Data Center
Discovery Agents + Connector] -->|Discovery Data| HOME
    HOME -->|Cross-Account Role| TGT1
    HOME -->|Cross-Account Role| TGT2
    TGT1 -->|MGN / DMS Status| HOME
    TGT2 -->|MGN / DMS Status| HOME
    HOME --> REPORT[Program Dashboard
QuickSight / Spreadsheet Export]
    

The standard production pattern for an enterprise migration program designates a single account and region as the Migration Hub home — often the organization’s existing shared-services or management account, or a dedicated migration-program account created specifically for the initiative — and configures cross-account IAM roles so that migration tools running in separate target accounts (production, staging, per-business-unit accounts) can still report status back into that shared home. This mirrors the broader AWS multi-account best practice of centralizing observability and program-tracking data even when workloads themselves are deliberately distributed.

Phased Rollout: Discovery-First vs. Parallel Tracks

Two common deployment sequences exist. A discovery-first approach runs Application Discovery Service across the full estate for several weeks before any migration activity begins, producing a complete inventory and strategy assessment before committing resources to specific migration waves. A parallel-track approach begins migrating well-understood, low-risk applications immediately using manual assessment, while discovery continues in the background for the less-understood remainder of the estate. Larger, less-well-documented environments generally benefit from discovery-first, since committing to migration waves before understanding true application dependencies is a common source of unplanned rework; smaller or well-documented environments often move faster with the parallel-track approach.

Infrastructure as Code for Repeatable Waves

Because a migration program typically executes the same pattern — deploy target infrastructure, replicate via MGN or DMS, validate, cut over — across dozens or hundreds of applications, teams commonly define the target-side infrastructure (VPCs, subnets, security groups, target EC2 launch templates) via CloudFormation or Terraform, parameterized per application, and pair it with a Migration Hub Orchestrator workflow template so that each migration wave is a repeatable, auditable execution of the same underlying pattern rather than a bespoke effort per application.

Best Practices

• Choose the Migration Hub home region deliberately and document the decision before any team starts using the console, since changing it later fragments the program’s tracking history.
• Run discovery for a minimum of two to four weeks before finalizing application groupings or committing to strategy recommendations, to capture representative peak-usage and dependency patterns.
• Scope Discovery Agent and Agentless Discovery Connector service accounts to least-privilege, rather than reusing broad administrative credentials for convenience during setup.
• Treat status-reporting freshness as its own monitored concern, independent of whether the underlying migration tool itself is healthy, since the two can silently diverge.
• Standardize on Orchestrator templates for any migration pattern repeated more than a handful of times, rather than letting each migration engineer improvise their own runbook.

Common Mistakes

• Assuming Migration Hub itself performs data replication or cutover — it doesn’t; every byte moved is the responsibility of an underlying tool like MGN, DMS, or DataSync.
• Grouping servers into applications too early, based on assumed rather than observed dependencies, leading to rework mid-program.
• Forgetting that a custom or partner migration tool needs an explicit integration (via the Import API or CSV upload) to appear on the dashboard at all — silence on the dashboard doesn’t necessarily mean no progress is happening.
• Treating the Tracking Dashboard’s coarse three-state status as sufficient for operational troubleshooting, rather than going to tool-specific CloudWatch metrics when something needs to be diagnosed in detail.

A Practical Checklist

For a program standing up Migration Hub for the first time, a reasonable sequence looks like: designate the home region and document why; deploy discovery (agentless first for speed, agents selectively for higher-value applications) and let it run at least two to four weeks; validate dependency data against existing architecture documentation and correct assumptions before finalizing application groupings; run Strategy Recommendations and review its output with application owners rather than accepting it uncritically; select or build Orchestrator templates for any strategy that will repeat across more than a handful of applications; and set up independent freshness monitoring for both discovery agents and status-reporting tools before the first migration wave goes live, so gaps are caught early rather than discovered mid-program.