A migration copies everything, including what is wrong
Changing ATS is the one moment every record you hold gets picked up and put down again. The vendor's migration moves what is there, faithfully. Two records for the same finance director arrive as two records. A candidate with a name and nothing else arrives as a name and nothing else. The title somebody held four years ago arrives as their title.
After the move the clean-up gets harder, not easier. Record ids change, the team is learning different screens, and nobody has the appetite. Before the move, the same work is a filter on an export.
This is narrower than making an old database searchable again, which is upkeep on a system you are keeping. This one has a destination, and it ends in files shaped for the import.
What you get back
A count of what you hold, split by what each record can be matched on. A list of likely duplicate pairs, people and companies, each with the reason. A list of people with no email, no mobile and no LinkedIn URL. And for the segment you chose, the current title and employer beside the ones on file.
Then the export: people and companies in the destination's column names, with the duplicate and no-identifier flags as their own columns, plus the list of your fields that had no column to go to.
What this play does not do
Hyreflow reads and writes records through the systems you connect. It does not run the vendor migration. It does not move CVs, documents or attachments. It does not map every custom field. Notes, activity history, placements and pipeline stages stay with the vendor's process.
Variations worth knowing
Fix the source, not the file. Approved corrections can be written back to the system you are leaving, one record first, so the vendor's extract already carries them.
Pilot the destination. If the destination is a system you can connect, a small approved batch of people and companies can be created there through its connection. You see how your data looks on those screens before the bulk import.
Leave people behind. Records with no identifier at all are the obvious candidates for staying behind, which is also a retention question. The list is the input. The decision belongs to you and whoever advises you on data protection.
Where this goes wrong
Running it after the extract. Corrections made once the vendor has taken the data have to be made again on the other side.
Refreshing everything. Every refreshed profile is a paid lookup. Refresh the people you could place this year and migrate the rest as they are.
Expecting merged records. Pairs are flagged. Merging happens in your ATS, by you, with its own tool.
Treating the export as the migration. It carries people and companies. It carries no CVs and no history.
