The situation
A large estate of legacy reports needed moving to a modern self-serve BI tool. The risk in any reporting migration is not technical — it is that a number changes during the move, nobody can explain why, and the new tool loses credibility permanently.
What I did
- Migrated reports with side-by-side validation against the legacy version, so any difference was identified and explained before cut-over rather than discovered afterwards.
- Folded data-quality improvements into each migration instead of faithfully reproducing known-wrong numbers.
- Where a number legitimately changed because the old one had been wrong, made that explicit rather than quietly shipping it.
- Ran the same approach on a separate compliance-sensitive multi-market reporting migration, validated against the source of truth with a controlled rollout and sign-off from the relevant safety and compliance team.
What it means for you
Reporting migrations fail on trust, not on technology. Validating every report against the one it replaces — and being explicit when a number changes because the old one was wrong — is what keeps the new tool credible.
Context
These are from eight years owning the data warehouse and reporting function of a consumer marketplace platform, in-house rather than as an outside consultant. The employer and the internal system names are withheld; the numbers are the real ones.