Application Discovery
Establishing what applications exist, what they depend on, who owns them and whether anyone uses them — the step whose absence makes every later step a guess.
Most organisations do not have a reliable list of their own applications, and a migration plan built on an unreliable list produces surprises at cutover.
The sources that give honest answers, in order of reliability: network flow logs (what actually talks to what — the only trustworthy source for dependencies), authentication logs (whether anyone logs in, which is the fastest honest answer to "is this used"), the CMDB and licence agreements (a starting point, usually incomplete), and interviews last, because people describe the system they believe exists.
What must be captured per application: a named owner, the dependencies in both directions, actual usage, run cost, data classification and criticality.
The finding that repays the effort is retirement. Discovery consistently identifies applications nobody uses, applications superseded but still running, and duplicate implementations of the same capability — and switching one off is cheaper and faster than migrating it. Starting the migration with the retirement list is the single highest-return move available.
The other reason it matters: undiscovered dependencies are what break cutovers. An application moved without knowing that a nightly job on another host reads its database will fail at 2 a.m. on the first night, and nobody will connect the two events quickly.