AWS Migration Hub Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Migration and transfer

1. Introduction

AWS Migration Hub is AWS’s central place to track, manage, and coordinate application migrations to AWS. It does not replace migration tools that actually move servers or databases. Instead, it organizes your migration program by giving you a consistent view of progress across applications, migration waves, and integrated tools.

In simple terms: AWS Migration Hub is a “single pane of glass” for migrations. If you are using AWS services like AWS Application Migration Service (MGN) for servers or AWS Database Migration Service (DMS) for databases, Migration Hub helps you see what is happening, what is done, what is stuck, and what is next—at an application level.

Technically, AWS Migration Hub provides a console experience and APIs to: – Group resources into applications – Track migration tasks and their status over time – Orchestrate migration steps (via Migration Hub Orchestrator) – Generate migration strategy recommendations (via Migration Hub Strategy Recommendations) – Support incremental modernization patterns (via Migration Hub Refactor Spaces)

The problem it solves: most migrations fail or run over budget not because the tools can’t move workloads, but because teams struggle with program governance—visibility, sequencing, ownership, repeatability, and auditability. AWS Migration Hub addresses these program-level gaps by providing a structured way to plan and track migrations across tools and teams.

2. What is AWS Migration Hub?

Official purpose: AWS Migration Hub helps you track the progress of application migrations to AWS across multiple AWS and partner migration tools, and provides capabilities to plan, orchestrate, and modernize as part of your migration journey.

Core capabilities (at a practical level): – Application-centric tracking: Track migration status by application, not just by server. – Tool aggregation: Bring migration signals from multiple AWS services and partner tools into one place. – Orchestration (optional): Coordinate multi-step migrations using workflows and runbooks (Migration Hub Orchestrator). – Strategy (optional): Generate recommendations for how to migrate/modernize workloads (Migration Hub Strategy Recommendations). – Refactoring support (optional): Support incremental application refactoring patterns (Migration Hub Refactor Spaces).

Major components you’ll encounter: – AWS Migration Hub console (visual dashboard for migration status) – Migration Hub APIs (track tasks, update status, attach attributes) – Migration Hub Orchestrator (workflow-based orchestration for application migrations) – Migration Hub Strategy Recommendations (analysis and recommendations) – Migration Hub Refactor Spaces (support for incremental refactoring; modernization)

Service type: A management and governance service for migrations (Migration and transfer category), plus optional components for orchestration and modernization.

Scope (important): – Account-scoped: Migration Hub data is associated with an AWS account. If you use multiple accounts, you typically manage migrations per account or use a centralized migration account with clear governance. – Region-scoped: Migration Hub is used in an AWS Region. Your “migration program” should standardize on a Region for tracking.
Verify region behavior and “home region” requirements in official docs for the specific Migration Hub capability you’re using (tracking vs strategy vs orchestrator).

How it fits into the AWS ecosystem: AWS Migration Hub sits “above” execution tools: – Discovery/assessment tools (for example, AWS Application Discovery Service, Migration Evaluator) help you understand what you have. – Migration execution tools (for example, AWS Application Migration Service and AWS DMS) help you move workloads. – Migration Hub helps you track, coordinate, and govern the end-to-end program.

Official docs entry point: https://docs.aws.amazon.com/migrationhub/

3. Why use AWS Migration Hub?

Business reasons

Portfolio visibility: Executives and program managers need a credible view of what is migrated, what is at risk, and what’s next.
Reduced migration risk: Better tracking and orchestration reduces missed steps during cutover.
Faster time to value: Teams can execute migration waves more consistently.
Standardization: A single tracking method reduces chaos from spreadsheets and fragmented reporting.

Technical reasons

Application-level mapping: Migrations succeed at the application boundary, not at the individual server boundary.
Integration with AWS migration tooling: Migration Hub can reflect status from AWS migration services and partner tools (where integrated).
Repeatable orchestration: Orchestrator workflows reduce manual runbooks for common migration patterns.

Operational reasons

Clear ownership and status: Track migration tasks by application, wave, and team.
Auditability: Integrates with AWS auditing patterns (for example, AWS CloudTrail for API activity).
Consistency across environments: Use repeatable templates/workflows where applicable.

Security/compliance reasons

Controlled access via IAM: You can control who can see or update migration status.
Audit trails: CloudTrail can record API actions for governance and compliance.
Reduced ad-hoc data sharing: Less need for uncontrolled spreadsheets emailed around.

Scalability/performance reasons

Program scale: Helps track migrations across dozens to thousands of servers when integrated with discovery/migration tools.
Scalable tracking model: Use APIs and structured task updates for automation.

When teams should choose it

Choose AWS Migration Hub if: – You are migrating multiple applications (not just one server) – You need program-level tracking across teams/tools – You want repeatability and workflow-based coordination (Orchestrator) – You are building a migration factory (waves, cutovers, standard operating procedures)

When teams should not choose it

Migration Hub may be unnecessary if: – You are migrating a single small workload and can track progress informally – You need a tool that moves data/servers (Migration Hub does not perform data replication itself) – Your migration execution is entirely outside AWS tooling and you can’t integrate status updates (though you can still use APIs if you build your own updates)

4. Where is AWS Migration Hub used?

Industries

Financial services (regulated migrations, strict audit trails)
Healthcare (PHI-sensitive programs with governance needs)
Retail/e-commerce (wave-based migrations with seasonal constraints)
Manufacturing (legacy estate modernization)
SaaS and software companies (multi-tenant platform migrations)
Public sector (structured programs, reporting requirements)

Team types

Cloud Center of Excellence (CCoE)
Platform engineering teams
DevOps/SRE teams coordinating cutovers
Migration factories / professional services teams
Security and compliance teams supporting governance
Application owners and product teams coordinating modernization

Workloads

VM-based applications (VMware or other hypervisors) moving to EC2
Three-tier web apps (web/app/db)
COTS apps (including Windows-based estates)
Data platform migrations (when paired with DMS and database modernization work)
Hybrid estates with phased migrations

Architectures and deployment contexts

Landing zone / multi-account AWS Organizations setups
Hub-and-spoke network patterns with shared services
Central migration account coordinating execution accounts
Environments where discovery and dependency mapping inform sequencing

Production vs dev/test usage

Production migrations: Most common, because tracking and governance matter most during production cutovers.
Dev/test migrations: Useful for dry runs and pilot waves to establish repeatable workflows and reporting.

5. Top Use Cases and Scenarios

Below are realistic scenarios where AWS Migration Hub is a strong fit.

1) Application migration portfolio dashboard

Problem: Leadership needs a reliable view of progress across dozens of applications and teams.
Why it fits: Migration Hub centralizes application migration status across integrated tools.
Example: A company migrates 120 applications in 10 waves and uses Migration Hub as the reporting system of record.

2) Track AWS Application Migration Service (MGN) server migrations by application

Problem: Server replication status exists, but app owners need application-level readiness.
Why it fits: Migration Hub focuses on applications and can surface migration progress.
Example: 40 EC2 cutovers are grouped into 8 applications; Migration Hub shows which apps are ready for cutover.

3) Coordinate database migrations alongside application cutover

Problem: App cutover depends on database replication, schema changes, and validation.
Why it fits: Migration Hub provides a single place to track tasks across services (for example, DMS plus app tasks).
Example: DMS replication tasks and app deployment tasks are tracked under one application entry.

4) Migration factory operations (waves and workstreams)

Problem: Multiple teams (network, IAM, app, DBA, security) must complete steps per wave.
Why it fits: Migration Hub Orchestrator can codify workflows and provide status visibility.
Example: Each wave uses the same workflow template: prechecks → replication → test → cutover → validation.

5) Build a custom migration tracker for non-integrated tools

Problem: A partner or in-house tool performs some migration steps but doesn’t show up in AWS dashboards.
Why it fits: Migration Hub APIs let you import tasks and update status programmatically.
Example: A custom on-prem discovery tool sends status updates to Migration Hub so teams can use one dashboard.

6) Strategy planning and rationalization (6Rs)

Problem: You need to decide which workloads to rehost, replatform, refactor, retire, or retain.
Why it fits: Migration Hub Strategy Recommendations can provide structured recommendations based on collected data.
Example: 600 servers are analyzed; low-complexity apps are flagged for rehost, others for refactor/retire.

7) Migrate and modernize using incremental refactoring (strangler pattern)

Problem: You can’t refactor a monolith in one big-bang release.
Why it fits: Migration Hub Refactor Spaces supports patterns for gradually routing traffic to new services.
Example: An API endpoint is carved out of a monolith and implemented as a new service while legacy remains in place.

8) Governance and audit for regulated migrations

Problem: You must demonstrate who changed migration status and when.
Why it fits: API actions can be audited through CloudTrail; access can be controlled through IAM.
Example: A regulated firm requires evidence of change control for each cutover stage.

9) Operational readiness tracking and cutover checklists

Problem: Migration fails due to missed operational tasks (monitoring, backups, patching, runbooks).
Why it fits: Orchestrated workflows and consistent task tracking reduce missed steps.
Example: A workflow includes enabling CloudWatch alarms, backup policies, and access reviews before “go-live.”

10) Multi-team collaboration and handoffs

Problem: Status is unclear during handoffs between teams and time zones.
Why it fits: Migration Hub provides a shared, near-real-time status view.
Example: APAC team completes replication; EU team performs validation; US team performs cutover—tracked centrally.

6. Core Features

AWS Migration Hub includes multiple capabilities. Not every organization uses all of them; many start with tracking and add orchestration/strategy later.

Feature 1: Centralized migration tracking dashboard

What it does: Provides a consolidated view of migration status across applications and tasks.
Why it matters: You need a single source of truth to run migration waves.
Practical benefit: Faster reporting, fewer status meetings, fewer spreadsheet conflicts.
Limitations/caveats: The dashboard is only as good as the data feeding it; non-integrated tools require API-based updates.

Feature 2: Application grouping (application-centric view)

What it does: Lets you represent migrations as “applications” rather than isolated servers.
Why it matters: Cutovers are planned at the application level (dependencies, change windows, rollback).
Practical benefit: Aligns technical migration with business ownership.
Limitations/caveats: You must define what “application” means in your org (naming, boundaries, ownership).

Feature 3: Migration task tracking via APIs

What it does: Enables programmatic creation and updates of migration tasks and statuses.
Why it matters: Automation and integration are essential at scale.
Practical benefit: Integrate CI/CD, ITSM, or partner tools with Migration Hub.
Limitations/caveats: Requires IAM permissions and consistent conventions (streams, task names, status mapping).

Feature 4: Integration with AWS migration services (tracking signals)

What it does: Surfaces migration progress from AWS migration tools where supported.
Why it matters: Reduces duplicated reporting; aligns execution tooling with program tracking.
Practical benefit: Less manual work to maintain status.
Limitations/caveats: Integration scope depends on the tool and region; verify current integration support in official docs.

Feature 5: Migration Hub Orchestrator (workflow coordination)

What it does: Helps orchestrate multi-step migrations with workflows/templates and task assignments.
Why it matters: Real migrations have many steps (prechecks, replication, DNS, validation, rollback).
Practical benefit: Repeatability, fewer missed steps, clearer run-state visibility.
Limitations/caveats: Not a universal orchestrator for every tool; templates and integration vary—verify supported templates and steps in official docs.

Feature 6: Migration Hub Strategy Recommendations (planning support)

What it does: Analyzes collected server/application data and provides migration strategy recommendations.
Why it matters: Reduces time spent manually classifying workloads and identifying modernization paths.
Practical benefit: Portfolio segmentation and planning acceleration.
Limitations/caveats: Recommendations depend on data quality and coverage; treat as guidance, not absolute truth.

Feature 7: Migration Hub Refactor Spaces (incremental modernization support)

What it does: Supports patterns for incremental refactoring of applications (often aligned to strangler-pattern approaches).
Why it matters: Many orgs need to modernize gradually while keeping legacy stable.
Practical benefit: Controlled transition from monolith to services without big-bang rewrites.
Limitations/caveats: It’s a modernization component, not required for lift-and-shift; it introduces architectural complexity—use intentionally.

Feature 8: Governance and audit alignment (via AWS-native controls)

What it does: Leverages AWS IAM for authorization and AWS CloudTrail for auditing API actions.
Why it matters: Migration programs must satisfy compliance and change management requirements.
Practical benefit: Traceability and separation of duties.
Limitations/caveats: You must enable and retain CloudTrail logs appropriately; Migration Hub is not itself a GRC tool.

7. Architecture and How It Works

High-level architecture

AWS Migration Hub sits at the “coordination layer”: 1. Migration execution tools (AWS and partner tools) perform replication, conversion, and cutover actions. 2. Those tools (or your automation) publish status to Migration Hub (directly via integration or via APIs). 3. Migration Hub organizes status by application and tasks. 4. Users and automation systems read status from the console/APIs for reporting and governance.

Control flow vs data flow

Control flow: Users/automation update tasks and statuses; Orchestrator triggers steps (where used).
Data flow: Migration Hub stores metadata about tasks, applications, and statuses—not your application payload data.

Integrations with related AWS services (common patterns)

AWS Application Migration Service (MGN): Server migration execution (replication, test, cutover). Migration Hub can be used for tracking at the program level.
AWS Database Migration Service (DMS): Database replication and migration tasks that can be tracked as part of an application migration.
AWS Application Discovery Service: Discovery and inventory that can inform planning and grouping.
AWS IAM: Access control (who can view/update migration tracking).
AWS CloudTrail: Audit API actions and console activity.
AWS Organizations (common pattern): Multi-account governance. Migration Hub itself is account-scoped; cross-account visibility typically requires role switching or centralized patterns you design.

Security/authentication model

Authentication: AWS Identity and Access Management (IAM) users/roles.
Authorization: IAM policies granting access to Migration Hub APIs and related resources.
Audit: CloudTrail logs can record API calls.

Networking model

Migration Hub is a managed AWS service accessed via:
AWS Management Console (HTTPS)
AWS APIs (HTTPS)
No VPC deployment is required for the tracking service itself. If you use collectors/agents or Orchestrator steps, those may require VPC connectivity to your environments and targets.

Monitoring/logging/governance considerations

Logging: Use CloudTrail for API auditing.
Operational monitoring: Migration Hub is not primarily a metrics service; operational monitoring usually happens in the execution tools (MGN/DMS) and in CloudWatch for migrated workloads.
Governance: Standardize naming, tagging (where applicable), and wave definitions outside and inside Migration Hub.

Simple architecture diagram (conceptual)

flowchart LR
  subgraph Sources["Migration Status Sources"]
    MGN["AWS Application Migration Service (MGN)"]
    DMS["AWS Database Migration Service (DMS)"]
    PT["Partner / Custom Tools"]
    API["Your Automation (Migration Hub APIs)"]
  end

  HUB["AWS Migration Hub\n(Tracking + Apps + Tasks)"]
  CONSOLE["Migration Hub Console\n(Portfolio View)"]
  USERS["Program Teams\n(App owners / Ops / PMO)"]

  Sources --> HUB
  HUB --> CONSOLE
  CONSOLE --> USERS

Production-style architecture diagram (program scale)

flowchart TB
  subgraph Org["AWS Organizations (typical)"]
    subgraph MigAcct["Migration Program Account"]
      HUB["AWS Migration Hub"]
      ORCH["Migration Hub Orchestrator (optional)"]
      CT["AWS CloudTrail"]
      IAM["IAM / Identity Center (common)"]
    end

    subgraph WorkloadAccts["Workload Accounts (per app/team)"]
      MGN["AWS Application Migration Service (MGN)"]
      DMS["AWS Database Migration Service (DMS)"]
      CW["Amazon CloudWatch (workload monitoring)"]
    end
  end

  OnPrem["On-Prem / Data Center\n(servers, DBs)"] --> MGN
  OnPrem --> DMS

  MGN --> HUB
  DMS --> HUB

  ORCH --> MGN
  ORCH --> DMS

  IAM --> HUB
  HUB --> CT

  HUB --> "Portfolio dashboards & reporting\n(inside console / via APIs)"
  WorkloadAccts --> CW

8. Prerequisites

Before you start using AWS Migration Hub (especially for API-based tracking and labs), make sure you have the following.

Account and billing

An AWS account with billing enabled.
Permission to use AWS Migration Hub in at least one AWS Region.

Permissions / IAM roles

You need IAM permissions to: – Access the Migration Hub console – Call Migration Hub APIs (if doing automation) – (Optional) Use Orchestrator, Strategy Recommendations, or Refactor Spaces capabilities

AWS provides managed policies for some migration services. Prefer least privilege where possible: – Start by reviewing available managed policies (search in IAM for “MigrationHub”).
Verify current managed policy names and scope in official IAM documentation.

Tools

AWS CLI (recommended for the hands-on lab): https://docs.aws.amazon.com/cli/
A terminal with access to the internet
(Optional) jq for JSON formatting

Region availability

AWS Migration Hub is not necessarily available in every region with identical capabilities (tracking vs strategy vs orchestrator vs refactor spaces can differ).
Verify in the official docs and region tables for the specific Migration Hub capability you plan to use:
https://docs.aws.amazon.com/migrationhub/
https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/

Quotas / limits

Expect limits around the number of applications, tasks, and update rates (varies by capability).
Check Service Quotas and Migration Hub documentation for current limits.
If you can’t find a quota in Service Quotas, rely on the service’s API/documentation limits.

Prerequisite services (optional, depending on your use)

If you are executing migrations: MGN, DMS, discovery tooling, etc.
If you are orchestrating: permissions to run underlying steps and access target accounts/resources.

9. Pricing / Cost

Current pricing model (how to think about it)

AWS Migration Hub is primarily a management/tracking layer. Historically, AWS has stated that Migration Hub tracking is available at no additional charge, and you pay for the AWS services you use for discovery, replication, compute, storage, and data transfer.

However, AWS Migration Hub also includes capabilities that can create costs indirectly (and some capabilities may have their own pricing rules). Always confirm the latest pricing and any capability-specific charges.

Official pricing page (verify current details): https://aws.amazon.com/migration-hub/pricing/
AWS Pricing Calculator: https://calculator.aws/

Pricing dimensions (what you pay for)

You typically pay for related services used alongside Migration Hub, such as: – AWS Application Migration Service (MGN): replication infrastructure, staging resources, snapshots, EBS, etc. (pricing rules vary) – AWS Database Migration Service (DMS): replication instances, storage, I/O, logs – Discovery tooling: collectors, compute/storage for data retention, analytics – Orchestrator dependencies: any AWS resources created or run as part of workflows (for example, automation steps that run compute) – Refactor Spaces dependencies: resources used to route traffic and run services (exact components depend on your design)

Cost drivers

Number of servers/databases migrated: more replication, more staging capacity, more data moved
Data transfer volumes: on-prem → AWS, inter-region, cross-AZ, and internet egress
Parallelism: migrating many apps simultaneously increases peak infrastructure needs
Duration: longer replication windows and extended coexistence periods cost more
Logging and retention: CloudTrail, log storage, and analytics costs

Hidden or indirect costs to watch

Data transfer charges (especially cross-region or internet egress)
Staging resources for replication and testing (MGN/DMS)
Snapshots and storage growth during extended migration windows
Temporary double-running (on-prem + AWS) during coexistence
Tooling overhead: CI/CD, monitoring, security scanning, and compliance tooling

How to optimize cost

Standardize migration waves: reduce idle staging time.
Right-size replication infrastructure: avoid overprovisioning replication instances.
Shorten coexistence: plan cutovers tightly to reduce dual-running costs.
Use tagging and cost allocation: track costs per application/wave.
Use AWS Budgets and Cost Explorer: monitor anomalies during waves.

Example low-cost starter estimate (conceptual)

A minimal starter lab that uses only Migration Hub APIs (no replication) will usually incur: – $0 or near $0 for Migration Hub tracking itself (verify pricing page) – Standard API and logging costs are typically minimal, but: – If CloudTrail data events or extra trails are configured, logging may have small costs – Your existing account baseline (for example, CloudTrail, Config, GuardDuty) may incur costs unrelated to this lab

Example production cost considerations (realistic)

A production migration program cost model should include: – Replication service costs (MGN/DMS) – Temporary EC2/EBS usage (staging, test environments) – Data transfer (DX/VPN/Internet) – Security and compliance tooling – Operations overhead (monitoring/logging) – Team time and partner services

The key point: AWS Migration Hub improves visibility and reduces program risk, but it does not eliminate the underlying infrastructure and data movement costs of migration.

10. Step-by-Step Hands-On Tutorial

This lab demonstrates AWS Migration Hub’s tracking APIs in a safe, low-cost way by creating a progress update stream and a sample migration task, then updating task status over time and verifying it in the console.

Objective

Create and track a sample “application migration task” in AWS Migration Hub using the AWS CLI: – Create a Progress Update Stream – Import a Migration Task – Update task status from NOT_STARTED → IN_PROGRESS → COMPLETED – Verify in the AWS Migration Hub console – Clean up resources

Lab Overview

You will simulate status updates as if they were coming from a migration tool.

What you’ll build: – A Progress Update Stream (a logical channel that groups updates from a tool or integration) – A Migration Task (represents the thing being migrated—server/app component) – Status updates with timestamps

Expected outcome: – You can see your migration task and its latest status in Migration Hub. – You understand the mechanics behind integrating custom tools with Migration Hub tracking.

Step 1: Choose a Region and verify CLI access

Configure your AWS CLI credentials: – https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html
Pick a region (example uses us-east-1). Set environment variables:

export AWS_REGION="us-east-1"
export AWS_DEFAULT_REGION="us-east-1"

Verify identity:

aws sts get-caller-identity

Expected outcome: You see your AWS account and ARN.

Step 2: Confirm you can call Migration Hub APIs

List existing progress update streams (may be empty):

aws migrationhub list-progress-update-streams

Expected outcome: Command succeeds. If access is denied, fix IAM permissions (see Troubleshooting).

Step 3: Create a Progress Update Stream

Create a stream to represent a tool or integration (example: tutorial-stream).

STREAM_NAME="tutorial-stream"

aws migrationhub create-progress-update-stream \
  --progress-update-stream-name "$STREAM_NAME"

Expected outcome: The stream is created successfully.

Verify it exists:

aws migrationhub list-progress-update-streams

Step 4: Import a Migration Task

Now create a migration task (example: webapp-server-01).

TASK_NAME="webapp-server-01"

aws migrationhub import-migration-task \
  --progress-update-stream "$STREAM_NAME" \
  --migration-task-name "$TASK_NAME"

Expected outcome: The task is registered.

List tasks:

aws migrationhub list-migration-tasks \
  --progress-update-stream "$STREAM_NAME"

Step 5: Send the first status update (NOT_STARTED)

Migration Hub task updates include a timestamp. Use UTC time. On Linux/macOS:

NOW_UTC="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"
echo "$NOW_UTC"

Now send a status update:

aws migrationhub notify-migration-task-state \
  --progress-update-stream "$STREAM_NAME" \
  --migration-task-name "$TASK_NAME" \
  --update-date-time "$NOW_UTC" \
  --next-update-seconds 3600 \
  --task '{"Status":"NOT_STARTED","StatusDetail":"Task registered in Migration Hub","ProgressPercent":0}'

Expected outcome: The task’s state is updated.

Step 6: Update status to IN_PROGRESS

A few minutes later (or immediately for the lab), update to in progress:

NOW_UTC="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"

aws migrationhub notify-migration-task-state \
  --progress-update-stream "$STREAM_NAME" \
  --migration-task-name "$TASK_NAME" \
  --update-date-time "$NOW_UTC" \
  --next-update-seconds 3600 \
  --task '{"Status":"IN_PROGRESS","StatusDetail":"Replication started (simulated)","ProgressPercent":25}'

Expected outcome: The task is now IN_PROGRESS.

Step 7: Update status to COMPLETED

Update the task to completed:

NOW_UTC="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"

aws migrationhub notify-migration-task-state \
  --progress-update-stream "$STREAM_NAME" \
  --migration-task-name "$TASK_NAME" \
  --update-date-time "$NOW_UTC" \
  --next-update-seconds 3600 \
  --task '{"Status":"COMPLETED","StatusDetail":"Cutover completed (simulated)","ProgressPercent":100}'

Expected outcome: The task shows COMPLETED.

Step 8: Verify in the AWS Migration Hub console

Open the AWS console.
Go to AWS Migration Hub: – https://console.aws.amazon.com/migrationhub/
Ensure the Region selector matches your CLI region (for example, us-east-1).
Locate migration tasks and find your task: – Look for views related to Migration tasks or Tools / Task status (console layout can evolve).

Expected outcome: You can see tutorial-stream and webapp-server-01 with the latest status.

If you don’t see it, double-check: – Region – Permissions – That the task updates succeeded – Console filters

Validation

Run the following checks:

Confirm the task exists:

aws migrationhub list-migration-tasks --progress-update-stream "$STREAM_NAME"

Get details:

aws migrationhub describe-migration-task \
  --progress-update-stream "$STREAM_NAME" \
  --migration-task-name "$TASK_NAME"

Expected outcome: Output shows task status COMPLETED and progress 100.

Troubleshooting

Common issues and fixes:

AccessDeniedException – Cause: Missing IAM permissions for Migration Hub APIs. – Fix: Attach or create a policy that includes the necessary migrationhub:* actions for this lab. – Also ensure you’re not blocked by permission boundaries or SCPs in AWS Organizations.
Task/stream not visible in console – Cause: Wrong AWS Region selected in the console. – Fix: Match the console Region to AWS_REGION.
Invalid timestamp format – Cause: --update-date-time must be in an accepted timestamp format (commonly ISO 8601 UTC). – Fix: Use date -u +"%Y-%m-%dT%H:%M:%SZ".
ResourceAlreadyExistsException – Cause: You already created the stream/task earlier. – Fix: Choose a unique name or delete and recreate during cleanup.

Cleanup

Delete the progress update stream (this is the main cleanup item):

aws migrationhub delete-progress-update-stream \
  --progress-update-stream-name "$STREAM_NAME"

Re-list streams to confirm deletion:

aws migrationhub list-progress-update-streams

If deletion fails because tasks still exist or due to service rules: – Check the error message. – Some services require tasks to be in a terminal state; ensure tasks are completed. – Verify official docs for stream/task deletion behavior (service behavior can change).

11. Best Practices

Architecture best practices

Define application boundaries early: Align with business ownership, not just infrastructure topology.
Track by wave and cutover window: Make migration hub data reflect how you actually execute migrations.
Standardize migration statuses: Decide what “IN_PROGRESS” means (replication? testing? cutover?) and document it.

IAM/security best practices

Least privilege: Separate permissions for:
View-only dashboards
Updating task status
Managing Orchestrator workflows
Separation of duties: Migration operators can update tasks; auditors can view logs.
Use roles, not long-lived keys: Prefer IAM roles and federation.

Cost best practices

Use tags and cost allocation across the migration program: Especially for MGN/DMS and temporary EC2/EBS.
Budget by wave: Use AWS Budgets to detect overruns early.
Shut down temporary resources promptly: Test instances, staging resources, and extra logging.

Performance best practices (program execution performance)

Parallelize safely: Migrate in parallel only when downstream teams (network, security, operations) can support it.
Automate status updates: If your pipeline updates Migration Hub automatically, humans spend less time on reporting and more on execution.

Reliability best practices

Treat Migration Hub as tracking, not execution: Build reliable migration execution using MGN/DMS and tested runbooks.
Use Orchestrator for repeatable steps: Reduce manual error during cutovers.
Plan rollback paths: Track rollback steps as first-class tasks, not as an afterthought.

Operations best practices

Use CloudTrail and central logging: Keep an audit trail of migration status changes.
Create a runbook for “stuck” statuses: What to do when replication stalls or validation fails.
Operational readiness checks: Include monitoring/alerting/backups in the definition of “completed.”

Governance/tagging/naming best practices

Consistent naming conventions: appname-env-wave-component is often better than ad-hoc names.
Ownership metadata: If supported in your process, track app owner, tech owner, and escalation contacts.
Change management alignment: Map Migration Hub milestones to ITSM change records.

12. Security Considerations

Identity and access model

IAM controls access to Migration Hub APIs and console.
Use role-based access:
Read-only for stakeholders
Update rights for migration operators/automation
Admin rights for platform team

Verify current IAM actions and managed policies in official docs: – Migration Hub docs: https://docs.aws.amazon.com/migrationhub/ – IAM documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/

Encryption

Migration Hub is a managed AWS service; AWS services typically encrypt data at rest and in transit.
For capability-specific encryption controls (for example, KMS integration), verify in official docs for the specific capability (tracking vs strategy vs orchestrator vs refactor spaces).

Network exposure

Console and APIs are accessed over HTTPS.
If you deploy collectors/agents (for discovery or strategy recommendations), ensure:
Outbound connectivity is controlled (proxy/NAT)
TLS inspection policies are compatible
Firewall rules are documented and approved

Secrets handling

Do not store credentials in scripts.
Use:
IAM roles for EC2
AWS SSO / IAM Identity Center for humans
CI/CD secrets managers (for example, AWS Secrets Manager) where needed

Audit/logging

Enable CloudTrail in line with your organization’s policies.
Centralize logs in a security account if using AWS Organizations.
Ensure log retention meets compliance requirements.

Compliance considerations

Migration programs often touch regulated data. Migration Hub stores metadata, but your migration execution tools and target workloads handle real data.
Align your migration governance with:
Data classification
Access reviews
Change management approvals
Evidence collection (CloudTrail, run logs, validation outputs)

Common security mistakes

Over-permissive IAM roles for migration automation
No CloudTrail retention or centralized audit
Mixing human and automation identities
Poor separation between dev/test and prod migration permissions

Secure deployment recommendations

Use dedicated migration roles with scoped permissions.
Require MFA and federation for console access.
Use SCPs carefully to avoid blocking needed migration actions, but don’t disable governance controls without a plan.
Document who is allowed to mark tasks “COMPLETED” and what evidence is required.

13. Limitations and Gotchas

Key realities to plan for:

Migration Hub does not migrate workloads by itself. It tracks and coordinates.
Region scoping can confuse teams. If you update tasks in one region but check the console in another, you may think data is missing.
Data quality depends on integrations. If tools don’t publish status (or you don’t automate API updates), dashboards won’t reflect reality.
Application grouping is a design task. Poor app definitions lead to misleading progress reporting.
Orchestrator is not a universal migration engine. It coordinates steps, but you must verify supported templates and integrations.
Partner tool integration varies. Not all third-party tools integrate equally; many require custom API updates.
Quotas exist. Large migration programs should verify task/application limits and update frequency constraints.
Legacy service confusion: AWS has had multiple migration services over time. For example, AWS Server Migration Service (SMS) has been retired/end-of-support (verify current status in AWS announcements). Do not design new migrations around retired services.
Status semantics: If you treat COMPLETED as “cutover done” but another team treats it as “replication started,” reporting becomes meaningless—standardize definitions.

14. Comparison with Alternatives

AWS Migration Hub is best understood as a migration management plane. Alternatives fall into three buckets: migration execution tools, cloud-native tracking alternatives, and other cloud providers’ migration hubs.

Option	Best For	Strengths	Weaknesses	When to Choose
AWS Migration Hub	Program-level migration tracking and coordination in AWS	Application-centric tracking, integrates with AWS migration tools, supports orchestration/strategy/modernization components	Doesn’t move workloads; value depends on integrations and good operating model	You have multiple apps and need a structured migration program
AWS Application Migration Service (MGN)	Server rehosting to EC2	Replication and cutover tooling	Not a portfolio dashboard by itself	You need to migrate servers; use with Migration Hub for program tracking
AWS Database Migration Service (DMS)	Database migrations/replication	Broad engine support, continuous replication options	Requires planning around schema conversion and validation	Use for DB migration; track at app level in Migration Hub
AWS Systems Manager + Step Functions (custom)	Custom orchestration/tracking	Highly flexible	You must build and maintain everything	When you need bespoke workflows beyond Migration Hub capabilities
Spreadsheets / ITSM boards (Jira/ServiceNow)	Lightweight tracking	Familiar, quick start	Hard to govern at scale, weak automation/audit	Small migrations or early planning only
Azure Migrate	Migration hub on Azure	Integrated discovery/assessment/migration management in Azure	Azure-specific; different ecosystem	When Azure is your target cloud
Google Cloud migration tooling	GCP migration planning/execution	Integrates with GCP services	GCP-specific	When GCP is your target cloud
Third-party migration platforms	Cross-cloud or complex estates	Deep features, enterprise governance	Cost, vendor lock-in, integration complexity	When you need multi-cloud governance or specialized migration support

15. Real-World Example

Enterprise example (regulated, multi-wave migration)

Problem: A financial services company needs to migrate 200 applications from VMware to AWS with strict governance, auditability, and phased cutovers across regions and business units.
Proposed architecture:
AWS Organizations with separate accounts: security/logging, shared services, and workload accounts
AWS Application Discovery Service for inventory (where applicable)
Migration execution:
- AWS Application Migration Service (MGN) for server rehosting
- AWS DMS for database replication
AWS Migration Hub for application grouping and portfolio progress
Migration Hub Orchestrator for repeatable cutover workflows and pre/post checks
CloudTrail centralized for auditing changes and approvals
Why AWS Migration Hub was chosen:
A single program-level view across tools
Repeatable workflows for cutovers
Better audit alignment than spreadsheets
Expected outcomes:
Reduced cutover failures due to missed steps
Faster reporting to governance committees
Clearer ownership and fewer stalled migrations

Startup/small-team example (incremental modernization)

Problem: A startup has a monolithic app running on a small on-prem footprint. They need to move to AWS quickly but also want to refactor key endpoints into services over time.
Proposed architecture:
Initial rehost using EC2 (and possibly MGN depending on starting point)
Use AWS Migration Hub to track migration tasks and readiness by application
Use Migration Hub Refactor Spaces (where appropriate) to incrementally route traffic to new service components
Why AWS Migration Hub was chosen:
Lightweight tracking and visibility without building a custom system
A structured path to modernization while maintaining operational clarity
Expected outcomes:
Faster initial cloud move (rehost)
Controlled modernization roadmap
Better visibility for a small team managing many moving parts

16. FAQ

1) Does AWS Migration Hub migrate my servers or databases?
No. AWS Migration Hub primarily tracks and coordinates migrations. Use execution tools like AWS Application Migration Service (MGN) for servers and AWS DMS for databases.

2) Is AWS Migration Hub global or regional?
Migration Hub is Region-scoped for usage and visibility. Always confirm you’re in the correct Region in the console.

3) Can I use AWS Migration Hub without AWS migration tools?
Yes. You can use Migration Hub APIs to import tasks and update statuses from custom tools, but you must implement the integration.

4) What is a Progress Update Stream?
A logical grouping mechanism for status updates, often representing a tool/integration publishing migration updates.

5) What is a Migration Task?
A tracked unit of migration work (for example, a server, component, or activity) whose status can be updated over time.

6) How do I track an application with multiple servers?
Define an application grouping model and track component tasks consistently. Exact grouping features vary—verify current console capabilities and best practices in official docs.

7) Can multiple AWS accounts contribute to one Migration Hub dashboard?
Migration Hub is account-scoped. Multi-account consolidation typically requires a program design (role switching, centralized updates, or organizational processes). Verify current cross-account options in docs.

8) Is AWS Migration Hub free?
Migration Hub tracking has commonly been described as no additional charge, but you pay for related services and resources. Always verify on the official pricing page: https://aws.amazon.com/migration-hub/pricing/

9) Does Migration Hub support ITSM integration (ServiceNow/Jira)?
Not inherently as an ITSM tool, but you can integrate via APIs and automation to keep status synchronized.

10) What’s the difference between Migration Hub and Migration Hub Orchestrator?
Migration Hub provides tracking and visibility; Orchestrator focuses on coordinating multi-step workflows for migrations (capabilities vary by region/template).

11) What’s the difference between Migration Hub and AWS Application Discovery Service?
Discovery Service is for inventory and dependency discovery. Migration Hub is for tracking and coordinating migrations.

12) Should I standardize status definitions?
Yes. Without a shared definition of statuses (NOT_STARTED/IN_PROGRESS/COMPLETED), dashboards become misleading.

13) How do I audit who changed migration status?
Use AWS CloudTrail to audit API calls and console actions, and retain logs per compliance policy.

14) Can I automate status updates from CI/CD?
Yes. Use Migration Hub APIs in pipelines to update tasks based on deployment/migration milestones (with least-privilege IAM roles).

15) What’s the best way to start with Migration Hub?
Start with one pilot wave: – Define application boundaries – Track a small set of tasks consistently – Integrate with one execution tool (MGN or DMS) or use APIs – Establish reporting cadence and operational definitions

17. Top Online Resources to Learn AWS Migration Hub

Resource Type	Name	Why It Is Useful
Official documentation	AWS Migration Hub Docs – https://docs.aws.amazon.com/migrationhub/	Primary source for APIs, concepts, and workflows
Official product page	AWS Migration Hub – https://aws.amazon.com/migration-hub/	Overview of capabilities and positioning in AWS migration tooling
Official pricing page	AWS Migration Hub Pricing – https://aws.amazon.com/migration-hub/pricing/	Confirms current pricing model and notes
Pricing tool	AWS Pricing Calculator – https://calculator.aws/	Estimate end-to-end migration program costs (MGN/DMS/resources)
Related service docs	AWS Application Migration Service (MGN) – https://docs.aws.amazon.com/mgn/	Common execution tool paired with Migration Hub
Related service docs	AWS Database Migration Service – https://docs.aws.amazon.com/dms/	Database migration execution tool often tracked in Migration Hub
Related service docs	AWS Application Discovery Service – https://docs.aws.amazon.com/application-discovery/	Helps discovery and planning for migration programs
Architecture guidance	AWS Architecture Center – https://aws.amazon.com/architecture/	Reference architectures and patterns adjacent to migration programs
Official videos	AWS YouTube Channel – https://www.youtube.com/@amazonwebservices	Search for “AWS Migration Hub”, “Orchestrator”, “Strategy Recommendations”
Hands-on learning	AWS Skill Builder – https://skillbuilder.aws/	Official training content; search for Migration Hub and migration learning plans
Updates	AWS What’s New – https://aws.amazon.com/new/	Track announcements for Migration Hub capabilities and changes

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, architects, beginners	Cloud/DevOps tooling, migration basics, operational practices	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Students, engineers transitioning to DevOps	SCM/DevOps foundations, CI/CD, cloud operations	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud engineers, operations teams	Cloud ops, governance, reliability practices	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, platform engineers	Reliability engineering, operations, monitoring	Check website	https://www.sreschool.com/
AiOpsSchool.com	Operations and platform teams	AIOps concepts, automation, operational analytics	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training content (verify offerings)	Students and practitioners	https://rajeshkumar.xyz/
devopstrainer.in	DevOps coaching/training (verify offerings)	Engineers building hands-on DevOps skills	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps expertise platform (verify offerings)	Teams seeking short-term help or guidance	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support/training resources (verify offerings)	Ops teams and engineers	https://www.devopssupport.in/

20. Top Consulting Companies

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify exact portfolio)	Migration planning, DevOps enablement, delivery support	Migration factory setup, landing zone readiness, migration wave execution support	https://cotocus.com/
DevOpsSchool.com	Training and consulting (verify exact portfolio)	Skills enablement + project guidance	Migration runbook creation, DevOps toolchains to support migration delivery	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify exact portfolio)	Automation, cloud operations, migration support	CI/CD for migrated apps, IaC standardization, operational readiness checks	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before AWS Migration Hub

AWS fundamentals: IAM, Regions, VPC basics, EC2, EBS, S3
Networking: DNS, routing, VPN/Direct Connect fundamentals
Security: IAM roles/policies, CloudTrail, encryption basics
Operations: CloudWatch basics, logging, incident response
Migration fundamentals: the 6Rs, migration waves, cutover planning, rollback strategies

What to learn after AWS Migration Hub

AWS Application Migration Service (MGN): server replication/cutover patterns
AWS DMS + AWS SCT: database migration and schema conversion approaches
Landing zone design: AWS Organizations, multi-account strategy, shared services
Modernization: containers (ECS/EKS), serverless (Lambda), event-driven architectures
Governance: cost allocation, security guardrails, policy-as-code

Job roles that use it

Cloud Solutions Architect (migration focus)
Migration Engineer / Migration Factory Engineer
DevOps Engineer / SRE supporting migration waves
Cloud Program Manager / Technical Program Manager (TPM)
Security Engineer supporting migration governance

Certification path (AWS)

AWS certifications change over time; verify current tracks on the official site: – https://aws.amazon.com/certification/

Commonly relevant certifications: – AWS Certified Solutions Architect – Associate/Professional – AWS Certified SysOps Administrator – Associate – AWS Certified DevOps Engineer – Professional – AWS Certified Security – Specialty (for governance-heavy environments)

Project ideas for practice

Build a “migration tracker” that updates Migration Hub tasks from a GitHub Actions pipeline.
Create a wave-based migration template: define app grouping rules, status definitions, and dashboards.
Run a simulated migration program: 10 apps, 3 waves, each with tasks and acceptance criteria.
Extend the lab: attach resource attributes to tasks and generate a simple report via scripts.

22. Glossary

Migration and transfer: AWS category of services focused on moving workloads and data into AWS.
AWS Migration Hub: AWS service for tracking and coordinating migrations across tools and applications.
Application (migration context): A logical grouping of components (servers, databases, services) that move together for a business function.
Progress Update Stream: A named channel representing a source of task updates (tool/integration).
Migration Task: A unit of work tracked in Migration Hub with statuses and progress percentage.
Rehost: “Lift-and-shift” move with minimal changes (often to EC2).
Replatform: Make small platform optimizations during migration (for example, move to managed services with minimal code changes).
Refactor: Redesign/re-architect for cloud-native benefits (often highest effort).
Retire: Decommission systems no longer needed.
Retain: Keep as-is (for now), often due to constraints.
Cutover: The moment traffic/users switch to the AWS-hosted version.
Migration wave: A batch of applications moved together in a planned time window.
Orchestration: Coordinating multi-step processes with dependencies, automation, and approvals.
CloudTrail: AWS service that logs API activity for audit and governance.

23. Summary

AWS Migration Hub is AWS’s service for migration program tracking and coordination. It helps teams manage migrations at the application level, consolidate status across tools, and (optionally) orchestrate multi-step migrations and support planning/modernization capabilities.

Why it matters: migrations fail in the gaps—handoffs, sequencing, governance, and visibility. AWS Migration Hub reduces those gaps by standardizing how progress is tracked and communicated across teams.

Cost and security highlights: – Migration Hub tracking is commonly positioned as no additional charge, but real costs come from the migration execution services and the AWS resources you run (always verify pricing on the official page). – Use IAM least privilege and CloudTrail auditing to keep migration governance clean and compliant.

When to use it: whenever you have multiple applications, multiple teams, or a multi-wave migration program where consistent status and repeatable workflows reduce risk.

Next learning step: pair this with hands-on execution services—start with AWS Application Migration Service (MGN) or AWS DMS, and design an application grouping and wave model so Migration Hub becomes your program’s reliable source of truth.

Category