Application Discovery, Migration Hub, and Migration Evaluator
Key Takeaways
- Set an AWS Migration Hub home Region before discovery: planning data is stored only there, while you can still migrate into any Region the chosen migration tool supports.
- Application Discovery Service Agentless Collector is an OVA in VMware vCenter for faster inventory and utilization; Discovery Agent installs on each Windows or Linux VM or physical server when you need running processes and detailed time-series performance.
- File-based import (including RVTools-style inventories) and partner tools can feed Migration Hub when agents are not yet approved; imported fidelity cannot exceed the spreadsheet you provide.
- Migration Evaluator is a complimentary directional TCO and business-case service that uses an agentless collector or existing inventory—including Application Discovery Service data—to model Amazon EC2 and Amazon EBS rehost cost from measured utilization.
- As of 7 November 2025 AWS closed Migration Hub and Application Discovery Service to new customers; existing customers continue in-flight work, and AWS Transform (generally available May 2025) is the published path for new discovery projects.
Why discovery quality decides the 7 R list
The previous section assigned rehost, retain, repurchase, and the rest of the 7 Rs. Those labels are only as good as the inventory, utilization, and dependency data behind them. Independent SAP-C02 study material by OpenExamPrep treats AWS Migration Hub, AWS Application Discovery Service, and Migration Evaluator as the assessment trio Task 4.1 still tests. You use them to turn Meridian Health Systems’ 200-application rumor mill into an asset list finance can fund.
Read the availability change before you design a greenfield tool chain. AWS closed Migration Hub and Application Discovery Service to new customers on 7 November 2025. Existing customers continue in-flight discovery and tracking. AWS Transform, launched in May 2025, is the published next-generation workbench that AWS documents as providing equivalent discovery, assessment, dependency mapping, and wave-planning capabilities for new projects. SAP-C02 still expects you to know Hub, Discovery Service, and Evaluator behavior—home Region, agent versus agentless, TCO inputs—because those capabilities are what the exam guide’s assessment tools describe. Do not invent a shutdown date AWS has not published for existing customers, and do not invent an exam pass rate to justify skipping discovery.
Migration Hub as the planning console
AWS Migration Hub provides a single place to discover existing servers, group them into applications, plan migrations, and track status regardless of which migration tool performs the move. Hub documents status updates from AWS Application Migration Service (primary lift-and-shift tool in Hub documentation) and AWS Database Migration Service (AWS DMS). You may start migrating and group servers later, or discover first and then group. Either way, application grouping is how a 200-row server list becomes a wave candidate.
On first use, Hub prompts you to select a home Region. You must select it before any write action from the console, SDK, or CLI. Discovery and planning data are stored only in that home Region. Discovery agents, collectors, and imports work with that home Region. You can still migrate into any AWS Region the migration tool supports; the home Region is not “the only Region you may land in.” For Meridian, architects often pick a home Region that matches the security and logging account they already use, then rehost clinic apps into us-east-1 and us-west-2 as product needs require.
Hub also exposes Strategy Recommendations (modernization pathway suggestions), EC2 instance recommendations from discovered profiles and utilization, network visualization for grouped applications, Migration Hub Orchestrator (templated workflows), Journeys, and Refactor Spaces (incremental refactor to microservices). Those features help planning; they do not by themselves rewrite Meridian’s mainframe. Treat Strategy Recommendations as input to a 7 R conversation, not as an automatic refactor mandate.
Application Discovery Service: agent versus agentless
AWS Application Discovery Service collects usage and configuration data about on-premises servers and databases and integrates with Migration Hub (and with AWS DMS Fleet Advisor for database assessment). AWS documents three collection paths.
Agentless Collector is an on-premises appliance you install as a virtual machine in VMware vCenter from an Open Virtualization Archive (OVA) file. After it is configured, it identifies VMs and hosts associated with vCenter. It collects static configuration such as hostnames, IP addresses, MAC addresses, disk resource allocations, database engine versions, and database schemas. It also collects utilization (average and peak CPU, RAM, and disk I/O) for VMs and databases. The database and analytics module can use LDAP against Microsoft Active Directory to find OS, database, and analytics servers, then query engines AWS lists as Oracle, SQL Server, MySQL, and PostgreSQL. AWS’s getting-started guidance states the benefit of Agentless Collector as a more efficient and faster on-premises infrastructure assessment. It does not deploy per physical blade. Physical servers are a no in AWS’s comparison table unless you add another method.
Discovery Agent installs on each VM or physical server. Installers exist for Windows and Linux. It collects static configuration, detailed time-series system performance, inbound and outbound network connections, and processes that are running. AWS’s comparison table lists a collection interval on the order of 15 seconds for the agent versus on the order of 60 minutes for Agentless Collector. Only the agent exports time-series utilization and agent network data to CSV or Amazon Athena in the comparison table. AWS’s VMware narrative still tells you that Agentless Collector cannot look inside a guest to list processes; if you need that closer look on selected VMs, install Discovery Agent as needed. You may run both collectors on VMware at once.
File-based import loads an inventory into Migration Hub without deploying either collector. Fidelity equals the file. RVTools exports are a common VMware snapshot: good for profiles, not a substitute for utilization or running processes. Partner discovery tools can write through the public API.
| Capability | Agentless Collector | Discovery Agent | Import / RVTools-style file |
|---|---|---|---|
| VMware VMs via vCenter | Yes (OVA per vCenter) | Yes (per guest if installed) | Profile snapshot |
| Physical servers | No | Yes | If the file includes them |
| Running processes | No | Yes | No |
| TCP connections for grouping | Comparison table: yes | Yes (inbound/outbound) | No |
| Time-series utilization export | No (latest snapshot) | Yes | No |
| Database engine/schema module | Yes (listed engines) | No | No |
| Collection cadence (AWS table) | ~60 minutes | ~15 seconds | One-time |
| Best first use at Meridian | Fast VMware + SQL estate baseline | Physical boxes, process maps, contested dependencies | When change control blocks appliances |
Migration Hub’s discovery tools page also lists the Migration Evaluator Collector as a path into the same planning conversation. Do not treat Evaluator and Discovery Service as the same product: Evaluator’s job is the business case; Discovery Service’s job is server and application data for Hub.
Migration Evaluator and TCO
Migration Evaluator (formerly TSO Logic) is a complimentary migration assessment service that builds a data-driven directional business case for AWS planning. AWS pricing documentation describes a white-glove path: on-premises inventory discovery, then analytics that match workloads to Amazon EC2 and Amazon Elastic Block Store (Amazon EBS) placements, including bring-your-own-license eligibility. You request an assessment through an AWS account team, a partner, or AWS’s request form—Evaluator is not “open a console and print a guaranteed invoice.”
If you lack inventory, Evaluator recommends a complimentary agentless collector with read-only access to VMware, Hyper-V, Windows, Linux, Active Directory, and SQL Server. If you already have exports from third-party discovery tools, you upload them; AWS states that industry benchmarks fill gaps in provisioning or utilization. If Application Discovery Service already collected inventory and utilization, Evaluator can use that data. The same ADS collector can feed server dependency mapping in Migration Hub and the Evaluator case. Optional TCP collection lets Hub visualize server-to-server dependencies, create application groups, and identify a first set of servers to move.
Quick Insights gives business stakeholders a one-page view of estimated rehost savings split by infrastructure versus software licenses, and gives engineers per-server and per-SQL recommendations. If the organization needs more, you request a full Business Case. AWS documents six sections: analysis and insights (scope, server counts, assumptions); financial summary (workload-specific what-if purchase scenarios); business value (AWS Cloud Value Framework, including a sustainability view of estimated carbon change versus on premises); deployment summary (Windows and SQL licensing options); storage assessment when in scope; and next steps. That is directional TCO, not a binding AWS price quote and not an exam pass-rate statistic.
Portfolio and asset planning with incomplete data
Discovery exists to close assumptions. AWS’s application-portfolio guidance tells you to convert assumptions into facts, refine application-to-infrastructure mapping, and capture ownership, criticality, and primary function. For Meridian’s 200 applications:
- VMware x86 line-of-business: Agentless Collector first, then Discovery Agent on the 30 servers whose TCP maps look like hidden shared databases.
- Physical Windows file servers: Discovery Agent; Agentless Collector will not see them through vCenter.
- COTS HR/payroll: inventory the servers, but the 7 R is still repurchase if the SaaS edition wins. Discovery tells you data volume and identity dependencies; it does not tell you to rehost a product you intend to replace.
- Claims mainframe and lab instruments: do not pretend Agentless Collector will inventory a mainframe the way it inventories vCenter. Record the mainframe as an asset with unknown guest telemetry, assign retain, and fund a dedicated assessment (including AWS Transform’s mainframe assessment capabilities if that is the organization’s current tool). Missing mainframe packets in Hub are a data-gap, not proof the mainframe is a simple rehost.
Export discovered performance into cost models. Hub stores data in the home Region; you can export for Microsoft Excel, Amazon Athena, or Amazon QuickSight. Input utilization into Evaluator or your own model so rightsizing uses measured CPU and RAM, not nameplate cores.
Dependency mapping
Dependency data includes communication volume and frequency and nontechnical dependencies such as shared change windows and vendor engineers. Dependencies decide which applications must move together and which can run from different locations for a time. Hub visualization of TCP connections is the usual exam picture. Process lists from Discovery Agent explain why two servers talk (a batch executable versus a stray backup).
A classic Meridian miss: clinic portal VMs look independent in a CMDB, but agent data shows a high-frequency path to the COTS HR identity store. Repurchase of HR without an identity design splits a runtime dependency across SaaS and Amazon EC2. Another miss: retiring a “zombie” VM that still hosts a DNS alias the mainframe uses for nightly files. Utilization below 5 percent is a retire candidate, not a delete-without-mapping license.
Discovery traps
- Starting collectors before setting the Migration Hub home Region.
- Believing Agentless Collector inventories physical blades and guest processes.
- Treating an RVTools snapshot as time-series utilization.
- Using Evaluator list-price folklore instead of utilization-based EC2/EBS modeling.
- Grouping servers by hostname prefix instead of communication data.
- Assuming Hub data must live in every destination Region.
- Rehosting COTS because it appeared in vCenter, even though repurchase is the business decision.
- Declaring the mainframe in-scope for Agentless Collector the same way as vCenter VMs.
- Telling a net-new customer in 2026 to onboard Migration Hub as if 7 November 2025 had not closed new-customer access—point them at AWS Transform for new projects while still knowing Hub behavior for the exam and for existing estates.
Meridian’s 200-application estate is mostly VMware, plus twelve physical Windows file servers and a claims mainframe. Change control will allow one vCenter appliance this month and agents on a subset of guests next month. Architects need a fast utilization baseline for Amazon EC2 recommendations and, later, process-level maps on the physical servers. Which discovery design matches AWS Application Discovery Service documentation?
Finance will not approve Meridian’s data-center exit until a directional AWS cost view exists for the x86 estate. The operations team can deploy a read-only collector or upload existing inventory. Leadership wants what-if purchase scenarios and Windows/SQL license views, not a made-up savings percentage. Which approach matches Migration Evaluator’s published role?
A solutions architect is enabling discovery for an existing AWS customer that already uses Migration Hub. Clinic workloads may land in two Regions, and a partner wants to import a CMDB extract. What must be true about Hub data placement and current onboarding rules?