"We'd love to change our tax reporting system. But a migration like that could take a year and put next season at risk."
It's one of the most common hesitations we hear and it's a reasonable one. Replacing infrastructure that touches every client's tax position is not a decision to take lightly.
So here's what a migration realistically looks like, step by step:
The first phase isn't about moving data — it's about understanding it. Legacy classifications, historical cost bases, and country-specific fields all need to be mapped to a common structure before anything moves.
Multi-year tax positions — carried-forward losses, adjusted cost bases from corporate actions, holding periods that span the cutover date — need to remain traceable across the old and new system. This is usually where the real complexity sits, not in the data volume itself.
Before a single legacy report is retired, the new system runs alongside the old one for at least one full reporting cycle. Both outputs are compared line by line. Discrepancies are investigated, not assumed away.
Migrations rarely happen in one big switch. Countries are typically moved over individually, starting with the least complex jurisdictions, so that any issues surface on a small scale before the more intricate markets follow.
Even after cutover, the legacy system's historical data remains accessible for audit and reconciliation purposes — migrations replace the reporting engine, not the institutional memory behind it.
The honest version: a well-run migration takes months, not weeks and touches more stakeholders than just IT. But "risky" and "disruptive" are not the same thing. The risk sits almost entirely in skipping the parallel run, not in the migration itself.
