A cloud migration discovery phase is the work done before anything moves: finding every server, database and connection in the estate, measuring how each one is used, and deciding what happens to it. A proper one produces four things: a verified inventory, a dependency map, a sizing baseline and a decision for each application. Without them, a migration plan is a guess with a Gantt chart on it.
Why discovery decides the timeline
Most migration plans start from a list: a spreadsheet, a CMDB export, or whatever the infrastructure team remembers. That list is almost always incomplete. The surprises arrive mid-project: a server nobody owns, a nightly file transfer to a supplier, a licence tied to a physical host. Each one stops a wave of work while somebody investigates.
Discovery moves those surprises to the start, when they cost a conversation rather than a delayed cutover. It is why the timeline in How Long Does a Cloud Migration Actually Take? depends so heavily on estate complexity, not just server count.
The five outputs of a proper discovery phase
| Output | What it contains | Why it matters |
|---|---|---|
| Verified inventory | Every server, database and storage system, with an owner | You cannot migrate, or retire, what you have not found |
| Dependency map | Which systems talk to which, on which ports, including external parties | Systems that depend on each other usually have to move together |
| Utilisation baseline | CPU, memory and disk use over time, including peaks | Sizes the target estate and spots idle servers before you pay to move them |
| Application decisions | One of the 7 Rs per application: rehost, replatform, retire, retain and so on | Stops everything defaulting to lift and shift |
| Constraints register | Licences, contracts, support end dates, regulated data, downtime windows | Sets the order in which things can move |
What to collect, and how
No single method sees everything. Most discovery work combines automated collection with conversations with the people who run the systems.
| Method | What it sees | Limits |
|---|---|---|
| Agentless collector | Server configuration, disk allocation, database versions, and average and peak CPU, memory and disk I/O, collected through VMware vCenter | Per AWS’s documentation, it cannot look inside each VM to see which processes are running |
| Agent on each server | Configuration, detailed performance over time, inbound and outbound network connections and running processes, on Windows and Linux servers, including physical ones | Needs installation and access to every server |
| Imported records | Whatever your CMDB or spreadsheets already hold | Only as accurate as the source |
| Owner interviews | Business purpose, hidden jobs, planned changes | Memory and goodwill vary |
(Check before publishing: AWS has been changing its discovery tooling. At the time of drafting, the Application Discovery Service documentation says the service “is no longer open to new customers” and points to AWS Transform for similar capabilities. Confirm what is available on the publish date. Our post on AWS Migration Hub alternatives covers the wider change.)
Whichever tool is used, capture at least a month of utilisation data. A server that looks idle in a quiet week may be the one that runs month-end reporting.
Dependencies are where plans break
Network connection data tells you what talks to what, but it cannot tell you why. The usual hidden dependencies are scheduled jobs that push or pull files, hard-coded IP addresses in application configuration, shared databases used by three applications, licence servers, and certificates or DNS entries managed by someone outside the project team. Mapping them early is what lets you group servers into sensible migration waves rather than moving an application and then discovering its database stayed behind.
A worked example
(Illustrative.) A UK wealth manager believes it has 45 servers running 12 applications. Four weeks of discovery, with agents on every server and a month of utilisation data, finds this:
| Before discovery | After discovery | |
|---|---|---|
| Servers | 45 | 53 (8 not on the list; 5 idle test machines, 3 live) |
| Applications | 12 | 14 |
| Known dependencies | None documented | 9 found, including a nightly file transfer from the reporting server to a custodian |
| Servers using under 5% CPU for the full period | Not known | 11 (candidates to retire or downsize) |
| Plan | 3 waves, all rehost | 4 waves: 7 apps rehosted, 3 replatformed, 2 retired, 2 retained |
The reporting application moves in a later wave than first planned, because the custodian’s file transfer needs re-pointing and testing before cutover. Retiring two applications and downsizing eleven servers means fewer things to pay for after the move. None of this would have appeared in the original spreadsheet.
The regulated-firm layer
For FCA-regulated firms, discovery also needs to record things a technical inventory would not:
- Data classification and location: what each system holds, and where that data is allowed to reside.
- Important business services: which systems support each one, because that decides which can tolerate downtime during cutover (see FCA operational resilience).
- Third-party connections: custodians, market data feeds, payment providers, and their contracts.
- Exit and rollback needs: what you would do if a cutover failed, and how you would leave AWS later.
(Check before publishing: whether the move counts as material outsourcing under the FCA’s rules (SYSC 8) and whether notifying the FCA is required. Confirm against the current FCA Handbook wording.)
What you should have at the end
A discovery phase is finished when you hold a signed-off inventory, a dependency diagram for each application, a decision and an owner for each, a list of constraints, and a draft wave plan. That is also what a landing zone design needs as input: accounts, networks and access rules built around the workloads that are actually moving.
Where to start
You do not need a large programme to begin. Pick your most important application, find everything it touches, and see how closely the result matches what your documentation says. The gap is usually instructive.
A Yemberzal Cloud Migration Assessment is a fixed-fee piece of work that maps every workload and dependency before a price is set for moving anything.
