Lesson 281 · AWS Learning Path

AWS 281: Migration assessment and dependency discovery

Anil Jalela · Published Apr 2, 2026 · 16 min read

Why this lesson matters

A server list is not a migration assessment. It may show 400 virtual machines but omit which business service each machine supports, who can approve downtime, what calls the machine, which data it stores, when demand peaks, and whether its software can legally run on AWS. Migrating from that list can produce an accurate copy of the wrong system, an incomplete wave, or an unexpected outage.

Assessment turns incomplete observations into reviewable decisions. Dependency discovery finds the technical and human relationships that make an application work. Neither is a one-click activity. Tools observe hosts, processes, utilization, storage, and connections; people explain business meaning, critical schedules, contracts, recovery objectives, and tolerated risk.

This lesson teaches a defensible evidence chain from raw discovery through application boundaries and migration readiness. It does not create resources or require access to a real environment.

Outcomes

By the end, you can:

• distinguish inventory, discovery, assessment, application grouping, dependency groups, and migration waves;
• choose current discovery sources without teaching a closed service to a new customer;
• define collection scope, representative duration, permissions, security, retention, and acceptance before deployment;
• reconcile tool observations, CMDB records, cloud inventories, financial records, and owner interviews;
• interpret host, process, network, performance, storage, database, and operational dependencies;
• expose blind spots such as unobserved batch jobs, external endpoints, UDP, dynamic addresses, and shared services;
• assign evidence confidence and keep facts separate from assumptions;
• produce application groups, dependency groups, readiness gaps, and wave constraints;
• test an automated right-sizing or cost recommendation before accepting it; and
• create a migration-assessment workbook from supplied evidence.

Six terms that must not be confused

An application can span many servers, one server can support several applications, and a shared service can belong to no single application. A wave is not simply an application list. It is an operational commitment based on dependencies, capacity, risk, and readiness.

Current AWS service position

AWS Application Discovery Service stopped accepting new customers on November 7, 2025. Existing enrolled customers can continue existing projects, but architects must not propose fresh onboarding for a new customer. AWS recommends AWS Transform for new discovery and assessment work.

The AWS Transform discovery tool supports VMware vCenter, Microsoft Hyper-V, and server import. With operating-system access it can collect server, process, performance, storage, database, network-interface, and server-to-server connection evidence. Its exports can feed an AWS Transform migration assessment. An assessment can also accept RVTools, CMDB, partner-tool, Migration Evaluator, MPA-format, and AWS assessment-template data.

This product boundary matters in exams and real designs:

• use current AWS Transform documentation for a new engagement;
• treat Application Discovery Service questions as legacy-context questions unless the scenario says the customer is already enrolled;
• retain existing-tool evidence if it is trustworthy instead of recollecting solely to change brands; and
• verify supported source formats, Regions, limits, permissions, and pricing at design time.

The complete evidence model

Use eight evidence domains. A green result in one domain cannot replace another.

Record each assertion with source, observation window, collection time, owner, confidence, and expiry or review date. “Oracle is installed” is a fact only if its source and recency are known. “The application can use Aurora PostgreSQL” is a hypothesis until compatibility and functional tests prove it.

Discovery sources and their blind spots

Use several sources. Agreement increases confidence; disagreement becomes a tracked data-quality issue rather than something to hide.

Design the collection before installing anything

Write a discovery charter with:

1. business scope and explicit exclusions;
2. environments such as production, disaster recovery, test, branch and acquired networks;
3. expected counts by hypervisor, physical server, operating system and location;
4. network zones and required collector-to-target paths;
5. least-privilege service accounts, credential owner and rotation method;
6. fields and modules to collect, sampling intervals and overhead test;
7. representative window and exceptional calendar events;
8. data classification, approved storage, encryption, access, retention and deletion;
9. completeness and quality thresholds;
10. support, monitoring, failure handling and change approval; and
11. who can accept results and authorize assessment use.

AWS Transform's appliance needs capacity and network access. Current guidance specifies 4 vCPU, 16 GiB RAM, at least 35 GB disk, SSH to Linux, WinRM to Windows, and optionally SNMP for network collection. These are starting requirements, not permission to open broad firewall rules or reuse administrator accounts. Test on a small representative segment, monitor target and collector load, then expand.

Choose a representative observation window

A seven-day collection can miss month-end settlement; a 30-day collection can miss annual enrollment; an average can hide a 15-minute payroll peak. Build a workload calendar before choosing duration:

• daily online and batch peaks;
• weekly backup, reporting and maintenance;
• month/quarter/year-end processing;
• seasonal campaigns and regulatory deadlines;
• failover or disaster-recovery exercises;
• certificate, key and license renewal;
• dormant systems used only during an incident.

AWS Transform exports can contain up to 30 days retained by the tool. Take incremental, controlled exports if the evidence period must span longer. Supplement automated data with scheduler histories, monitoring history, billing, logs and owner confirmation. Label partial windows honestly.

Secure the discovery plane

Discovery data is sensitive. Host names, IP addresses, process names, database editions, connection graphs and utilization can reveal architecture and vulnerabilities. Credentials used to collect it are more sensitive still.

Apply these controls:

• deploy the collector in a restricted management zone with only required routes and ports;
• use dedicated least-privilege SSH, WinRM, hypervisor and database identities;
• prefer Kerberos and validated WinRM HTTPS certificates where supported;
• change default appliance credentials immediately and normally keep SSH disabled;
• do not place passwords in CSV files, tickets, source repositories, screenshots or lesson submissions;
• restrict console and export access, encrypt exports, log access and use approved transfer paths;
• test auto-connect carefully because trying credentials across targets can trigger lockout and monitoring events;
• define retention before collection, preserve approved evidence before pruning, and securely delete expired copies; and
• patch and back up the collector according to its documented procedure.

The discovery tool stores a local database and normally retains collected data for 30 days. It warns at elevated disk usage and pauses collection at 90 percent; after freeing space, an operator must resume it below the documented threshold. Disk health is therefore an evidence-completeness control, not mere appliance housekeeping.

Normalize and reconcile inventory

Raw sources use different identifiers. A VM may appear as prd-api-04, an IP address, a BIOS UUID, a vCenter managed-object ID and a CMDB configuration item. Normalize without destroying source values.

Create a canonical record with:

• immutable internal record ID;
• every source-specific ID and original name;
• FQDN, aliases, current and historical IP/MAC addresses;
• physical/virtual/cloud type and location;
• OS/version/architecture/support status;
• CPU, memory, storage and utilization observations;
• environment, application, business and technical owners;
• lifecycle state and last-seen timestamp; and
• source, confidence and conflict notes for every important field.

Deduplicate only when strong identifiers and context agree. Never merge two servers just because their short host names match. Keep a reconciliation log for added, merged, split, excluded and unresolved records.

Measure coverage:

inventory coverage = discovered in-scope assets / expected in-scope assets
credential coverage = successfully inspected assets / assets requiring OS inspection
dependency coverage = assets with valid network evidence / assets expected to communicate
owner coverage = assets with confirmed accountable owner / in-scope assets

A percentage needs a denominator and an exception list. “95 percent discovered” is meaningless if the missing 5 percent contains the payment database.

Read dependency evidence correctly

AWS Transform network collection can record source and target addresses/ports, process IDs/names, transport protocol, IP version, connection state and count. By default, it captures connections whose endpoints are both in discovered inventory. Optional private-address collection can expose RFC 1918 endpoints not yet inventoried, but those records appear in the full export rather than the MPA files.

Turn every observed edge into a reviewable record:

Connection count is not business importance. Monitoring and backup may be noisy; a quarterly regulatory transfer may be quiet. An observed connection proves traffic occurred, not that it is required. An absent connection proves only that it was not observed within the source's scope and time.

Find dependencies that a traffic graph misses

For each application, investigate:

• synchronous calls where latency or failure immediately affects a request;
• asynchronous queues, topics, event buses and file drops;
• database links, replication, ETL, reports and analytics extracts;
• DNS zones, NTP, proxy, firewall, PKI, certificates and load balancers;
• Active Directory/LDAP, SSO, MFA, service accounts and secrets;
• backup, monitoring, patching, endpoint protection and vulnerability scanning;
• CI/CD, artifact repositories, configuration and license servers;
• schedulers, cron, managed file transfer and human approval;
• partner/public APIs and allowlisted source IP addresses;
• appliances, USB/dongle, multicast/broadcast and hardware ties;
• operator access, support contracts, skill and on-call dependencies; and
• legal retention, data residency and change-freeze constraints.

Ask “what must be true for this to work?” for startup, normal operation, peak, backup, restore, deployment, credential rotation, failure and disaster recovery.

From application groups to migration waves

First draw an application context diagram. Then classify dependency edges:

• hard/co-migrate: cannot tolerate transition latency or protocol break;
• bridgeable: can cross a temporary VPN/Direct Connect/private path within measured requirements;
• replaceable: target managed service or new interface removes the old dependency;
• operational: monitoring, backup or deployment needs a transition design;
• unknown: owner, purpose or behavior is unresolved.

Connected components with hard dependencies form candidate dependency groups. Shared identity, DNS, security and network foundations usually become prerequisites, not giant wave-one application groups. Create waves only after checking business calendars, team capacity, landing-zone readiness, data-migration duration, test environments, rollback, and concurrent-change risk.

Every proposed wave should state:

• included applications/components and excluded dependencies;
• chosen strategy from AWS280 and target architecture hypothesis;
• prerequisites and temporary connectivity;
• unresolved gaps with owner and due date;
• validation tests and measurable acceptance thresholds;
• cutover duration, data synchronization and freeze;
• rollback decision time and restored state; and
• decommission trigger, observation period and cost owner.

Assessment and right-sizing without false precision

AWS Transform can analyze inventory and recommend EC2/EBS and other target options, then compare scenarios by Region, pricing, exclusions, storage and licensing assumptions. A recommendation is a model output, not authorization to buy or migrate.

Challenge it:

1. Confirm that the source window includes representative load.
2. Check whether CPU, memory, IOPS, throughput, capacity and network data are measured or imputed.
3. Preserve burst, queue, latency and failover headroom rather than sizing from averages.
4. Check architecture, instruction set, GPU, local disk, tenancy and hardware requirements.
5. Model high availability, backup, logs, snapshots, data transfer, support and nonproduction.
6. Validate license mobility, core counting, dedicated-host and vendor-support rules with specialists.
7. Compare On-Demand, commitments and growth scenarios without assuming discounts before commitment approval.
8. Run a proof of concept and load/restore/failover tests for consequential assumptions.

Keep current-state cost, one-time migration cost, target run cost, optimization opportunity and business benefit separate. Include labor, connectivity, parallel running, tools, training, remediation, licensing, support, data transfer and decommissioning. Present ranges and sensitivity when inputs are uncertain.

Data quality and confidence

Use a simple, explicit rubric:

Do not average ratings into a comforting score that hides a critical unknown. Gate on mandatory fields. For example, a wave is not ready if any critical application lacks an owner, recovery objective, data classification, tested dependency treatment, target decision or rollback authority.

Maintain a data-quality register with issue, affected decision, risk, evidence needed, owner, due date and status. This converts uncertainty into work.

Hands-on workshop: assess the supplied portfolio

Create a local workbook with these tabs or CSV files. No AWS account is required.

1. sources: source ID, type, collection window, extraction time, custodian, limitations, hash.
2. assets: canonical ID, source IDs, host, environment, OS, CPU, memory, storage, owner, lifecycle, confidence.
3. performance: asset, metric, unit, average, p95, maximum, sample count, start/end, missing interval.
4. connections: source, destination, process, protocol, port, first/last seen, count, purpose, confidence.
5. applications: application, capability, criticality, components, owners, RTO/RPO, data class, strategy.
6. dependencies: application, dependency, type, requirement, migration treatment, owner, evidence.
7. readiness_gaps: gap, affected application/wave, severity, evidence needed, owner, due date.
8. waves: dependency group, prerequisites, window, tests, cutover, rollback, decommission gate.
9. decisions: decision, options, evidence, assumptions, rationale, approver, review date.

Supplied scenario

Assume the source files report:

• 52 expected servers; 48 hypervisor records; 45 successful OS collections;
• a CMDB with 50 records, 12 stale owners and 4 duplicate-looking host names;
• 30 days of telemetry, except five servers have only two days;
• shop-web calls shop-api over TCP 8443;
• shop-api calls PostgreSQL over TCP 5432 and an unowned IP over 443;
• the database performs nightly file backup to a shared NAS;
• a quarterly finance export did not occur during collection;
• Active Directory, DNS, monitoring and backup are shared services; and
• the business owner requires RTO 2 hours and RPO 15 minutes, while the runbook says RTO 8 hours and nightly backup.

Tasks

1. Calculate the four coverage measures and list every denominator assumption.
2. Keep the four duplicate-looking hosts unresolved until identifiers prove merge or separation.
3. Draw observed edges with solid lines and reported/unobserved edges with dashed lines.
4. Identify at least ten nontraffic dependencies and the evidence source for each.
5. Reconcile the RTO/RPO conflict; do not silently choose one value.
6. Decide whether shop-web, shop-api, database and NAS form one dependency group. State latency, data and rollback evidence needed.
7. Treat the unknown HTTPS destination as a wave blocker until owner, purpose, identity and treatment are known.
8. Propose a representative extension for the quarterly export and short-window servers.
9. Create three readiness gates and three measurable migration acceptance tests.
10. Propose an initial wave order, with prerequisites and a confidence label for each decision.

Linux evidence checks

Work on copies of supplied exports. Hash them before transformation:

sha256sum discovery_tool_export.zip
unzip -l discovery_tool_export.zip
mkdir -p assessment-working
unzip -q discovery_tool_export.zip -d assessment-working
find assessment-working -type f -print0 | sort -z | xargs -0 sha256sum

These commands prove file identity and contents, not correctness. Do not extract untrusted archives on a sensitive machine. Never publish raw discovery files or hashes of low-entropy secrets. Use redacted synthetic extracts in a student submission.

Diagnose misleading assessments

Never “repair” evidence by deleting inconvenient records. Preserve raw input, transformations, exclusions and decision history so another reviewer can reproduce the conclusion.

Architect and certification decision patterns

• New customer needs on-premises discovery: choose current AWS Transform capabilities, not new Application Discovery Service onboarding.
• Fast directional business case: existing inventory or accepted exports can seed assessment, but document data-quality limits.
• Application dependency mapping: collect OS/network evidence over a representative period and combine it with interviews and logs.
• Missing owner or unexplained critical edge: mark the wave not ready; do not infer approval from tool output.
• High-volume shared monitoring traffic: classify it as an operational dependency, not automatically a co-migration requirement.
• Right-sizing from a short quiet window: reject the recommendation pending representative evidence and tests.
• Legacy enrolled Application Discovery Service project: it may continue, but plan with its lifecycle and current AWS guidance explicitly documented.

Knowledge check

1. Why is a hypervisor export not a complete assessment?

It lacks business meaning and usually lacks complete guest, data, dependency, operational, security, commercial and recovery evidence.

1. Does an absent network edge prove there is no dependency?

No. It proves only that the source did not observe it within its scope, permissions, protocol visibility and time window.

1. Why might two busy servers not belong in the same application group?

Their traffic may be monitoring, backup, security or another shared operational service rather than application behavior.

1. What should a new customer use instead of onboarding to Application Discovery Service?

Current AWS Transform discovery and assessment capabilities, after verifying present requirements and availability.

1. Why preserve raw exports and hashes?

They establish provenance and allow transformations and conclusions to be reproduced, while access must still be restricted.

1. What blocks a wave even when infrastructure is fully inventoried?

Examples include unknown owners, unresolved dependencies, absent RTO/RPO, unclassified data, license uncertainty, missing target validation, or no rollback authority.

1. How should an architect treat an automated target recommendation?

As a hypothesis derived from data and assumptions, to be challenged, costed and tested before approval.

Lesson acceptance

The lesson is complete only when the learner submits:

• a source register and immutable raw-file evidence;
• reconciled asset inventory with coverage calculations and unresolved exceptions;
• application and dependency maps distinguishing observed, reported and unknown edges;
• business, technical, data, security, operational and commercial dependency records;
• confidence ratings and a data-quality/remediation register;
• at least one challenged right-sizing or cost assumption;
• candidate dependency groups and waves with prerequisites, tests and rollback; and
• a decision log that another architect can reproduce.

Reject the submission if it treats a server list as an application map, treats missing traffic as proof of independence, exposes sensitive discovery data, silently resolves conflicting evidence, proposes new Application Discovery Service onboarding, or accepts automated cost recommendations without checking inputs.

Official sources

• AWS Transform discovery tool
• Set up the AWS Transform discovery tool
• Configure the AWS Transform discovery tool
• AWS Transform data collection
• Manage discovery tool storage and retention
• AWS Transform migration assessments
• Application Discovery Service availability change