The data is not the problem, but the person who has been living inside that system for five years usually is.
Every migration I have done has a moment, usually about three weeks in, where someone on the team looks at a field and says “why does this column have values like ‘GB’, ‘United Kingdom’, and ‘uk-london’ all meaning the same thing?”, and the answer is always the same: there was no country field, so someone used what was available, the shipping address line 3, the region code, the account notes, whatever worked when they needed it, and they never documented it because to them it was obvious, and it stayed obvious for five years because they were the only one who ever touched it.
We had a case once where the system had no country attribute at all, the data looked clean and structured and consistent, exports for the UK office had the right format every time, so we assumed it was a system setting, but it was not. The admin had been setting the locale field to a specific string for five years, and when that string hit the address printing template it came out right, the locale field, not the country field, and she was the only person in the building who knew this.
You will not find this in the schema documentation, because it is not there, and you will not find it by profiling the data, because the data looks perfectly reasonable until you understand what it is supposed to mean, and you will not find it in any handover document anyone was asked to write. You find it by sitting with the person, watching them work, and asking why.
Most migration projects budget for data profiling, for ETL development, for testing, for cutover, but very few budget for “sit with the user for a week and watch what they actually do,” and that is the work that prevents the big surprises at go-live, and it is almost always the first thing cut when timelines get tight.
Question is not whether you can move the data. Question is whether you understand it well enough to move it correctly. The technical preparation — auditing, schema mapping, rollback planning — is covered in how to plan a database migration, but that work only lands if you have already done this part.