You are asked to lead a migration of 300 applications to cloud. What happens in the first ninety days?

Days 1–30: discovery, and the foundation in parallel

Discovery from evidence, not interviews. Network flow logs for dependencies (the only trustworthy source), authentication logs for whether anyone actually uses each application, the CMDB and licence agreements as a starting point, and interviews last — because people describe the system they believe exists.

Per application, capture: named owner, dependencies in both directions, actual usage, run cost, data classification and criticality.

In parallel, start the landing zone, because it gates everything and has a long lead time: account structure, non-overlapping address plan, identity federation, centralised logging, baseline guardrails, tagging enforcement.

Days 30–60: disposition and the pilot

Assign a disposition per application — retire, repurchase, rehost, replatform, refactor, retain — rather than one strategy for the estate. A migration that refactors everything does not finish; one that rehosts everything arrives with the same problems and a higher bill.

Start with retirement. Discovery consistently finds applications nobody uses, superseded systems still running and duplicate implementations. Switching one off is cheaper and faster than migrating it, and it is the highest-return action available.

Run a pilot wave of low-risk, low-dependency applications chosen to prove the process, not to deliver the most value. Its output is a tested runbook, real timings and a list of surprises.

Days 60–90: wave planning and factory setup

Group into waves by dependency cluster, so tightly coupled applications move together — otherwise an application in cloud whose database remains on-premises runs every interaction across a slow, expensive link.

Sequence around the business calendar. Month-end, year-end and peak trading are not migration windows, and waves that ignore them do not happen.

Build the migration factory: repeatable tooling, a standard runbook, a testing and acceptance process, and a defined rollback for each application type. The pilot's learnings feed this directly.

What to be honest about

Ninety days produces the inventory, the retirement list, the foundation and a proven process. It does not migrate much, and promising otherwise is how these programmes lose credibility in the second quarter.

What a strong answer adds

Naming the two things that most often derail large migrations: undiscovered dependencies, which break cutovers at 2 a.m. on the first night; and business availability to test and accept, which is a scheduling constraint rather than a technical one and is routinely omitted from the plan.