Every AWS migration programme I've sat in the kickoff for has had the same energy. Sponsors are bought in, the business case is signed off, and someone has put a wave plan on a slide with twelve neat blocks marching left to right across eighteen months. Six months later, that programme is often still in discovery — no servers moved, no waves started, and a steering committee asking why the "simple lift-and-shift" hasn't produced a single migrated workload. The technology was never the problem. The discovery phase quietly became the whole programme.
The Trap Is Built Into the Tooling
AWS gives you good instruments for this stage: Application Discovery Service agents or agentless collectors pulling CPU, memory, and network flow data; Migration Evaluator turning that into a business case; Migration Hub stitching the picture together. They work. The trap isn't the tooling — it's what teams do with the output. A collector running across a 1,200-server estate will, within weeks, surface thousands of network connections, dozens of undocumented dependencies, and thirty different "we think this might still be in use" applications nobody can confidently name an owner for.
At that point, the natural instinct — especially in regulated environments where a wrong move has consequences — is to chase completeness. Map every dependency. Confirm every owner. Validate every data flow before committing to a single wave. That instinct feels like rigour. In practice it's analysis paralysis wearing a high-visibility vest, and it can run for months because nobody on the programme has the authority, or the nerve, to say "we know enough to start."
Why Nobody Calls Time
Three things conspire to keep discovery running long after it has stopped producing useful decisions. First, incentives: if your delivery partner is on a time-and-materials discovery contract, there is no commercial pressure to declare the phase finished — quite the opposite. Second, fear: in financial services, healthcare, and central government, the person who signs off the wave plan is also the person who answers for an outage, so erring towards "more data" feels like the safer career move even when it isn't the safer delivery move. Third, and most common, there's simply no single owner for the judgement call of "good enough." Discovery becomes a never-ending data-quality exercise because the alternative — making a risk-based decision with imperfect information — requires someone senior enough to own that decision and defend it later.
That's the part most migration playbooks skip. They'll tell you which AWS service maps which dependency. They won't tell you who in your organisation is allowed to say "stop mapping, start moving."
What "Good Enough" Actually Looks Like
The estates we've worked through don't need uniform rigour. They need tiered rigour, applied deliberately:
- Tier 1 — regulated, customer-facing, or business-critical: full dependency mapping, named application owners, explicit sign-off from the risk and security functions before a migration date is set. This might be 10–15% of the estate and genuinely warrants the months of care.
- Tier 2 — standard line-of-business applications: pattern-based grouping. If twenty applications share the same OS version, the same database engine, and broadly similar traffic profiles, they don't each need a bespoke dependency map — they need a representative sample validated, then the pattern applied across the group using the standard 6 R's (rehost, replatform, refactor, retire, retain, relocate).
- Tier 3 — anything nobody can name an owner for after two weeks of asking: default to "retain and revisit." Trying to migrate an application nobody will claim is how migration timelines die. Park it, flag it for the retirement conversation, and move on.
This isn't cutting corners. It's recognising that the cost of over-investing in discovery on low-risk workloads is just as real as the cost of under-investing on high-risk ones — it's just better hidden, because it shows up as a missed deadline rather than an incident.
Capping Discovery at Six Weeks
Here's the structure that has actually held up across multiple regulated-sector migrations:
Weeks 1–2: Deploy agentless collectors across the full estate while running structured interviews with the twenty or so application owners who matter most — the Tier 1 candidates. You're not waiting for the collectors to finish; you're running both tracks in parallel because the human conversations surface context the telemetry never will (the application that looks idle but runs the year-end batch, the "decommissioned" service still receiving traffic from a forgotten integration).
Weeks 3–4: Run a wave-grouping workshop with the data you have — not the data you wish you had. Group by pattern, assign R-strategies, and explicitly name the unknowns rather than letting them silently inflate the "needs more analysis" pile. An unknown that's been named and assigned an owner to chase is a tracked risk. An unknown that's been quietly left in the "still mapping" bucket is a programme slip waiting to happen.
Weeks 5–6: Stand up the migration factory — landing zone guardrails, Application Migration Service replication for the first wave, runbooks, rollback criteria — and select wave one from the lowest-risk, highest-confidence group. The point of wave one isn't to migrate the most valuable thing first. It's to prove the factory works on something survivable, then accelerate.
Six weeks sounds aggressive next to the six-month default. It isn't, once you accept that wave two will always know more than wave one, and that's fine — that's the model working as intended, not a discovery failure.
The Judgement Call Is the Job
This is where consulting actually earns its fee, and where it's most often absent. Anyone can run a collector and produce a dependency report. What a programme actually needs at the six-week mark is someone senior enough — and accountable enough — to stand in front of a steering committee and say "this is what we know, this is what we don't, and here's why we're moving anyway." That's not a technical skill. It's judgement, backed by enough hands-on delivery experience to know which unknowns are survivable and which aren't. We've built Kineticor around exactly that combination — senior engineers who've run the migration factory themselves making the call alongside the client, rather than handing down a generic playbook and disappearing when the awkward decisions show up.
If your discovery phase has been running for more than six weeks without a wave plan you'd actually defend in front of your risk committee, that's not a sign you need more data. It's a sign you need someone to own the decision to stop collecting it.
How Kineticor Can Help
We run AWS migration discovery as a time-boxed, decision-oriented exercise — not an open-ended data-gathering contract. That means tiered dependency mapping calibrated to actual risk, wave plans built on patterns rather than perfection, and a senior engineer in the room who can make the "good enough" call and stand behind it. If your migration programme is stuck in analysis and you want a second opinion on how to get it moving, get in touch.
— Danish
Danish Muhammad
Founder, Kineticor
I help businesses achieve their vision by making the cloud work for them — efficiently, securely, and at scale. Beyond technical solutions, I focus on solving real-world challenges, aligning cloud strategy with business goals, and building high-performing teams. My background is technical delivery; my passion is solving people problems. Connect on LinkedIn.