Business Challenge
The migration is approved, the discovery phase starts on Monday, and the runbook says to deploy AWS Application Discovery Service. Someone opens the console to enable it and finds they cannot. Not a permissions problem, not a Region problem — the service stopped accepting new customers on 7 November 2025.
This is a more common failure than it sounds. Discovery tooling is the part of a migration that gets chosen once, written into a methodology document, and then reused for years by people following the document rather than re-evaluating the tool. A service closing to new customers does not invalidate the runbook loudly. It fails at the moment someone tries to use it, which is the moment the schedule already started.
Application Discovery Service closed to new customers. AWS is explicit that existing customers “can continue using the service to complete their ongoing discovery projects, which typically have a 4-month lifecycle”, and that security and reliability maintenance continued, with no new features.
Given that four-month figure and a November 2025 cutoff, essentially every project that was in flight has since ended. Treat the service as unavailable when planning new work, and check rather than assume if you inherited an account that may already have it.
AWS Migration Hub did not close. It is still the console where servers are grouped into applications and migration status is tracked, and it still owns the home Region. Conflating the two is the most common misreading of this change.
AWS names AWS Transform as the alternative, describing it as providing discovery and assessment through “agent-based and agentless collectors” along with automated dependency mapping and wave planning.
The transition is deliberately undramatic: “no data migration required”, existing projects run to completion, and new projects start directly in the new service. There is no cutover to plan, which is welcome, but it also means there is no forcing event that makes a team notice the change. Nothing breaks. The old service simply stops being an option for anyone who did not already have it.
It would be easy to treat this as a tooling swap and move on. That misses the point worth carrying: the two decisions that determined whether discovery produced usable data were never properties of Application Discovery Service. They were properties of how you collect and where the data lands, and both survive intact into any successor.
Those two are the subject of the rest of this post, because they are what a reader starting a discovery phase next quarter still has to get right.
Architecture
What an appliance cannot see
Agentless collection deploys one appliance into vCenter and discovers every VM and host it manages. Nothing is installed on the workloads, nothing needs a change window, and nothing needs the cooperation of the team that owns each server. For a large VMware estate that is an enormous practical advantage, and it is why agentless is almost always where a discovery phase starts.
The limit is structural, and AWS states it plainly: the collector “cannot ‘look inside’ each of the VMs, and as such, cannot figure out what processes are running on each VM nor what network connections exist” on them. It sees each machine from the hypervisor's vantage point — configuration, CPU, RAM, disk I/O — and not from inside the operating system.
Everything else in the comparison follows from that one fact. No visibility into the OS means no process inventory, which means you cannot answer “what is this server actually running” from agentless data alone. It also means a coarser sampling interval: roughly 60 minutes, against roughly 15 seconds for an agent.
What an agent costs you to get it
An agent installed on the server returns what the appliance cannot: running processes, inbound and outbound network connections, and detailed time-series performance data. Only agent data supports time-series export and export to Amazon Athena for further exploration — agentless gives you the latest utilisation snapshot.
It also covers physical servers, which the vCenter appliance cannot see at all. Any estate with bare-metal database servers or appliances outside VMware has a coverage gap that agentless collection cannot close by itself.
The cost is deployment. An agent is per server, on Windows or Linux, which means change approval, a package, a rollout, and an owner for every machine that refuses to take it. On a two-thousand-server estate that is a project in its own right, running before the migration project can start.
The answer is usually both, deliberately
These are not competing choices to be settled once. For VMs hosted on VMware you can run both simultaneously. The pattern that works is to blanket the estate with agentless collection for coverage, then install agents selectively where the questions demand inside-the-OS answers — the applications nobody can describe, the servers whose dependencies are contested, the candidates for replatforming rather than rehosting.
Deciding which servers earn an agent is the actual planning work. Installing agents everywhere is a way of not making that decision, and it usually stalls.
Why This Architecture Holds Up
Migration Hub has a home Region, and it is treated by most teams as a console setting. It is not. AWS's own framing: “All discovered data is stored in your AWS Migration Hub home Region. Therefore, you must set your home Region in the Migration Hub console or with CLI commands before performing any discovery and migration activities.”
Two consequences make this a decision rather than a default.
It is the only Region that holds the data. Every server profile, every utilisation metric, every observed connection lands there. If your organisation has data residency obligations, the home Region is where they apply — and discovery data is not innocuous. A complete inventory of your estate with its network connection graph is one of the more sensitive datasets you will produce about your own infrastructure.
It gates the tooling. Agents, connectors and imports work in the selected home Region only. A collector pointed at a different Region does not produce a partial result or a warning that a reviewer might catch — the arrangement simply does not work, and the failure surfaces during the discovery window rather than before it.
The practical consequence is a sequencing rule. The home Region has to be agreed with whoever owns data residency before the first collector is deployed, because after that the data is already somewhere, and moving it is not a setting.
Key Architecture Decisions
| Decision | Choose this when | What it costs you |
|---|---|---|
| Agentless first, agents selectively | Default. A VMware estate where coverage matters more than depth on day one | You must still decide which servers earn an agent, and that decision needs an owner |
| Agents broadly | Process inventory or time-series data is needed across the estate, or much of it is physical | A per-server rollout with change approval, running before discovery can finish |
| File-based import | A trustworthy CMDB or third-party tool already holds the inventory | Profile data only, a single snapshot, and it inherits every error in the source |
| Home Region chosen deliberately | Always, before any collection | One conversation with whoever owns data residency, early |
| Home Region left as a default | Never | Discovery data lands somewhere nobody chose, and collectors silently fail elsewhere |
The row worth arguing about is the second. Teams reach for broad agent deployment because the data is richer, and richer data feels safer when the estate is poorly understood. But an agent rollout across thousands of servers is itself a migration-scale project, and it delays the discovery it was meant to serve. Coverage now with depth where it is earned beats depth everywhere in six months.
Closing Thought
The useful lesson here is not which discovery service to use this quarter. It is that migration methodology documents name tools, and tools have lifecycles that the documents do not track. A runbook that says “deploy Application Discovery Service” was correct for years and became wrong on a specific Tuesday, without changing a word.
Write methodology in terms of decisions, not products. “Collect agentlessly for coverage, install agents where you need process-level detail, and fix the data residency Region before collecting anything” is still true after the product named in the runbook closed to new customers. “Deploy Application Discovery Service” is not, and nothing in the document told you.
That is the durable form. The appliance-versus-agent trade exists because an appliance cannot see inside a virtual machine, which is a fact about virtualisation and not about any AWS service. The home Region decision exists because discovery data has to live somewhere and someone owns that choice. Both statements survived the service being closed, and both will survive whatever replaces its replacement.
Official AWS Reference
- AWS Application Discovery Service availability change — the closure date, what happens to existing customers, and the AWS Transform transition
- What is AWS Application Discovery Service? — the home Region requirement and the agentless-versus-agent comparison table
- Migration Hub home Region — AWS Migration Hub User Guide
- What is AWS Transform? — the recommended service for new discovery projects
- Wave planning — AWS Prescriptive Guidance, for what the discovery data is ultimately for
Comments