Plans for replacing a system usually put migration near the end. Build the new thing, check it, then move the data across. It reads sensibly and it is the wrong order.
The data is the specification
The system being replaced has been running for years. Almost everything true about how the business actually works is in its data, including the parts nobody would think to describe in a meeting: the field used for something other than its name, the records that break the rule everyone stated confidently, the conventions that grew because the software would not do what somebody needed that week.
A new system designed from a description of the business will not survive contact with that. A new system designed against the data will, because the data is the description, written by the business over several years without anyone intending it as one.
So it moves early, and keeps moving
We move data early and repeatedly, into a live environment the client can open for themselves. Every two weeks there is something running with real records in it rather than a demonstration with invented ones. Problems in the data surface in week two instead of week twenty.
And the way back stays open
The state before the move is kept and stays restorable. Cutover is rehearsed against a copy of production data before it is done for real, and the rehearsal is timed.
How long you will be down should be a measurement, not an estimate.
None of this makes migration easy. It makes it the thing being worked on rather than the thing being postponed.