Skip to content

Consulting and recruiting

Migrating executive search software: Invenias, Clockwork, Thrive, FileFinder

By SourceX Editorial · Updated

Short answer

An executive search software migration moves people, companies, assignments, notes, documents and off-limits flags from one system to another, for example between Invenias, Clockwork, Thrive or FileFinder. Map every record family and relationship before exporting, give off-limits commitments their own plan, reconcile a test load and keep a full legacy export after cutover.

Key takeaways

  • Map record families and the links between them before anyone exports a file; mapping decisions cause most data loss.
  • Off-limits flags are commitments to clients and need their own migration and test plan.
  • Notes and pipeline status history hold the firm's judgment, so preserve authors and timestamps.
  • Take a complete export of the old system before its subscription or support ends, and give it a retention rule.
  • Candidate personal data moves under the same privacy obligations as before, so carry consent status across.

What moves in an executive search software migration?#

An executive search software migration moves the firm's working memory: people, companies, assignments and the history that connects them. Systems such as Invenias, Clockwork, Thrive TRM and FileFinder organize that memory in different ways, so a migration is mostly a mapping exercise between two models of the same work.

The visible records are easy to list. The hard part is the relationships: which candidates sat on which longlists, who sourced whom, which notes belong to which assignment and which client agreed to which off-limits terms. Lose the links and the firm keeps a contact database but loses its search history.

Treat the vendor's import tools as a starting point, not a plan. Ask the new vendor which objects and fields its import supports, how attachments and history are carried, and what it cannot bring across, then write those answers into the mapping document.

Migration checklist by record family#

Work through each record family with the new vendor or your migration partner. For each one, agree what maps where, what will not move and how the result will be checked.

Migration checklist by record family
Record familyWhat to mapCommon loss
PeopleCandidates, client contacts, sources and referees with employment historyCareer history flattened into one current job
CompaniesClients, targets and prospects with parent and subsidiary linksGroup structures and former names
AssignmentsRole, client, team, dates, fee agreement reference and outcomeClosed or cancelled assignments left behind
Pipeline statusLonglist, shortlist, interview and placement stages with datesStatus history reduced to the final stage
Notes and reportsInterview notes, call notes and candidate reports with author and dateAuthors and timestamps lost on import
DocumentsCVs, position specifications, candidate reports and referencingAttachments unlinked from their person or assignment
Email and calendarLogged emails and meetings tied to people and assignmentsOnly recent or synced items moved
Off-limits flagsClient, company, scope and end date of each commitmentRule-based flags turned into static notes
Privacy and consentConsent status, data source and deletion requestsConsent status reset or dropped
Users and ownershipRecord owners, teams and access rightsRecords orphaned from departed consultants
  1. 01Your work records
  2. 02Personal details removed
  3. 03You approve the release
  4. 04Licensed to AI developers
How it works with SourceX: Your work records → Personal details removed → You approve the release → Licensed to AI developers.Illustrative

Why off-limits flags need their own plan#

Off-limits flags record commitments the firm made to clients not to approach their people, usually for a defined scope and period. They are contractual promises, so a migration error here becomes a client relationship problem rather than a data quality issue.

Systems handle off-limits differently. Some calculate it from rules attached to a client or assignment; others rely on manual flags or tags on companies and people. When the two models differ, rebuild the list of commitments from signed fee agreements and client terms, not only from the old system, then load it into the new system and test it.

  • Pick a sample of active commitments and confirm each one blocks the right people in the new system.
  • Check that expired commitments do not show as active, and active ones are not marked expired.
  • Confirm subsidiaries and acquired companies inherit the flag where the agreement says they should.
  • Have a partner sign off the off-limits list before cutover.

Running the migration step by step#

A controlled migration follows the same sequence whichever systems are involved. The steps assume the vendor or a migration partner performs the technical load, while the firm owns the decisions and the checks.

Reconciliation is more than matching totals. Pick a handful of assignments a partner knows well and open each one in both systems side by side: the longlist, the shortlist, the notes, the candidate reports and the outcome should all be there, attached to the right people. Partners spot a missing interview note faster than any count will.

  • Step 1: inventory the old system, including custom fields, tags, document stores and any linked email archive.
  • Step 2: clean duplicates and obsolete records before export, not after.
  • Step 3: agree a field-by-field mapping document and keep it as the record of decisions.
  • Step 4: run a test load and reconcile record counts, links and a sample of complete records.
  • Step 5: freeze changes in the old system, run the final load and repeat the reconciliation.
  • Step 6: keep the old system read-only, or take a complete export before its subscription ends.

What to keep from the old system after cutover#

After cutover the old system becomes an archive, and it needs an owner and a retention rule like any other record set. Take a complete export, including documents and logs, while the old subscription or server is still running, and confirm with the vendor what happens to hosted data when the contract ends.

Store the export in a controlled location with the mapping document beside it. Apply your candidate data retention policy to it: personal data that the new system would have deleted should not survive indefinitely in a forgotten export. Privacy laws such as the GDPR and US state privacy laws may apply to candidate records, and counsel assesses those obligations for the firm.

Illustrative: a search boutique changes systems#

Illustrative: a fictional executive search boutique focused on industrial and technology leadership roles has used the same on-premise search system for many years. The firm decides to move to a cloud platform when its database server reaches end of support.

The COO runs a mapping workshop with partners and the research lead. They find that pipeline status history exists only as text inside notes, that off-limits terms were tracked partly in the system and partly in a partner's spreadsheet, and that an old email sync created a large number of duplicate people records.

The firm rebuilds off-limits from signed fee agreements, migrates notes with authors and dates intact and keeps a full legacy export under a written retention rule. The test load catches attachments linked to the wrong assignment before cutover rather than after.

What the legacy archive is worth, and its limits#

A clean search archive records how assignments were scoped, how longlists narrowed and why candidates advanced or stopped. That decision history has internal value for training researchers and building firm playbooks, and parts of it may interest AI developers working on recruiting and professional judgment tasks.

Candidate personal data limits what can be done. Names, career histories and interview notes about identifiable people carry a heavy privacy burden, and fee agreements usually make assignment details confidential. In the SourceX five-step transaction, the Rights step separates firm-owned process records, such as position specification templates and assessment frameworks, from candidate and client data. The first assessment involves no candidate files at all, and the firm decides at each step whether to go further.

Frequently asked questions

Should we migrate all history or only recent records?

Migrate what consultants actually use and keep the rest in a controlled export. Older records that are rarely opened still carry privacy obligations, so a migration is a good moment to apply your retention policy rather than copying everything forward by default.

Can the new vendor handle the migration for us?

Many vendors offer migration services or work with partners, but the firm still owns the mapping decisions and the checks. Ask which objects and fields are supported, how attachments and history are handled and how many test loads the service includes.

How do we handle duplicate people records?

Deduplicate before export where possible, using email, phone and employment history as match keys, and have a researcher review uncertain merges. Merging after import is harder because notes and pipeline history may already be split across the duplicates.

What happens to emails stored in the old system?

Emails logged against people and assignments should move with their links if the new system supports it. If not, keep them in the legacy export with enough metadata to find them later. Check whether the old system stored full messages or only references to a mail server.

Do candidates need to be told about the migration?

Usually not for a like-for-like system change, since the purpose of processing stays the same. Your privacy notice should still describe the vendors and hosting you use, so update it if the new vendor or data location differs. Confirm the position with counsel.

Should consultants keep working in the old system during the migration?

Only until the freeze. Agree a cutoff after which no new notes or status changes go into the old system, and tell consultants where to log work during the gap. Changes made after the final export are the most common source of missing notes after go-live.

Related resources

See if your company qualifies

A short company assessment. No data uploads are needed.

See if your company qualifies