I'm probably reading your problem wrong ... but ...

Data Catch-Up ? What are you catching up ? Are you migrating and mapping data from some source-to-target (another system) ? Is there a table with data somewhere waiting to update the current database (ie: LockBox - a collection payments, orders, etc. that needs processing).

What could the user requirements be on a data migration ? ... "The Data Must Be Migrated Correctly And Available For Use By Monday Morning" ? Other user requirements could be identifying, processing, running reports on the migrated data differently ... which could be programming / user interface changes.

Don't you have a test database somewhere to initially load the migrated data in, unit test it and run current applications against it to test the successful mapping of migrated data ?

Now that things look OK, you will move the data into the production database and test again for success ... 

"a solution for a data catch up (between the migration phase and the go live phase of a migration program)." ... isn't that the QA part of the migrated data with end-users, test scripts and scenarios to verify that the new data was mapped correctly for your current system applications ?

Make sure none of the migrated will overlay any of the current system data ... wiping out current stuff with older stuff.

Do you have a Roll-Back plan in case something goes wrong on the production system ?

Like I said ... I probably read it all wrong and am missing some computer term ... but I'm not familiar with a "Data Catch Up".

Depending on technical you are, I would take a look at the databases you are using for migration ... check the data you have and where to put them in the new database (data mapping) ... data might be the same but field names might be different or one field might now hold the concatenation or calculations of other fields, etc.

Data mapping always took the longest for me because I was not familiar with the other system ... I usually worked with some tech person from the new database ... once that was done, then I could write the specs so it is know what goes where, what does not, needed database changes, etc. I usually set up an As-Is / To-Be database table images and showed the data migration in pictorial form.