Introduction
You can't migrate what you haven't mapped. Teams routinely plan a cloud move around a server inventory spreadsheet last updated two years ago. Then they discover a shared database, a hardcoded file path, or a cron job quietly linking two "unrelated" applications together.
Move the wrong piece first, and you break something else.
AWS Application Discovery Service (ADS) is AWS's answer to that blind spot. It's a migration-planning service that collects infrastructure, utilization, and dependency information from on-premises servers, virtual machines, and databases, then feeds that data into AWS Migration Hub for analysis.
This article covers how ADS actually works, what the Discovery Agent and Agentless Collector do differently, how to pick a collection method, and what changed after AWS deprecated the old Discovery Connector in November 2025.
Key Takeaways
- Application Discovery Service (ADS) supports discovery and migration planning; it does not execute the migration itself
- Three collection paths exist today: Discovery Agent, Agentless Collector, and file-based or partner-assisted import
- Pick the path based on data depth needed, environment type, and deployment permissions
- Discovery Connector support ended November 17, 2025. Always verify current AWS documentation before deploying
What Is AWS Application Discovery Service?
ADS builds an inventory of your on-premises environment: servers, virtual machines, applications, databases, configurations, resource utilization, and the network relationships connecting them. AWS designed it specifically to answer one question before a migration starts: what do we actually have, and what depends on what?
That question matters more than it sounds. An incomplete inventory, or a dependency nobody documented, leads directly to:
- Incorrect migration sequencing (moving an app before the system it depends on)
- Wrong instance sizing based on guessed, not measured, utilization
- Unplanned downtime when a "standalone" server turns out not to be
- Cloud costs that don't match pre-migration estimates
ADS and Migration Hub Aren't the Same Thing
ADS collects or imports the discovery data. Migration Hub is where you view it: a central console for seeing discovered resources, grouping them into applications, and tracking migration progress across AWS tools like Database Migration Service. Think of ADS as the data collector and Migration Hub as the dashboard.
What ADS captures depends on the collection method. Typical data includes:
- Host identity and operating system details
- CPU, memory, and storage utilization
- Running processes and network connections
- Database engine or schema information
Not every method captures every category. Confirm current coverage against AWS documentation before you lock a migration plan.
What ADS Is Not
The boundaries are clear:
- It's not a general-purpose application performance monitoring platform
- It's not a complete dependency-mapping replacement for every environment type
- It's not an automated migration execution tool — it informs the plan, it doesn't carry it out
How AWS Application Discovery Service Works
The workflow follows a fairly linear path, though it's rarely a one-time exercise.
- Select a Migration Hub home Region — this is where your discovery and planning data lives, regardless of which Region you eventually migrate workloads into
- Define the discovery scope — which servers, applications, and databases need coverage
- Choose a collection method — Agent, Agentless Collector, or import
- Configure permissions and connectivity — IAM roles, credentials, network access
- Collect data and let it accumulate over days or weeks
- Review findings in Migration Hub, then build migration groups and sequencing priorities
Discovery data is transmitted to AWS and stored in your selected home Region, then accessed through the console, APIs, or Migration Hub's grouping and export workflows. Confirm current storage and export behavior directly in AWS documentation, since service details shift.
Using the Data to Make Decisions
Once collected, this data supports several planning functions:
- Sequencing migrations around dependencies
- Grouping workloads into applications
- Right-sizing target resources
- Planning database moves
- Flagging systems that need a closer look before anyone touches them
Cloudtech's own discovery work has turned up exactly this kind of surprise. In one pre-migration check, a hardcoded file path linking an ERP system to an internal reporting database surfaced only after discovery ran. Migrating the ERP alone would have broken reporting and caused downtime nobody had planned for.
In a separate healthcare engagement, discovery revealed a patient-scheduling system quietly tied to an old on-premises SQL Server used for reporting. Neither dependency was documented anywhere.
Discovery isn't a one-time snapshot. Start with broad inventory coverage, validate what the data shows with the people who actually own those applications, and refresh it whenever infrastructure changes. A dependency map from six months ago may already be wrong.
Security Comes First, Not Last
Before any collection starts, nail down:
- Least-privilege IAM permissions scoped to what the task actually needs
- Approved network paths for agent or appliance traffic
- Controlled access to source servers or vCenter
- Protection for the infrastructure data you collect — it's a map of your whole environment
- Early coordination with security and compliance teams, not after deployment
Discovery Methods and When to Use Each
AWS offers three practical discovery paths. Pick the wrong one and you spend time later on reinstallation or rework.
Discovery Agent
Software installed directly on individual physical or virtual servers. It collects deeper host-level detail: processes, performance metrics, and network connections where supported.
The trade-off is operational weight. Installing an agent means managing credentials, checking OS compatibility, handling its lifecycle, and reviewing any resource or network impact on the host. It's the right call for:
- Critical servers where process-level visibility actually matters
- Environments where dependency detail outweighs deployment effort
- Workloads that need continuous collection during migration planning
Agentless Collector
An AWS-provided virtual appliance, usually deployed to cover VMware infrastructure plus supported database, analytics, or network data, without installing anything on individual servers.
It simplifies broad inventory coverage but generally surfaces less host-level detail than an installed agent. Module and platform limits change, so check AWS documentation before you scope a project around it. It fits well when:
- You're doing VMware-first discovery across a large estate
- You need initial inventory fast
- Installing software on every server isn't realistic or permitted
File-Based and Partner-Assisted Import
Existing CMDB exports, inventory spreadsheets, or AWS Partner tool data can be imported when direct collection isn't practical.
The catch: imported data only helps if it is complete, current, correctly mapped to supported fields, and able to show real application dependencies, not just a list of hostnames.
| Method | Best For | Trade-Off |
|---|---|---|
| Discovery Agent | Deep server-level insight | Requires install, credentials, lifecycle management |
| Agentless Collector | Broad VMware-centric coverage | Less host-level detail |
| File/Partner Import | Reliable inventory already exists | Quality depends entirely on source data |
One direct clarification: the Agentless Collector is not the same thing as the older Discovery Connector. AWS ended support for the Discovery Connector, and new collection should not rely on it. More on that in the next section.
Benefits and Use Cases
ADS replaces guesswork with a documented inventory. That inventory is especially valuable when you have undocumented servers, legacy systems, or business applications stacked on top of each other over the years.
Common planning use cases:
- Dependency-aware migration wave sequencing
- Application grouping by business function
- Workload prioritization based on risk and criticality
- Database assessment ahead of a move
- Flagging systems for rehost, replatform, refactor, retain, or retirement decisions
Utilization and configuration data feeds into AWS sizing and cost-estimation work. Tools like AWS Migration Evaluator can turn ADS discovery data into projected costs, right-sizing recommendations, and TCO comparisons. Treat that output as a planning input, not a guaranteed forecast.
Beyond migration prep, ADS data also supports:
- Data center consolidation
- Application portfolio rationalization
- Capacity planning
- Modernization readiness assessments
For SMBs specifically:
- Start with a clearly defined application set, not your entire estate at once
- Document business owners and criticality for each application before collecting data
- Validate every discovered relationship with the people who actually run that system
- Don't collect discovery data without a migration or modernization decision attached to it. Data without a purpose just becomes clutter
Limitations, Pricing, and Current Service Status
No discovery method is complete on its own, and ADS has real limits worth planning around.
Known Limitations
- Supported platforms and collection modules vary and change over time
- Agentless methods may not expose every process or network connection a server is handling
- Imported data can be incomplete or stale
- Every discovery finding still needs human validation before it drives a decision
Implementation also carries real complexity:
- Home Region selection and IAM configuration
- Source-environment access and network connectivity
- Agent or appliance deployment
- Ongoing coordination with infrastructure owners
None of that is a single afternoon's work.
Service Status You Need to Know
AWS stopped accepting new ADS customers as of November 7, 2025, though existing customers can continue ongoing projects. Separately, support for the legacy Discovery Connector ended November 17, 2025, with historical data remaining accessible but no new collection through it. If you're planning new discovery work, confirm account eligibility first. Open access is no longer a given.
Pricing Reality Check
AWS's own pricing matrix lists ADS itself as having no direct service charge. That does not make the whole exercise free. Supporting resources such as an S3 bucket for database metadata, plus storage and request charges, bill separately under standard AWS rates. Do not treat ADS as a zero-cost initiative without accounting for what sits underneath it.
Before you start, check:
- Supported operating systems and virtualization platforms for your chosen method
- Current collector modules against your environment
- AWS Region availability for your home Region choice
- IAM policies scoped to least privilege
- Any recent service deprecations or availability changes
Getting Started Checklist
- Define scope and objective: which applications, servers, databases, and business owners does this project need to cover, and what migration decision is it supporting?
- Prepare the AWS side: set your Migration Hub home Region, build least-privilege IAM permissions, confirm account access, and document data retention requirements
- Prepare the source environment: validate platform support, firewall and outbound connectivity rules, vCenter or host permissions, and pick a representative test group of workloads first
- Deploy your chosen method and monitor collection status until expected servers, metadata, and dependencies show up where they should
- Validate everything with application owners before locking in migration waves: if a dependency is unclear, record it as unknown rather than assuming it doesn't exist
A dependency matrix that covers APIs, databases, file shares, and scheduled jobs, tested through staged cutovers, catches far more than a single discovery pass ever will.
This is where a lot of SMB teams hit friction. The tools themselves are easy enough to install, but scoping the project, configuring permissions, and interpreting what comes back requires AWS-specific experience most internal teams rarely get to practice.
Cloudtech, an AWS Partner with AWS-Certified Solutions Architects on staff, works with SMBs through exactly this stage. That includes scoping discovery correctly, configuring secure collection, interpreting the data, and turning it into a migration roadmap that holds up once real workloads start moving.
Frequently Asked Questions
What is AWS Application Discovery Service?
It's an AWS service that collects infrastructure, utilization, and dependency information from on-premises environments to support migration planning. It informs decisions but does not execute the migration itself.
What is a discovery agent in AWS Application Discovery Service?
The Discovery Agent is software installed on supported servers that collects detailed host, performance, process, and network connection data. Check current AWS prerequisites for supported operating systems before installing it.
What is the difference between AWS Application Discovery Service and AWS Migration Hub?
ADS collects or imports the discovery data. Migration Hub is the console where you view that data, group applications, and track migration progress across AWS tools.
Is the AWS Application Discovery Service Discovery Connector still supported?
No. AWS ended Discovery Connector support on November 17, 2025. Historical data remains accessible, but new collection should use the Agentless Collector instead.
Does AWS Application Discovery Service cost anything?
ADS itself is listed with no direct charge in AWS's pricing documentation, but supporting resources like S3 storage for collected data bill separately. Check current AWS pricing before budgeting a project.
When should I use the Discovery Agent instead of the Agentless Collector?
Use the Discovery Agent when you need process-level and host-level detail on critical servers. Use the Agentless Collector for broader, lower-touch coverage across a VMware environment where that depth isn't required.
