---
title: Biggest Mistakes Teams Face During an AWS Migration (and How to Dodge Them)
description: July 2026: nine migration mistakes that still show up after Migration Hub closed to new customers on November 7, 2025, covering AWS Transform MGN (formerly AWS Application Migration Service), DMS, AWS Transform, Org/SCPs, FinOps dual-run costs, and Migration Lens.
url: https://www.joinhorizon.co/blog/common-aws-cloud-migration-mistakes-2026/
datePublished: 2026-05-08T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: palaniappan-p
category: Cloud Architecture
tags: aws-migration, cloud-migration, aws-organizations, finops, aws-security, landing-zone, how-to-guide
---

# Biggest Mistakes Teams Face During an AWS Migration (and How to Dodge Them)

> July 2026: nine migration mistakes that still show up after Migration Hub closed to new customers on November 7, 2025, covering AWS Transform MGN (formerly AWS Application Migration Service), DMS, AWS Transform, Org/SCPs, FinOps dual-run costs, and Migration Lens.

**July 19, 2026.** If your architecture review still opens with “we already know our apps, start cutting over,” speed does matter, but **undocumented dependencies** do not get cheaper after the first outage. The product shift still stands: **AWS Migration Hub is [no longer open to new customers as of November 7, 2025](https://docs.aws.amazon.com/migrationhub-strategy/latest/userguide/migrationhub-availability-change.html)**, and AWS points net-new planning at **[AWS Transform](https://aws.amazon.com/transform/)**. Net-new runbooks that **default to Migration Hub onboarding** without that caveat are stale.

This post names **nine** mistakes we still see in architecture reviews and MOU workshops, each framed with **what breaks**, **what to do instead**, and **where the advice fails**. It does not replace your compliance pack or contractual RTO/RPO; it is an execution-level gut check.

Recommendations cite **published AWS pathways** dated or version-stable at link time ([AWS Transform MGN](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html), [Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html), [Migration Lens](https://docs.aws.amazon.com/wellarchitected/latest/migration-lens/), [Organizations SCP concepts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)).

> **Composite review pattern:** Many mid-market software and shared-services portfolios we review share a common silhouette: VMware or mixed hypervisors, dozens to low hundreds of stateful VMs, insistence that “engineering already knows flows,” NAT-heavy egress, dual stacks during parallel run. **Finance surprise** shows up first in networking and NAT line items rather than EC2 SKU choice. The figure is **illustrative**, assembled from repeating themes, and is not a cited metric for any single tenant.

Quantified grounding for leadership slides: use **current** figures from the official **[Migration Acceleration Program](https://aws.amazon.com/migration-acceleration-program/)** page. Incentive structures change, so do not round “typical credits” from memory.

> **Reproduce this:** Program gate worksheet: [`examples/architecture-blog-2026/migration-readiness/checklist.md`](https://www.joinhorizon.co/examples/architecture-blog-2026/migration-readiness/checklist.md). Dual-run cost model: [`examples/architecture-blog-2026/migration-cost-surprises/dual-run-cost-worksheet.md`](https://www.joinhorizon.co/examples/architecture-blog-2026/migration-cost-surprises/dual-run-cost-worksheet.md).

## Mistake 1: Migrating before the multi-account / SCP backbone exists

**Failure mode.** Applications land into a heroic “experiment” account without central logging, SCP guardrails for newly risky APIs, consistent break-glass, or segregation for prod vs non-prod. Six months later, **every refactor is a tenancy migration**.

**Mitigation.** Stand up Organizations, logging archive, delegated admin for security services, baseline **SCPs** for deny patterns you cannot afford even during migration chaos, then attach workloads ([Organizations policy concepts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)).

**Where this hurts velocity.** Oversized SCP design before workloads exist can block legitimate sandbox automation. Start with narrowly scoped SCPs aligned to CIS-style guardrails, not a hundred bespoke denies per app team.

For sequencing strategy with the migration Rs, revisit **[Choosing the Right AWS Migration Strategy](https://www.joinhorizon.co/blog/aws-migration-strategy-choose-right-approach/)**.

## Mistake 2: Skipping machine-readable dependency evidence

**Failure mode.** Sticky notes substitute for topology. Cutover rehearsal passes in staging, fails in prod because **batch feeder #3 never listed DNS**.

**Mitigation.** Treat discovery as a product deliverable: owners, **application groups**, connection maps, data-class tags. **AWS Transform** is the current AWS-side umbrella for AI-assisted inventory and modernization planning where Migration Hub net-new onboarding does not apply post-**November 7, 2025** ([Transform getting started](https://docs.aws.amazon.com/transform/latest/userguide/getting-started.html)). Pair with your CMDB truth source. Transform accelerates; it does not replace contracts with app owners.

**Counter-case.** Small **10 to 20** VM estates with one architect who truly holds the graph can run lean; document the exception in the risk register.

## Mistake 3: Defaulting every workload to rehost (lift-and-shift)

**Failure mode.** Everything lands on Amazon EC2 as a **1:1** VM clone. You gain exit from the datacenter but keep **undifferentiated heavy lifting**: patch cadence, license friction, static scaling.

**Mitigation.** Classify every candidate with the **7 Rs** (see our **[migration strategy guide](https://www.joinhorizon.co/blog/aws-migration-strategy-choose-right-approach/)**). Use **[AWS Transform MGN](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html)** for **batch rehost** where replication-based cutover fits; schedule modernization waves after stable bills and observability exist.

**Where lift-and-shift still wins.** Regulated cutover windows, third-party ISV binaries you cannot touch, or evidence that **refactor-first** invalidates support contracts.

## Mistake 4: Database cutover without rehearsal-grade DMS discipline

**Failure mode.** Teams assume **native backups** equal **continuous replication**. Cutover Sunday hits **CDC lag**, **collation** mismatch, or **sequence** drift.

**Mitigation.** Run **[AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)** tasks (or engine-native **blue/green** where supported) through **full** fail-forward and fail-back drills. Measure **RPO** under load, not idle.

**When DMS is the wrong flex.** Tiny databases where **native snapshot + short outage** is contractually acceptable; over-automation costs calendar time.

## Mistake 5: NAT gateway and cross-AZ traffic “surprises” while parallel-running

![Architecture diagram of application traffic using a NAT gateway contrasted with AWS API traffic using a VPC endpoint](../../assets/images/blog/common-aws-cloud-migration-mistakes-2026-egress.webp)

_Figure: the parallel-run egress choice in the article. A default route through NAT is how AWS API traffic picks up a surprise bill. Interface endpoints keep those API calls off the public NAT path. The arrows are alternatives, not a sequence. Cross-AZ charges stay in the article. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/common-aws-cloud-migration-mistakes-2026/egress.drawio)._

**Failure mode.** Dual environments, chatty microservices, default routes through **NAT**, **cross-AZ** fan-out for “HA,” no **interface endpoints** for heavy AWS APIs. Cost Explorer spikes while leadership still focuses on instance sizes.

**Mitigation.** Model **data transfer** and NAT as **first-class** line items before cutover ([Cost Optimization Pillar](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html)). Add endpoints where policy allows; align AZ affinity for chatty tiers; set **Cost Anomaly Detection** before parallel run. Our **[migration cost surprises](https://www.joinhorizon.co/blog/aws-migration-without-cost-surprises/)** piece expands on the FinOps side.

## Mistake 6: “Cloud security” as VM security group copy-paste

**Failure mode.** Broad **security groups**, secrets in user-data, shared instance roles, no **AWS Secrets Manager** rotation story, **IMDSv1** tolerance.

**Mitigation.** Re-express controls with **IAM roles per workload**, **least-privilege** task roles, **Secrets Manager** or **Parameter Store** hierarchy, **VPC endpoints** for sensitive API paths, and **GuardDuty/Config** delegated admin from day one, not “after migration stabilizes.”

## Mistake 7: Roadmaps that still treat Migration Hub as the default for **new** programs

**Failure mode.** Third-party SOWs say “Phase 1: activate Migration Hub.” **New** customers cannot follow that path after **November 7, 2025** per AWS documentation.

**Mitigation.** Update procurement templates: **AWS Transform** for planning/modernization assistance; **AWS Transform MGN** for lift-and-shift execution; **DMS** for databases; **MAP** where funding applies. See **[MAP SMB practical guide](https://www.joinhorizon.co/blog/aws-migration-acceleration-program-map-smb-guide/)** for qualification realism.

**Existing** Migration Hub tenants should plan **only** what their signed architecture allows. No blind rip-and-replace.

## Mistake 8: MAP tags and chargeback afterthoughts

**Failure mode.** Eligible spend never maps to **MAP-approved tags**; finance cannot reconcile partner incentives; engineering blames “paperwork” while credits slip a quarter.

**Mitigation.** Define **tag policy** during wave zero, align service owners before first large bill, automate **CUR** dashboards, and rehearse monthly **MAP** evidence collection with whoever signs the partner attestation ([MAP overview](https://aws.amazon.com/migration-acceleration-program/)).

## Mistake 9: Cutover waves sequenced by team politics, not dependency graph

![Architecture diagram of identity and shared services migrating before business applications](../../assets/images/blog/common-aws-cloud-migration-mistakes-2026-order.webp)

_Figure: the dependency order in the article. Identity, DNS, observability, and shared data move before the business applications that use them. Team preference is not the sequence. The 7 Rs and the MGN cutover are earlier diagrams. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/common-aws-cloud-migration-mistakes-2026/order.drawio)._

**Failure mode.** Friendly teams go first; **identity** and **payments** stacks go last, but **everything** hid behind that AD connector you have not migrated.

**Mitigation.** Build a **critical path** DAG: identity, DNS, observability buses, shared databases, integration buses, then hang business applications. Publish the graph; defend it in steering.

## When modernizing before the move is wrong

> **Counter-case we have seen approved:** A batch settlement platform with a fixed regulatory freeze could not absorb large refactors pre-cutover. The **right** play was **AWS Transform MGN rehost** into a locked VPC, **read-only** observability parity, and a **post-go-live** refactor program with budget reserved, instead of six months of blocked migration for ideal microservices.

## Opinionated substitutes

| Anti-pattern                        | Prefer (when conditions hold)                                    | Trade-off                                                |
| ----------------------------------- | ---------------------------------------------------------------- | -------------------------------------------------------- |
| Lift everything with ad-hoc scripts | **AWS Transform MGN** replication + launch templates | Agent footprint and change control on source hypervisors |
| Snapshot-only DB stories            | **DMS** or engine-native **blue/green** with measured RPO        | Operational complexity of replication                    |
| Default public egress for AWS APIs  | **VPC interface endpoints** where policy allows                  | Endpoint hourly + data processing charges                |
| Single prod account for “speed”     | **Workload accounts** + **SCP** guardrails                       | Up-front landing zone effort                             |

## Reproduce the guardrails (no mystery URLs)

Also run an **[AWS Well-Architected Migration Lens](https://docs.aws.amazon.com/wellarchitected/latest/migration-lens/)** workload review after each major wave. Cross-check retirement assumptions against **[AWS service lifecycle](https://docs.aws.amazon.com/general/latest/gr/service-lifecycle.html)** and **[AWS Transform MGN](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html)** (Transform callouts in MGN docs change, so keep runbook names synchronized).

**Legacy trap:** runbooks that still install **AWS Server Migration Service (SMS)** agents. SMS is **not** the current lift-and-shift path AWS documents for these scenarios. Default to **AWS Transform MGN** and verify **current** availability in your partition (commercial vs GovCloud) against official guides such as **[Migration tools for application mobility](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-tools/app-mobility-ams.html)**.

## What to do this week

1. **Inventory** every external design doc for “Migration Hub phase 1” language, then update with **November 7, 2025** policy or retire it.
2. **Route** net-new portfolio planning questions to **AWS Transform** + **Migration Lens** evidence, not forum posts from 2023.
3. **Model** NAT, cross-AZ, and endpoint costs for **parallel run** with **Cost Anomaly Detection** enabled; see **[migration cost surprises](https://www.joinhorizon.co/blog/aws-migration-without-cost-surprises/)**.
4. **Rehearse** one **DMS** or **blue/green** fail-forward with production-like **RPO** measurement.
5. **Align** MAP tagging with finance **before** the next major funding checkpoint; see the **[MAP SMB guide](https://www.joinhorizon.co/blog/aws-migration-acceleration-program-map-smb-guide/)** if you qualify that path.

### If you only do one thing

**Publish a single dependency graph with named owners and cutover order**, then defend it in steering. Everything else (tools, credits, endpoints) hangs off that graph.

## Related reading

- **[How to choose the right AWS migration strategy](https://www.joinhorizon.co/blog/aws-migration-strategy-choose-right-approach/)**: 7 Rs and sequencing.
- **[AWS migration without cost surprises](https://www.joinhorizon.co/blog/aws-migration-without-cost-surprises/)**: parallel-run FinOps.
- **[MAP guide for SMBs](https://www.joinhorizon.co/blog/aws-migration-acceleration-program-map-smb-guide/)**: incentive realism.
- **[How to evaluate an AWS managed services provider](https://www.joinhorizon.co/blog/how-to-evaluate-aws-managed-services-provider/)**: when outside delivery helps.
- **[When you need an AWS MSP](https://www.joinhorizon.co/blog/when-do-you-need-aws-managed-services-provider/)**: guardrails vs staff aug.

## What this post does not cover

- **Industry-specific** compliance mapping (HIPAA, PCI) beyond pointing to your control matrix.
- **VMware Cloud on AWS** commercial negotiations or partner-specific MAP math; verify with AWS and your partner SA.
- **Region-by-region** service availability; features differ, so validate in **Service endpoints** lists before cutover weekends.
- **DMS Fleet Advisor** or other narrowly scoped tooling beyond a general DMS rehearsal; confirm current GA/deprecation notices in AWS documentation before adopting new inventory agents.

---

**Need a second pair of eyes on wave planning, landing zone guardrails, or MAP evidence?** [FactualMinds is an AWS Select Tier Services Partner](https://www.joinhorizon.co/aws-partner/). [Tell us what you are migrating](https://www.joinhorizon.co/contact-us/).

## FAQ

### Should every net-new migration program anchor on Migration Hub dashboards in 2026?
No. Official documentation states Migration Hub stopped accepting new customers on November 7, 2025, and directs net-new entrants toward AWS Transform for similar planning and modernization assistance. Existing Migration Hub deployments can continue, but greenfield roadmap decks that still cite “stand up Migration Hub first” without that caveat are materially out of date. Always confirm current console availability against the latest AWS Migration Hub user guide before budgeting headcount.

### Is lift-and-shift with AWS Transform MGN always preferable to refactoring first?
Not when business constraints require refactoring before contractual cutover, database collations change, or you need app-level changes before the workload can tolerate the cloud network model. AWS Transform MGN shines for batch rehost and continuous replication; it will not fix application logic that cannot survive a cutover window. When regulatory windows ban big-bang refactors, prefer staged rehost plus post-migration modernization, accepting longer-run cost for compliance. Do not confuse MGN with AWS Managed Services (also abbreviated AMS).

### What is the fastest way to turn this checklist into an argument instead of action?
Buy a partner presentation that lists nine mistakes but never ties each line item to an owner, date, cost account, or evidence artifact. Effective programs map each mitigation to RACI roles, tagging policy, MAP eligibility (when applicable), and an exit criterion for exiting double-run budgets.

### Can we defer Organizations and SCP guardrails until after the first workloads land to save velocity?
You can, once. Teams that postpone central governance almost always refactor accounts under live traffic later, which burns more cycles than delaying applications by a sprint to wire baseline SCP deny lists, logging accounts, and break-glass patterns. Exceptions exist only for proofs-of-concept that never touch PHI/PCI subnets and terminate within weeks.

---

*Source: https://www.joinhorizon.co/blog/common-aws-cloud-migration-mistakes-2026/*