If you’ve searched for AWS Migration Hub recently, you’ve probably found plenty of guides explaining how to use it. Most of them are now out of date. On 7 November 2025, AWS stopped accepting new customers for Migration Hub, along with the tools that sat around it: Application Discovery Service, Strategy Recommendations, Refactor Spaces, Orchestrator and Migration Hub Journeys. Existing customers can finish the projects they started. Anyone starting a migration today can’t sign up.
That doesn’t change what a good migration needs. It changes which tools you reach for, and it’s a useful moment to separate the tooling from the work the tooling was meant to support.
What AWS Migration Hub did
Migration Hub was a single place to follow a migration to AWS. It didn’t move anything itself. Instead it pulled together information from the services that did:
- Discovery — Application Discovery Service collected an inventory of your servers, their specifications, their utilisation and which servers talked to each other.
- Planning — Strategy Recommendations suggested a migration approach per application (rehost, replatform, refactor and so on), and the hub grouped servers into applications.
- Tracking — as tools such as AWS Application Migration Service and AWS Database Migration Service moved workloads, the hub showed the status of each application in one dashboard.
- Orchestration and refactoring — Orchestrator provided templated migration workflows, and Refactor Spaces helped route traffic between old and new versions of an application while it was broken up piece by piece.
Its value was visibility: one view of a migration that was otherwise spread across several tools and spreadsheets.
What replaces it: AWS Transform
AWS now points new migration projects to AWS Transform, launched in May 2025. It covers the same ground as Migration Hub and the tools around it — discovery and assessment, dependency mapping, wave planning and tracking — and adds AI agents that do much of the analysis. It also reaches into modernisation work that Migration Hub never covered, such as VMware migrations, Windows and .NET modernisation, and mainframe applications.
Two points are worth knowing before you plan around it:
- Existing Migration Hub projects keep working. No data needs moving; AWS is keeping the service available for customers who were already using it.
- The services that do the moving are unaffected. AWS Application Migration Service (for servers) and AWS Database Migration Service (for databases) remain the standard tools for actually shifting workloads.
What the tooling never did for you
Migration Hub’s retirement is a good reminder that the dashboard was never the hard part. The migrations that run late and over budget rarely fail because of tracking. They fail because of things found halfway through:
- Dependencies nobody mapped. A reporting job on a server everyone forgot about, a hard-coded IP address, a licence tied to specific hardware.
- A landing zone that wasn’t ready. Accounts, networking, identity and logging need to exist — and be secure — before the first workload arrives, not be built around it.
- One strategy applied to everything. Most estates need a mix: some systems rehosted to get off ageing hardware quickly, some replatformed onto managed services, a few retired altogether.
- No agreed cutover plan. How much downtime each system can tolerate, who signs off, and how you roll back if something goes wrong.
Tools like AWS Transform make discovery faster and the plan easier to track. They don’t decide how much downtime your payments system can take, which regulator needs to hear about the change, or whether that forgotten server should move at all. Those decisions sit with people who know the business.
How to plan an AWS migration now
For a UK business starting today, a sensible sequence looks like this:
- Inventory and dependencies first. Use AWS Transform’s discovery, or a lighter manual inventory for a small estate, to get every server, database and integration on one list — with owners.
- Choose a strategy per application. Rehost, relocate, replatform, refactor, repurchase, retire or retain — the 7 Rs — decided system by system on cost, time and risk.
- Build the landing zone before anything moves. Multi-account structure, networking, identity and logging, set up as code so it can be reviewed and repeated.
- Plan waves and cutovers. Group systems that depend on each other, agree downtime windows and rollback steps, and move the least risky wave first.
- Move, then prove it. Use Application Migration Service and Database Migration Service to move workloads, then test each one in AWS before the old version is switched off.
If you’re in financial services, add one more step at the start: check what your migration means for your important business services and your third-party risk obligations, so the FCA conversation happens before the move, not after it.
Where we fit
A fixed-fee Cloud Migration Assessment covers steps one to four: the inventory and dependency map, a strategy for each application, the landing zone design and a sequenced migration plan — priced before we start, with a fixed price per workload for the move itself.
Frequently asked questions
Can I still use AWS Migration Hub? Only if your account was already using it before 7 November 2025. New customers can’t sign up; AWS recommends AWS Transform instead.
Does AWS Application Migration Service still work? Yes. Application Migration Service and Database Migration Service are not part of the change and remain the standard tools for moving servers and databases to AWS.
Do I need AWS Transform to migrate to AWS? No. It speeds up discovery and planning, especially for larger or VMware-based estates, but a small estate can be inventoried and planned without it. The decisions that matter most — strategy, landing zone, cutover — still need people who understand the business.