Do the discovery before you commit to the business case
An inventory that has not been verified against the systems is an estimate of a different platform.
A proposal to move a large Teradata platform to Oracle passed its performance testing on every scenario — and was then stopped, because discovery found a long tail of undocumented line-of-business domains that would have to be rebuilt rather than migrated, and the revised effort broke the return-on-investment model. Field note: The Teradata proposal that never happened
Three things I take from that.
The acceptance criteria measured the wrong thing. Performance was never the risk. It was chosen as the headline criterion because it was measurable, demonstrable and comfortable — it is the question a migration team knows how to answer. The actual risk was scope, and nobody had a test for it. Before you agree what a migration will be judged on, ask whether the criterion is the risk or merely the thing that is easiest to prove.
IT’s model of the platform is a floor, not a map. What the central team knows about is what has passed through the central team. The material that never did — the departmental extension, the domain that was onboarded by its own people, the area that was always going to be tidied up later — is invisible from the centre and is precisely the material with no documentation. Assume the estate is larger and less structured than the people who run it believe, and get the evidence from the systems rather than from the org chart.
A cancelled migration can be the right outcome. This is the part people find hard. Discovery did its job: it established that the programme as conceived was not worth doing, and it did so before the money was spent rather than eighteen months in with a broken business case and too much sunk cost to stop. That is a success, however it feels at the time. It is also an argument for sequencing — fund discovery as its own decision point, with an explicit possibility of stopping, rather than folding it into a programme whose approval already assumes the answer.
The practical consequence for your project: do not let the business case be built on an inventory that has not been verified against the systems. If the numbers were produced from what people believe is there, the business case is an estimate of a different platform.