Almost every transformation programme I’ve joined came with a target architecture already drawn. A clean diagram, usually good. Landing zone on the left, workloads in tidy boxes, arrows that all point the right way.
The programmes that worked are the ones where we were willing to throw that diagram away after discovery. The ones that struggled kept it, and spent the budget finding out where reality disagreed.
I’ve written about migrations being org problems first and about the operating model being the product. This is the technical half of the same argument. The dependency map is the architecture artefact. The target diagram is a hypothesis until the map says otherwise.
What discovery is not
An inventory. A spreadsheet of VMs, instance sizes and disk volumes is useful for a cost estimate and useless for a plan. It tells you what exists in isolation. Nothing in a migration fails in isolation.
Interviews, on their own. People describe the system they built, the system they remember, or the system they’d like to have. All three differ from the one running in production, and the gap is precisely where cutovers go wrong.
What it is
Three outputs, in this order.
A dependency graph of what actually talks to what. For a marketing-technology SaaS provider in India I ran an on-site discovery across roughly 150 services on EC2, EKS and Lambda, spread over multiple AWS accounts in India, the US and the EU, with MySQL, MongoDB, Cassandra, DynamoDB, Redis, Vertica, ClickHouse, Kafka and S3 data lakes underneath. The deliverable that mattered was not the list of 150 services. It was the map of which of them could not move without which others, because that map is the migration sequence.
A list of the decisions the organisation has been avoiding. Every discovery surfaces a few. The shared database nobody owns. The service two teams both think the other one runs. At Koo, moving 40+ application services, 48 ML services and 21 databases from AWS to GCP inside a fixed four-month window, the hard constraint wasn’t any single service. It was a single shared central database with dependencies across the estate. The migration plan was, in effect, the plan for that one database. Everything else followed from how we resolved it.
A sequence ordered by value and risk, not by ease. The instinct is to move the easy workloads first to show progress. The problem is that easy workloads teach you nothing about the hard ones, and the hard ones are where the programme’s risk lives. I’d rather sequence so the riskiest dependency gets tested at its cheapest point, which usually means moving something uncomfortable early with a rollback still open.
When there’s nothing to map from
The purest version I’ve done was on an AWS migration programme for an urban and infrastructure consultancy in Singapore. Legacy applications, dependencies undocumented, the original engineers gone.
We stopped asking and started observing. We reverse-engineered the dependencies from live network traffic and built the map from what actually talked to what. Then we migrated by staged traffic shifting, 10% to 25% to 75% to 100%, validating against the map at each stage and keeping the rollback path open until the final shift.
Two things I took from that. The observed system is the only reliable specification. And staged shifting turns one unknowable migration into a series of small, reversible ones, each of which tests an assumption in the map before the next one depends on it.
The executive version
Discovery has a second audience, and it isn’t engineers.
For a logistics-technology company in India, the output of a two-week on-site discovery was a target GCP architecture and a TCO and cost-comparison model that their leadership could actually decide on. Not a diagram. A decision, with numbers and dates attached, that a CFO could say yes or no to.
That’s the test I now apply to any architecture artefact for an executive audience: can someone decide something from it? A roadmap that can’t be decided on is a picture. A dependency map with a sequence and a cost is a decision waiting for a signature.
What people get wrong
They treat discovery as a phase to get through so the real work can start. It is the real work. The build that follows a good discovery is mostly execution; the build that follows a bad one is discovery again, with production traffic on it.
They draw first and map second, then defend the drawing. The diagram acquires sponsors. Correcting it becomes a political act rather than a technical one. Drawing after mapping avoids the whole problem, and it costs nothing but sequence.
And they interview when they should observe. If a question about the system can be answered by looking at the system, look. The people are for the questions the system can’t answer: what it’s for, what’s allowed to break, and who decides.
Map what exists. Then draw what should. The order is the method.