If the data you plan to migrate is currently bad, it needs to be fixed whether you do a migration or not. Bad data = useless data.
Migrations are risky, that is true. But so is every major IT project. There are ways to mitigate risk and they should certainly be planned up front in a migration.
First, you should always have a way to go back to the system as it is now. Second migrations should be done on test servers that are set up just for the migration. It is foolish to do a migration without the ability to test it first. Third, all code for the migration should be in source control.
Fourth, you need requirements and test plans before you start the migration. You need to know that if you had 1,293,687 records in the old system, that you have the same in the new or you know where they went (to an exception table perhaps). If you are normalizing a denormalized scheme, you need to calculate how many records you should end up with before you start and then check that. You need documentation that specifies what the mappings from one system to the other are. This will help your QA people check to see that the data went to the right place.
You need to determine how to handle the current bad data. What can be cleaned, what might need a value in a required field that says 'Unknown', what should be tossed out to an exception table, what needs manual intervention by a group of users (deciding if these two people are really a dup or are there two doctors in that practice with the same name for instance and if it is a dup which data to choose when the two records differ, etc.).
The key to a successful migration is planning. I have found that planning (which includes writing the test cases and unit tests) usually takes more time than the actual development.
The next key to a successful data migration is QA. This is not a project to throw at the QA team the day before launch. This is not a project to launch when QA says there is a problem.
Another key to a successful migration is to deploy the majority of the data and test it while the orginal system is still running. If you are moving lots of records this could be time-consuming and new changes will happen. So your process must be able to pull the data changes after the migration starts as well. SQL Server for instance has something called Change Data Capture which can help with this. You can take a backup of the orginal system and turn on change data capture at the same time. Then you can resotre the backup to your migration server, test the migration, get the majority of the data loaded and then you only have to load the records that have changed. When you migrate the final records, turn off the source system until the migration is done. This is one reason to migrate the majority of the records ahead of time, so the application is down the least amount of time. Choose your migration time well, don't shut the payroll sytem down the day they should process payroll or send out W2s. And do it during the low usage hours. If you have multiple clients, you could consider migrating one first and making sure all is good before doing the others. It's a whole lot easier to rollback one customer's data than 10000 if there is a problem. But plan this carefully if you do it.
If the migration involves a new user interface, please get the actual users to use it as part of the migration testing. Then train the other users before you go live (but less than a week before you go live or they will forget). Have the users involved in testing help design the training, they know what questions they had and what the people need to know in what order. Get their input, making a field required because you think it should be won't help if the users usually don't have that data when they enter the records. They will just put junk into the newly required field becasue they can't get the data in
Look at what is wrong with the current data, can you add foreign keys, constraints, triggers, business rules inthe application, default values, etc. in order to avoid this being bad in the future? When you clean bad data, you also need to create a way to avoid that simliarly bad data getting in in the future. Analyze why the bad data was alloed and fix the holes inteh design.