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".