We assume you already know ADS “discovers servers for migration.” This chapter goes past that into the two distinct collection architectures, the data model distinctions that determine what questions you can actually answer later, and the grouping constructs that turn raw inventory into an actionable migration plan.

Two Fundamentally Different Collection Architectures, One Shared Backend

ADS supports agent-based discovery (a lightweight software agent installed directly on each physical server or VM) and agentless discovery (a single OVA appliance deployed once into a VMware vCenter environment, which polls the vCenter API on behalf of every VM it can see, with no per-VM software installed at all). These are not two flavors of the same mechanism — they collect fundamentally different depth of data through fundamentally different privilege models, and an advanced discovery design almost always uses both simultaneously across different segments of an estate rather than picking one exclusively.

Static Configuration Data Versus Time-Series Performance Data

ADS’s data model splits cleanly into two categories that get treated very differently downstream. Static configuration data — hostname, OS version, IP addresses, installed software inventory — is captured largely once and updated on change. Time-series performance data — CPU utilization, memory utilization, disk I/O, network throughput — is sampled continuously (agent-based, by default every 15 seconds) and only becomes meaningful in aggregate over an observation window, typically two to four weeks, long enough to capture a full business cycle including month-end batch jobs or weekly peak-traffic patterns that a single snapshot would completely miss.

Applications Are a Manually Curated Grouping, Not an Auto-Discovered Fact

ADS discovers servers and their relationships automatically, but it does not automatically know that “these fourteen servers, taken together, are the order-management application.” Grouping discovered servers into logical “Applications” inside Migration Hub is an explicit, human-driven curation step — informed heavily by the discovered network-connection graph and tag data, but never fully automated, because business context (which team owns it, which line of business it serves, its migration priority) is not something any agent can infer from packet flows alone.

Configuration Items Have a Type Hierarchy, Not a Flat List

Discovered data is not a single undifferentiated table of servers — it is organized as a typed hierarchy of Configuration Items: Server, Process, Connection, and Application each carry a distinct schema and distinct fields relevant to that type, with relationships between them (a Process runs on a Server, a Connection links two Processes) forming the graph that later analysis walks. Treating discovery data as “just a server list” and ignoring the Process and Connection layers is the single most common way teams under-use the data they’ve already paid the collection cost to gather.

Utilization Percentiles Matter More Than Averages for Sizing Decisions

A server’s average CPU utilization across a four-week window can look comfortably low while its 95th-percentile utilization during known peak windows is dangerously high — averaging away exactly the spikes that determine whether a target instance will be adequately sized. Advanced discovery analysis pulls percentile distributions from the exported time-series data via Athena rather than relying solely on the summary averages presented in the Migration Hub console’s default views, since the console’s simplified presentation is built for a quick overview, not for the sizing-decision rigor a production workload deserves.

Software Inventory Feeds License and Compatibility Decisions Independently of Sizing

Beyond performance data, both collection methods capture installed software inventory — product name, version, publisher — which feeds an entirely separate downstream decision stream from utilization-based sizing: license true-up negotiations, end-of-life software identification, and compatibility screening against target cloud services. Teams that only mine discovery data for CPU and memory numbers frequently leave this software inventory unexamined until a licensing audit or a compatibility surprise forces a second, much more rushed look at data that was collected all along.

The two collection paths differ sharply in how they gather data internally, what privileges they require, and what artifact actually talks to AWS.

The Discovery Agent Runs Locally and Batches Uploads

The Discovery Agent is a small binary installed on each target Windows or Linux server. It reads system-level performance counters directly from the OS, inspects running processes and their listening/connecting network sockets, and periodically batches this data into an upload payload sent over HTTPS to a regional ADS endpoint. Critically, the agent never requires an inbound connection to the server — all communication is agent-initiated outbound, which is precisely why the agent-based model is viable even in tightly locked-down data center network segments where opening an inbound management port would be a non-starter.

The Discovery Connector Polls an External API, Not the Guest OS

Agentless discovery is architecturally the opposite: a single Discovery Connector, delivered as an OVA appliance, is deployed once into the VMware environment and configured with read-only credentials against the vCenter Server API. It never touches the guest operating system of any VM directly — instead, it polls vCenter for VM inventory, host and cluster configuration, and resource utilization metrics that vCenter itself already collects, then forwards that data to AWS in the same way the agent does. This is why agentless discovery can instantly see hundreds of VMs the moment the connector is registered, but is fundamentally limited to whatever visibility vCenter itself has — it cannot see inside a guest OS to processes or in-guest network connections the way an agent can.

graph TB
    subgraph OnPrem[On-Premises Data Center]
        A1[Server A
Discovery Agent]
        A2[Server B
Discovery Agent]
        VC[VMware vCenter]
        DC[Discovery Connector
OVA Appliance]
        VC --> DC
    end
    A1 -->|HTTPS, outbound only| EP[ADS Regional Endpoint]
    A2 -->|HTTPS, outbound only| EP
    DC -->|HTTPS, outbound only| EP
    EP --> DS[(Discovery Data Store)]
    DS --> MH[Migration Hub Console]
    DS --> S3[(S3 Export via Athena)]
        

Neither Path Performs Any Analysis Locally

Both the agent and the connector are intentionally “dumb” collectors — they gather raw metrics and configuration facts and ship them upstream; all correlation, deduplication, dependency-graph construction, and utilization aggregation happens centrally in the ADS backend once data lands in the regional data store. This matters architecturally because it means the on-premises footprint stays minimal and stateless — an agent can be reinstalled or a connector redeployed without any loss of historical data, since nothing meaningful is retained locally beyond a short local buffer awaiting the next upload cycle.

Migration Evaluator and Application Migration Service Read From the Same Backbone

ADS is not an isolated tool — it is the discovery layer underneath the broader AWS migration tooling stack. Migration Hub surfaces the discovered inventory for grouping and tracking; Migration Evaluator consumes the utilization time-series to right-size target EC2 instances and build a cost business case; and Application Migration Service can consume discovered server metadata to streamline replication setup. Understanding ADS purely as a standalone reporting tool misses that its real architectural role is as the shared fact base every other migration tool in the stack builds its recommendations on top of.

The Agent’s Local Buffer Is Deliberately Short-Lived

When network connectivity to the ADS endpoint is temporarily unavailable, the agent holds collected data in a local buffer rather than dropping it immediately, but that buffer is bounded in both size and retention duration by design — it is meant to absorb brief network blips, not to serve as a durable offline data store for an extended outage. An agent on a server that loses connectivity for several days will eventually begin discarding the oldest buffered data as the buffer fills, which is why sustained connectivity, not just eventual connectivity, is the actual requirement for complete data capture.

The Connector’s vCenter Polling Cadence Is Independent of the Agent’s Metric Interval

Because the Discovery Connector reads from vCenter’s own performance-monitoring subsystem rather than sampling the guest OS directly, its effective data granularity is bounded by whatever collection interval vCenter itself is configured with — commonly a coarser interval than the agent’s default 15-second polling. This means agentless utilization data, while broadly directionally accurate, is inherently a lower-resolution signal than agent-collected data, an important caveat when agentless-only data is used as the sole basis for a fine-grained sizing decision on a workload with short, sharp utilization spikes that a coarser sampling interval could average away entirely.

Handoff to Migration Evaluator Happens Through a Shared Data Model, Not a Manual Export

When a discovery-collected server is later analyzed inside Migration Evaluator for right-sizing and cost modeling, that handoff happens automatically through the shared underlying data model both tools read from — there is no manual export-and-reimport step required between the two, provided both are operating against the same account and Home Region. This is a meaningful operational simplification over an architecture where discovery and cost-modeling were separate tools requiring a data-format translation layer between them, but it also means an account or region misalignment between where discovery ran and where Migration Evaluator is being used silently breaks that automatic handoff, requiring the manual S3/Athena export path as a fallback.

Tracing a single discovered server from first contact to an exportable wave-planning artifact reveals the specific stages where data quality can quietly degrade if the process isn’t run deliberately.

sequenceDiagram
    participant Server as On-Prem Server
    participant Agent as Discovery Agent
    participant Backend as ADS Backend
    participant Hub as Migration Hub
    participant Analyst

    Server->>Agent: Local OS metrics, processes, sockets
    Agent->>Agent: Buffer and batch (local, short window)
    Agent->>Backend: HTTPS upload (outbound only)
    Backend->>Backend: Correlate by Configuration ID
    Backend->>Backend: Aggregate time-series over collection window
    Backend->>Hub: Surface inventory + connection graph
    Analyst->>Hub: Apply tags, curate Applications
    Analyst->>Backend: Export via S3 / Athena for custom analysis
        

The Collection Window Is the Single Most Consequential Decision in the Lifecycle

Because performance data is only meaningful as a time-series aggregate, the duration of the collection window directly determines whether the resulting sizing recommendations reflect reality. A two-week window that happens to exclude a month-end financial close batch job will systematically under-report peak CPU and memory demand for exactly the workload most likely to break if under-provisioned post-migration. Advanced discovery programs deliberately extend the collection window to span at least one full known peak-load cycle for each application category, rather than defaulting to the shortest window that produces “enough” data to generate a report.

Deduplication Happens by Configuration ID, Not by Hostname

When the same server is visible through both agent-based and agentless collection simultaneously — a common scenario during a phased rollout — the backend correlates and deduplicates records using the stable configuration ID rather than hostname string matching, which is deliberately more robust against hostname reuse, DNS changes, or inconsistent naming conventions across business units that would otherwise cause the same physical server to appear as two separate discovered entities.

Export Is a Point-in-Time Snapshot, Not a Live Feed

Data exported to S3 for Athena-based analysis reflects the aggregated state at the moment of export, not a continuously synced live feed. Teams building recurring wave-planning reports schedule a deliberate, repeatable export cadence rather than treating a single export as a permanently current source of truth, since discovery data continues accumulating and being re-aggregated for as long as collection remains active.

Data Retention Requires Proactive Archival

Discovery data is retained for a bounded default window; teams needing it preserved for a longer compliance or historical-comparison purpose must proactively export it to S3 before that window elapses rather than assuming ADS itself functions as indefinite storage — a governance detail that is easy to overlook mid-program when the discovery phase feels “done” and attention has already shifted to migration execution.

Curation Changes Don’t Retroactively Alter Historical Time-Series Data

When an analyst re-tags a server or moves it between Application groupings partway through a collection window, that curation change applies going forward and to how existing data is now organized for reporting purposes, but it does not rewrite or re-attribute historical performance samples that were collected under the previous grouping. This distinction matters when reviewing a utilization trend for an Application that was reorganized mid-collection: the visible trend line may reflect a boundary change partway through, not an actual change in the underlying workload’s behavior, and misreading that discontinuity as a real performance shift is a subtle but consequential analysis mistake.

The Connection Graph Is Built Incrementally, Not All at Once

A dependency between two servers only becomes visible in the network connection graph once both ends of that connection have actually been observed communicating during the collection window — an infrequently used batch integration that only runs once a month, for example, may not surface as a discovered connection at all if the collection window doesn’t happen to include that monthly run. This is a direct consequence of discovery being observational rather than declarative: it records what it actually sees happen, not what a configuration file says should happen, which is exactly its strength for uncovering undocumented dependencies and exactly its limitation for capturing rare-but-critical ones.

The Lifecycle Doesn’t End When Collection Stops — It Ends When a Decision Is Made

It’s tempting to treat “collection window closed, report generated” as the end of the discovery lifecycle, but the data’s actual lifecycle only completes once it has visibly informed a wave-sequencing or sizing decision. Data that sits fully collected and fully curated but never reviewed against the actual migration plan being executed has technically completed the ADS pipeline while functionally failing the purpose the entire collection effort existed for — a distinction worth stating plainly because it’s an easy trap for a program under schedule pressure to fall into, treating “discovery complete” as a milestone rather than a means to an end.

The choice between agent-based and agentless collection — and the decision of how thoroughly to deploy either — is a genuine architectural trade-off with real consequences for both data quality and organizational friction.

The Real Cost Is Organizational, Not Technical

ADS itself is inexpensive relative to the migration programs it supports, and its technical footprint is deliberately light. The genuine cost driver is organizational: securing change-management approval to install an agent fleet across hundreds or thousands of servers, and securing the curation time from application owners to translate a raw inventory into meaningful Application groupings. Architects who treat discovery as “just deploy the tool and read the report” consistently underestimate this coordination cost relative to the tool’s own technical simplicity.

Speed-to-Coverage Versus Depth-of-Insight Is the Trade-off That Actually Drives Architecture Decisions

Every discovery program implicitly trades speed-to-coverage against depth-of-insight, and the two collection methods sit at opposite ends of that trade-off rather than at a single optimal point. A program under intense schedule pressure to produce a rough server count and cost estimate quickly will lean almost entirely on agentless discovery, accepting shallower insight in exchange for near-immediate broad coverage. A program where the migration’s success genuinely depends on getting application dependencies right — a complex, tightly coupled application landscape where a mis-sequenced wave could cause a real outage — has to accept slower agent-based rollout timelines in exchange for the depth that actually de-risks the plan. Recognizing which end of this trade-off a given program actually needs, rather than defaulting to whichever method is faster to deploy, is itself an architectural decision worth making explicitly and early.

At enterprise fleet scale, discovery itself has to be planned as a project with its own capacity and rollout considerations, not deployed as an afterthought.

Agent Footprint Is Deliberately Minimal, But Not Zero

The Discovery Agent is engineered for negligible CPU and memory overhead on the host it runs on, but at the scale of thousands of simultaneously reporting agents, the aggregate upload traffic and backend ingestion load become a real capacity consideration for the platform, which is why AWS applies throttling and batching on the ingestion side rather than assuming unlimited simultaneous upload concurrency from an arbitrarily large fleet.

Phased Rollout Beats a Big-Bang Agent Deployment

Deploying agents to an entire multi-thousand-server estate in a single change window is rarely advisable — not because ADS can’t handle the ingestion volume, but because a phased rollout by business unit or data center segment surfaces installation issues (OS compatibility edge cases, restrictive endpoint security software flagging the agent) against a small population before they become a fleet-wide blocker, and gives application owners a manageable cadence of Application-grouping curation work instead of an overwhelming backlog appearing all at once.

Agentless Scales Faster but Plateaus in Depth

A single Discovery Connector can enumerate an entire vCenter-managed environment essentially as fast as vCenter itself can answer the query, meaning agentless coverage scales to thousands of VMs almost immediately upon deployment. The scalability trade-off is depth, not breadth: no matter how many VMs the connector sees, it will never produce the process-level or in-guest connection detail an agent provides, so “scaling agentless discovery further” does not substitute for deploying agents where that missing depth actually matters to the migration decision.

Multiple Connectors Scale Horizontally Across vCenter Instances

A large enterprise with several independently managed vCenter instances — common after acquisitions or regional data-center autonomy — deploys one Discovery Connector per vCenter rather than attempting to point a single connector at multiple vCenter servers, since the connector’s architecture assumes a one-to-one relationship with its target vCenter API. This horizontal scaling pattern means discovery rollout planning for a multi-vCenter estate is really a project-management exercise in sequencing connector deployments and credential provisioning across each independently governed vCenter, not a single technical deployment step.

Athena Query Performance Depends on Export Partitioning Discipline

When discovery data volume grows into the millions of time-series data points across a large, long-running collection effort, ad hoc Athena queries against an unpartitioned S3 export can become noticeably slow and, at high enough volume, costly, since Athena scans data proportional to what a query touches. Advanced analysis pipelines partition the exported data by collection date and configuration type before querying, turning a full-scan query that might otherwise take minutes into one that completes in seconds by only scanning the relevant date range and data type.

Scaling Curation Effort Alongside Collection Scale Is Frequently the Actual Bottleneck

Technical collection scales relatively smoothly — deploying agents to a thousand servers is a matter of rollout automation, not a fundamentally harder engineering problem than deploying to a hundred. Curation does not scale the same way: tagging and grouping a thousand discovered servers into meaningful Applications requires proportionally more application-owner time and cross-team coordination, and that human coordination effort — not agent deployment throughput or backend ingestion capacity — is overwhelmingly the actual constraint that determines how quickly a large discovery program can move from raw inventory to an actionable wave plan.

Discovery reliability is less about uptime in the traditional sense and more about avoiding silent, undetected gaps in a data set that a migration wave plan will later be built on.

Agent Uninstalls and OS Decommissions Leave Stale Records Behind

When a server is decommissioned or an agent is uninstalled without an explicit deregistration step, the discovered record for that server does not automatically disappear from Migration Hub — it simply stops receiving new data and eventually appears stale. Left unaddressed across a long-running discovery program, an accumulating population of stale, no-longer-relevant server records can distort inventory counts and reconciliation checks, making a decommissioned-but-not-deregistered server look identical, from a monitoring standpoint, to a genuinely lost data-collection failure worth investigating. Establishing an explicit deregistration step as part of any decommissioning runbook keeps the discovered inventory an accurate reflection of what’s actually still running.

Resilience Is Asymmetric Between the Two Collection Paths

Agent-based discovery’s resilience is distributed — the failure of any single agent affects only that one server’s data, with no shared point of failure across the fleet. Agentless discovery’s resilience is concentrated — a single Discovery Connector outage silences data collection for every VM behind that vCenter instance simultaneously. This asymmetry is a genuine architectural consideration when deciding how much of an estate’s discovery visibility to place behind a single connector versus how much redundancy in monitoring and prompt-restoration practice that concentration of risk deserves.

Redundant Connectors Reduce, but Do Not Eliminate, the Concentration Risk

Some teams mitigate the connector’s single-point-of-failure profile by deploying a second, standby connector against the same vCenter instance, ready to be activated quickly if the primary fails. This reduces the practical downtime window during a connector outage but does not eliminate the underlying architectural asymmetry — both connectors still depend on the same underlying vCenter API being healthy and reachable, so a vCenter-side outage rather than a connector-side one would still silence agentless collection regardless of how many connector instances are standing by.

Discovery tooling touches sensitive terrain by nature — it needs enough visibility into a production estate to be useful, which means its own credential and data-handling posture deserves the same scrutiny as the systems it’s inventorying.

The Discovery Connector’s vCenter Credentials Should Be Read-Only and Scoped Narrowly

The service account configured on the Discovery Connector only needs read access to inventory and performance data within vCenter — it never needs write, provisioning, or configuration-change permissions. Granting it broader vCenter privileges than strictly required (a common shortcut when standing up the connector quickly) creates an unnecessary lateral-movement risk if the appliance itself is ever compromised, since the appliance now holds credentials capable of far more than passive observation.

Agent Communication Is Outbound-Only and TLS-Encrypted, But Network Segmentation Still Matters

Both the agent and the connector communicate exclusively outbound over HTTPS to AWS-owned endpoints, which satisfies most perimeter-security postures without an inbound firewall exception. That said, an advanced security review still considers whether the segment the agent runs in should have unrestricted internet egress at all, or whether traffic should be routed through a controlled proxy or VPC-like on-prem egress point — outbound-only does not automatically mean unrestricted, and treating it as such skips a legitimate control point.

Discovered Data Itself Can Be Sensitive Metadata

Software inventory, hostname naming conventions, and network topology revealed by discovery data can themselves be sensitive from a security-posture-disclosure standpoint — a complete map of an organization’s server estate and its dependency graph is meaningful reconnaissance value in the wrong hands. IAM access to the discovery data in Migration Hub and any S3 export bucket should be scoped to the specific migration program team, not left at a broad default that any engineer with general AWS console access can browse.

The Discovery Agent’s Own Binary Integrity Deserves Standard Software-Supply-Chain Scrutiny

Because the agent runs with sufficient local privilege to read system-level performance counters and process/socket information across potentially thousands of production hosts, it is functionally a piece of monitoring software with broad host-level visibility — the same category of software that a security team would normally subject to checksum verification on download, controlled distribution through an internal software repository, and version-pinning rather than allowing ad hoc downloads directly from the internet on each target server during rollout.

S3 Export Buckets Need the Same Encryption and Access Discipline as Any Sensitive Data Store

Once discovery data is exported to S3 for Athena-based analysis, it inherits none of Migration Hub’s built-in access model automatically — the exporting team is responsible for applying appropriate bucket policies, encryption at rest, and access logging to that export bucket exactly as they would for any other sensitive data landing zone, since a permissive default bucket policy on an export containing a full estate inventory and dependency graph is a meaningfully larger exposure than the same misconfiguration on a less sensitive data set.

Cross-Team Data Sharing Should Go Through Scoped Views, Not Raw Export Access

A large migration program frequently needs to share discovery findings with stakeholders beyond the core discovery team — application owners reviewing their own portfolio, finance reviewing the cost business case, security reviewing dependency exposure. Rather than granting each of these audiences direct read access to the raw discovery data set or full S3 export, mature programs build scoped, purpose-built views (a filtered Migration Hub Application view for an application owner, a curated cost summary for finance) so that each audience sees exactly the slice of discovery data relevant to their decision, without unnecessarily exposing the full estate inventory to every stakeholder who only needs a fragment of it.

Because ADS’s failure modes are quiet by nature, monitoring the discovery process itself — not just consuming its output — is a distinct and necessary discipline.

Agent and Connector Health Status Is a First-Class Signal to Watch

Migration Hub surfaces per-agent and per-connector health and last-check-in status directly in the console, and this status — not the completeness of the resulting reports — is the earliest indicator of a coverage gap forming. A discovery program that only reviews aggregated reports at the end of a collection window, without periodically checking agent health throughout, risks discovering a three-week-old connectivity failure only after the collection window has already closed and can’t retroactively be filled.

Reconciliation Against an Independent Inventory Is the Real Metric That Matters

The single most valuable “metric” in an advanced discovery program is not anything ADS reports natively — it’s the delta between discovered server count and an independent source of truth like a CMDB or network-scan tool. A persistent, unexplained gap between the two is the leading indicator of either an incomplete agent rollout or a segment of the estate the discovery program hasn’t reached at all, and closing that gap before finalizing a wave plan is what separates a plan built on measured reality from one built on partial visibility mistaken for complete visibility.

Trend Monitoring Catches Estate Drift During a Long-Running Discovery Effort

Large discovery programs frequently run for months across a phased estate, during which the underlying environment itself keeps changing — new servers get provisioned, old ones get decommissioned, applications get re-architected. Tracking discovered-inventory trend over time, not just a single end-state count, surfaces this drift directly: a discovered count that should be roughly flat but instead climbs steadily suggests either genuine estate growth worth understanding or, more commonly, that earlier discovery passes missed segments that a later, broader pass is now catching up on.

Data Freshness Should Be Monitored Per Server, Not Just in Aggregate

An aggregate “last data received” timestamp across the whole discovery program can look perfectly current even while a specific subset of servers has gone silent, because the aggregate is dominated by the much larger population still reporting normally. Advanced monitoring pulls per-server last-check-in timestamps and flags any server exceeding an expected reporting interval individually, rather than relying on a program-wide freshness indicator that can mask a real, localized coverage gap.

Deployment specifics differ meaningfully between the two collection paths and interact directly with existing data-center network and virtualization architecture.

Discovery for Hybrid and Multi-Hypervisor Estates Requires a Blended Strategy

An estate that is not purely VMware — a mix of Hyper-V, bare metal, and VMware — cannot rely on agentless discovery alone, since the Discovery Connector is VMware-specific. These environments deploy agent-based discovery on the non-VMware segments while using the connector for the VMware footprint, accepting the resulting asymmetry in data depth (process-level detail on agent-covered hosts, configuration-and-utilization-only on agentless-covered VMs) as a known, documented limitation of the blended approach rather than something to paper over in the final report.

Configuration-Management Integration Turns a Manual Rollout Into a Repeatable One

Pushing the Discovery Agent through existing configuration-management tooling rather than manual installation does more than save time — it makes the rollout auditable and repeatable, which matters when a security or compliance review later asks exactly which servers had the agent installed, when, and under what approved change ticket. Treating agent deployment as just another managed software package inside an existing CM pipeline, rather than a bespoke one-off migration-program activity, is what lets a large rollout stay consistent across hundreds of servers touched by different regional operations teams.

Firewall and Proxy Configuration Is Usually the First Deployment Blocker Encountered

Even though both collection paths require only outbound HTTPS, many enterprise data-center network segments still route all outbound traffic through a controlled proxy or restrict egress to an explicit allow-list of destinations. The most common first-week deployment blocker in practice is not the agent or connector software itself but getting the specific AWS discovery endpoints added to that allow-list — a network-change request that, in a heavily governed enterprise, can take longer to approve than installing the agent software across the entire target fleet.

Rollout Sequencing Should Mirror Migration Wave Priority, Not Alphabetical Convenience

When a program has to phase agent rollout across a large estate rather than deploying everywhere simultaneously, the sequencing decision itself carries weight: deploying agents first to servers already suspected of belonging to early migration-wave candidates produces usable, deep data for the decisions that matter soonest, while a purely alphabetical or arbitrary rollout order risks having the most business-critical, earliest-wave applications still running on shallow agentless-only data right when the wave-planning decision for them needs to be made.

A handful of recurring patterns distinguish discovery programs that produce a defensible migration plan from those that produce a report nobody trusts by the time migration execution starts.

The following distinctions consistently separate discovery programs whose output survives contact with actual migration execution from those that don’t.

The highest-leverage practice overall is refusing to let discovery become a checkbox milestone disconnected from the wave-planning decisions it’s meant to inform. A discovery report that sits in a shared drive while the actual migration wave sequence gets decided in a separate meeting based on organizational assumptions has produced data without producing decisions — the value of ADS is realized only when its connection graph and utilization data directly, visibly shape which servers move together and in what order.

A closely related mistake worth naming explicitly is assigning discovery ownership to a team with no stake in the migration’s ultimate success. When the discovery phase is outsourced entirely to a separate data-collection vendor or a junior team disconnected from the wave-planning decisions, curation quality — tagging, application grouping, dependency validation — tends to suffer, because the people doing the tedious curation work have no visibility into, or accountability for, how poorly-curated data will later distort a wave plan they won’t be present to defend. Keeping at least one member of the actual migration-planning team embedded in the discovery curation process, rather than treating discovery purely as an upstream data-gathering vendor task, consistently produces a more trustworthy final data set.

The following patterns reflect the class of decisions organizations at real migration scale actually make — illustrative of the pattern, not proprietary internal detail.

Advanced-level questions engineers and migration architects actually run into once past the introductory “what does ADS do” stage.