A program rarely fails on the processes. It fails on the data beneath them — and that sits on no board slide.
I have seen three very different cases, with the same lesson. In the first, a company was already struggling with its master data before I arrived; the consolidation concept was so complex it threw me — partly because they wanted to solve it in one big move instead of step by step. It never came to implementation; in the end the blueprint missed the target. In the second, a rebuild after a spin-off, the master data was genuinely cleaned and only the valid records extracted — planned from the start, analyzed, valued, integrated into the project pipeline. In the third, again a spin-off, the data sat neatly encapsulated in its own client: system copy, delete the surplus clients, export for the move. Done.
The tax nobody plans for
The difference between these cases was not the technology, but the preparation. Unprepared, each of the three scenarios would have hit deep. Well planned, the cleanup was just another line item — in the consulting effort for the extraction, or in the downtime for the deletion. Sometimes the migration even forces the cleanup; the move to the central business partner in S/4 is such a case. Precisely then it belongs up front.
Master data is at least as important as processes, and because of its sheer mass often far more effort. Since a program mobilizes, tests and signs off the people anyway, the migration is the opportunity to straighten it out: for fewer errors, more transparency, and the full effect of the integrated system.
How you tell before the start whether you have a data problem: is there a dedicated workstream and a clear plan for the data? Are several test runs foreseen? Because between the first plan, sandbox, test runs and production cutover, more than six months easily pass — and in that time the data keeps growing. „We’ll clean it up during the migration“ fails on exactly that: you clean up a state that, by go-live, no longer exists.
