ERP migration has a reputation as the project that eats a year and a career. The failures are rarely technical. They come from migrating a process nobody re-examined, into a schema shaped by the system being replaced, in a single cutover weekend.
Audit before you migrate anything
Every long-running operation accumulates steps that exist because of a limitation in the old software. Migrating those faithfully carries the limitation forward into a system that did not need it. Map the process with the people who run it and decide what is genuinely required.
Design the schema around the operation, not the old software
The data model is the most expensive thing to get wrong, because everything downstream inherits it. Build it from the physical reality of how goods, money and approvals actually move — not from the table structure of the system you are leaving.
Never do a big-bang cutover
Run the migration repeatedly against production copies for weeks beforehand. Legacy data is never as clean as anyone expects, and the reconciliation problems need to surface while there is still time to decide what to do about them. Where the process allows, run both systems in parallel and keep the old one readable afterwards.
Build for the people on the floor
An ERP is judged by whoever enters data into it forty times a day, not by the reports it produces for the board. If that person finds it slower than the spreadsheet they were using, they will keep using the spreadsheet and your data will be wrong.