How to Migrate Recruitment CRM Without Losing Your Data—or Your Mind

The fear of migration keeps many recruitment agencies on systems they no longer want.

That fear is understandable.

A recruitment CRM can contain years of:

• Candidate relationships
• Client history
• Contact details
• Vacancy records
• Submissions and interviews
• Placement information
• Consultant notes
• Emails
• CVs and compliance documents
• Marketing preferences
• Custom fields
• Tasks and reminders

A poor migration can preserve the obvious records while losing the information that gives them meaning.

The candidates may appear in the new system, but no longer be connected to the correct vacancies. Contacts may arrive without their companies. Notes may lose their dates or authors. Documents may be missing. Opt-outs may be reset. Historic placements may appear as active jobs.

The migration can therefore look successful at first glance and still fail operationally.

A reliable migration is not a file transfer. It is a controlled reconstruction of the agency's data, relationships, permissions and working processes in a new environment.

Begin by defining what success means

"Move all our data" is not a useful migration objective.

It does not explain:

• Which data must move
• Which data should not move
• Which relationships must be preserved
• How much history is required
• Which workflows must work on day one
• What level of downtime is acceptable
• How accuracy will be tested
• Who can approve the result
• What happens if the cutover fails

A better migration brief defines measurable outcomes.

For example:

• Every active candidate is available in the new CRM.
• Companies and contacts remain correctly connected.
• Historic submissions, interviews and placements remain searchable.
• Notes preserve their date and author where the source system provides them.
• CVs and required compliance documents can be opened.
• Existing opt-outs and communication restrictions remain enforced.
• Users see only the records they are authorised to access.
• Active jobs and placements continue from the correct stage.
• No changes made after the test migration are lost at cutover.
• The agency can respond to data-rights requests covering both historic and current information.
• The old system can be recovered or consulted during an agreed transition period.
• The old supplier deletes or returns the agency's personal data when instructed under the contract.

The project should have a named owner inside the agency, even when the new vendor performs the technical work.

The supplier can extract, transform and load the data. The agency must still decide what the records mean and whether the result is operationally correct.

Understand who remains responsible for the data

Changing CRM does not transfer the agency's accountability to the software provider.

The recruitment agency will normally remain the controller because it decides why and how candidate and client personal information is used. The CRM provider will generally act as a processor on the agency's instructions, although the precise legal roles depend on the actual processing arrangements.

The agency should therefore understand:

• What information the old provider holds
• What the new provider will receive
• Which sub-processors are involved
• Where the data will be stored and accessed
• Whether any international transfers occur
• How temporary migration files will be protected
• When the old provider will delete remaining copies
• How data rights and security incidents will be handled

UK GDPR processor contracts must include appropriate provisions, including instructions, confidentiality, security, assistance with data-subject rights and end-of-contract arrangements. At the end of the service, the processor must, at the controller's choice, return or delete the personal data and delete existing copies unless the law requires continued storage.

If the new supplier or one of its sub-processors accesses the information outside the UK, the agency must also establish whether the arrangement creates a restricted international transfer and what safeguard applies.

These issues should be resolved during procurement, not after the export has already been uploaded.

Give the migration clear ownership

A migration tends to involve at least four different kinds of knowledge:

Business knowledge

Someone must understand how consultants actually use:

• Candidates
• Companies
• Contacts
• Jobs
• Pipelines
• Placements
• Tasks
• Notes
• Documents
• Custom fields

Data knowledge

Someone must understand:

• Source tables
• Unique identifiers
• Field formats
• Relationships
• Duplicates
• Historic values
• Attachments
• Export limitations

Technical knowledge

Someone must manage:

• Extraction
• Transformation
• Secure transfer
• Import order
• Error handling
• Performance
• Final synchronisation

Governance knowledge

Someone must consider:

• Retention
• Lawful basis
• Data accuracy
• Restrictions and opt-outs
• Access permissions
• Processor contracts
• Security
• Individual rights

A small agency may have one person covering several of these roles. The important point is that none of them should be left implicitly to "the migration team."

A practical project structure includes:

• An agency project owner
• A vendor migration lead
• One or more operational testers
• A data-protection or compliance contact
• A final decision-maker for cutover
• A documented escalation route

The person approving the migration should understand the business records, not merely the import report.

Audit the source system before designing the migration

You cannot map information you have not identified.

Begin with an inventory of the current system.

Record types

Count and review:

• Candidates
• Companies
• Client contacts
• Jobs
• Candidate submissions
• Interviews
• Offers
• Placements
• Temporary bookings
• Shifts and timesheets
• Tasks
• Notes
• Emails or communication records
• Invoices
• Compliance checks
• Consent and lawful-basis records
• Suppression records
• Users and teams

Documents

Identify:

• CVs
• Formatted CVs
• Right-to-work evidence
• Contracts
• Terms
• Assignment documents
• Key Information Documents
• Interview documents
• Offer letters
• References
• Client agreements
• Timesheet attachments
• Other uploaded files

Configuration

Record:

• Pipelines and stages
• Status values
• Custom fields
• Option lists
• User roles
• Access permissions
• Automations
• Email templates
• Saved searches
• Tags
• Sources
• Reasons for rejection or withdrawal
• Compliance categories

Integrations

Identify systems connected to the current CRM:

• Email and calendar
• Job boards
• Careers site
• Payroll
• Accounting
• Timesheets
• Telephony
• Document signing
• Data enrichment
• Marketing platforms
• Browser extensions
• Reporting tools

The objective is not simply to count rows. It is to understand which information is needed to preserve the agency's ability to work.

Decide what should move—carefully

Migration is a useful opportunity to improve data quality, but "clean up before importing" can become an excuse for arbitrary deletion.

UK GDPR requires personal information to be adequate, relevant and limited to what is necessary, accurate where required and retained no longer than needed for its purpose.

That does not mean every old candidate should automatically be deleted.

Historic information may still be needed for:

• Ongoing candidate relationships
• Defending or pursuing legal claims
• Fee disputes
• Rebate obligations
• References
• Compliance evidence
• Tax and accounting requirements
• Subject access requests
• Restrictions or objections
• Understanding historic placements
• Preventing someone who opted out from being contacted again

The agency should therefore define migration categories.

Migrate as active

Records still being used operationally, such as:

• Active candidates
• Live client contacts
• Open jobs
• Current placements
• Outstanding tasks
• Valid compliance records
• Current campaigns and opportunities

Migrate as historic

Information that is no longer active but still has a legitimate purpose, such as:

• Previous placements
• Closed jobs
• Historic submissions
• Relevant notes
• Client relationship history
• Completed compliance evidence still within retention

Retain with restricted use

Some information may need to remain available without being used for ordinary recruitment or marketing.

Examples include:

• A person who has objected to particular processing
• A record subject to a temporary restriction
• Information retained for a legal claim
• A dormant record awaiting a retention decision
• A suppression record

When someone objects to direct marketing, the ICO recommends retaining a minimal suppression or "do not contact" record rather than simply deleting every trace, because otherwise the person may be imported and contacted again.

Do not migrate

Information may be excluded where:

• It is an exact duplicate.
• It is demonstrably corrupt.
• It has no continuing purpose.
• The agency's retention policy requires deletion.
• It was created for testing.
• It belongs to a former tenant or another organisation.
• It is unnecessary system data with no business meaning.

Every exclusion rule should be documented and tested before deletion occurs.

A migration is not the right moment to discover that "inactive" was used inconsistently and included people whose placements were still running.

Protect open legal, compliance and rights matters

Before removing or consolidating information, identify records connected to:

• Subject access requests
• Erasure requests
• Restrictions on processing
• Objections
• Complaints
• Data breaches
• Employment disputes
• Fee disputes
• Litigation or anticipated claims
• Regulatory enquiries
• Audit requirements

An individual can request access to their personal information, and the controller remains responsible for making a reasonable and proportionate search. Processor contracts should ensure that suppliers help the controller meet those obligations.

If relevant personal data remains only in an inaccessible legacy backup or an undocumented export folder, responding to a future request becomes difficult.

The migration design should therefore record:

• Which system contains the authoritative information
• How historic data can be searched
• Whether document text is searchable
• How restricted records are marked
• Whether deletion requests propagate to migrated copies
• How temporary exports and test environments are handled
• Who can retrieve information from the legacy system

Do not delete or transform information involved in an active dispute without appropriate legal or professional advice.

Preserve relationships, not just records

The most important part of recruitment data is often the relationship between records.

A candidate record has limited value unless the system also knows:

• Which jobs they were considered for
• Who submitted them
• Which client received the profile
• What stage they reached
• Why they were rejected or withdrew
• Whether they were interviewed
• Whether they were placed
• Which consultant owns the relationship
• Which communications and documents belong to them

Likewise, a client contact should remain connected to:

• The correct company
• Relevant jobs
• Interviews
• Placements
• Notes
• Commercial terms
• Opportunities
• Communication history

This is known technically as referential integrity.

A simple CSV import often moves individual tables but fails to reconstruct the links between them.

A migration plan should therefore identify:

• The unique identifier for every record
• The parent and child relationship
• Whether a relationship is one-to-one, one-to-many or many-to-many
• What happens where a referenced record no longer exists
• The order in which records must be imported
• How source identifiers will be preserved for validation

For example:

1. Companies are imported.
2. Company contacts are connected using the original company identifier.
3. Jobs are connected to the correct company and contact.
4. Candidates are imported.
5. Submissions link candidates to jobs.
6. Interviews link submissions, candidates, jobs and contacts.
7. Placements link the final candidate, job, company and consultant.
8. Notes and documents attach to the correct records.

If the import creates new identifiers, retain a cross-reference between the old and new IDs. Without it, investigating discrepancies becomes much harder.

Build a migration data dictionary

The technical heart of the project is the mapping document.

For each source field, record:

• Source table or object
• Source field name
• Description
• Data type
• Example value
• Allowed values
• Whether it can be empty
• Destination object
• Destination field
• Transformation rule
• Default value
• Validation rule
• Whether the source value is retained
• Owner of the mapping decision

For example:

This work reveals decisions that a blind import hides.

What should happen when:

• The old status has no new equivalent?
• A date is invalid?
• A mandatory new field did not exist previously?
• Several old fields now become one?
• One old field must be divided into several?
• A former consultant no longer has an account?
• A custom option was misspelled in historic data?
• The same email belongs to several records?
• A company appears under several legal or trading names?

There is rarely one universally correct answer. The mapping must reflect the agency's actual process.

Do not let custom fields disappear silently

Custom fields often contain business-critical information precisely because the original CRM did not have a standard place for it.

They may hold:

• Security clearance
• Work preferences
• Client tier
• Candidate availability
• Fee agreements
• Notice period
• Payroll information
• Compliance status
• Business-development ownership
• Historic system identifiers

Each custom field should be classified as:

• Migrate into a standard field
• Recreate as a custom field
• Transform into a tag or option
• Archive for reference
• Exclude with an agreed reason

Do not pour every custom field into one free-text "legacy data" box. That technically preserves the content while making it impossible to filter, report or automate.

Preserve provenance and timestamps

A migrated note should not look as though it was written on the day of migration.

Where the source system makes the information available, preserve:

• Original creation date
• Last modified date
• Original author
• Source system
• Record owner
• Activity date
• File name
• File type
• Original external identifier

This matters for operational understanding and auditability.

For example:

"Candidate confirmed availability next Monday."

means something very different when written yesterday from when written seven years ago.

If original metadata cannot be imported into the destination's standard fields, include it visibly in the migrated record or maintain it in an associated audit field.

Deal with duplicates deliberately

A migration can either preserve existing duplication or make it worse.

Duplicate detection should consider more than exact email address.

Candidates may share or change:

• Email addresses
• Telephone numbers
• Names
• Surnames
• Locations
• Employers

Likewise, companies can appear under:

• Legal name
• Trading name
• Abbreviation
• Previous name
• Group company
• Subsidiary
• Misspelling

A safe deduplication process normally has three categories:

Definite duplicates

Records that can be merged automatically because the evidence is strong.

Possible duplicates

Records requiring human review.

Distinct records

Records that appear similar but should remain separate.

The merge rule should explain what happens to:

• Notes
• Documents
• Ownership
• Consent
• Opt-outs
• Candidate-job relationships
• Placements
• Dates
• Conflicting values

A deduplication process should never convert "opted out" into "marketable" merely because the other duplicate record did not contain the restriction.

Where values conflict, use the most protective or reliable rule and flag the record for review.

Documents require their own migration plan

Documents are frequently treated as a secondary task until the records have already been imported.

That is a mistake.

A document migration should identify:

• File location
• File name
• File type
• File size
• Parent record
• Document category
• Upload date
• Author or uploader
• Access restriction
• Retention status
• Whether the file can be opened
• Whether malware scanning is required
• Whether text extraction or search is expected

A successful document count is not enough.

The same file may have been duplicated several times, while an important document is missing.

Validation should include:

• Total files
• Total bytes
• Files by type
• Files by category
• Files without a parent record
• Zero-byte files
• Corrupt files
• Unsupported formats
• Duplicate checksums
• Random opening tests
• Checks of high-risk document categories

Particular care is needed for right-to-work documents, health information, equality data and other sensitive material. Special-category information requires an Article 6 lawful basis and an Article 9 condition, with additional safeguards potentially applying under the Data Protection Act 2018.

Migrate permissions as carefully as records

A migration can be factually accurate and still create a serious problem if the wrong people can see the information.

Map:

• Active users
• Former users
• Teams
• Branches
• Tenant boundaries
• Administrator permissions
• Record ownership
• Sensitive-field visibility
• Document access
• Export permissions
• Bulk-email permissions
• API access
• Integration accounts

Test the system from the perspective of different users.

Can:

• A consultant see only the expected records?
• A manager see the correct team?
• A former employee still log in?
• One tenant see another tenant's data?
• An ordinary user export the entire database?
• Sensitive compliance files be opened by everyone?
• Imported private notes become publicly visible?

Security controls should reflect the sensitivity and risk of the information. ICO guidance expects appropriately strong access controls, and the NCSC recommends protecting data in transit through encryption, network protection and authentication.

Protect the migration files

The migration itself often creates extra copies of the database:

• Full exports
• CSV files
• Document archives
• Transformation files
• Test imports
• Error reports
• Backups
• Developer copies

These temporary copies may be less protected than either CRM.

A secure migration process should define:

• Who can create an export
• Where it is stored
• How it is encrypted
• How it is transferred
• Who can download it
• Whether local copies are permitted
• Whether multi-factor authentication is required
• How access is logged
• When test and staging data will be deleted
• Who confirms deletion
• What happens if a file is sent to the wrong place

Do not transfer a full candidate database through ordinary email or leave an unencrypted export in a shared downloads folder.

The UK GDPR's security principle applies throughout the lifecycle, not only when the information is inside the live CRM. The ICO also requires data protection to be considered from the design stage and throughout a system's lifecycle, including decommissioning.

Where the migration is likely to create a high risk to people's rights and freedoms—because of its scale, sensitivity, new technology or other circumstances—the agency must carry out a Data Protection Impact Assessment. Even where one is not legally required, a proportionate risk assessment can still be useful.

Back up before changing anything

Before the first destructive transformation or final cutover, create a secure and recoverable backup of the source information.

The backup should include, as appropriate:

• Database export
• Documents
• Configuration
• User and permission data
• Mapping specifications
• Record counts
• Integration settings
• Audit information

A backup is useful only if:

• It is complete.
• It is protected.
• The organisation knows where it is.
• The necessary people can access it.
• It can be restored.
• Its retention and deletion are controlled.

The NCSC recommends maintaining appropriate backups because they provide a route to recovery when data is lost, damaged or made unavailable.

Do not assume that the old supplier's backup is available to the agency or can be restored on the required timetable. Ask.

Run at least one full test migration

The first full import should not be the live cutover.

A test migration allows the agency to discover:

• Broken mappings
• Missing relationships
• Invalid dates
• Duplicate inflation
• Unsupported documents
• Incorrect statuses
• Ownership problems
• Permission failures
• Performance problems
• Workflow differences

A representative sample can help during early development, but a final rehearsal should use the full realistic volume where possible.

Problems often appear only at scale:

• A field truncates long notes.
• A file limit excludes large CVs.
• A supposedly optional value fails on 30,000 records.
• Duplicate detection slows the import.
• A historic option contains unexpected characters.
• A relationship links correctly for recent records but not older ones.
• A date conversion reverses day and month.

The rehearsal should follow the same steps, tools and order intended for cutover.

Validate at several levels

A migration is not validated simply because the import completed without an error message.

Validation should occur at several levels.

1. Record counts

Compare source and destination counts for each object.

But do not demand equality without understanding the transformation.

Counts may differ legitimately because:

• Duplicates were merged.
• Test records were excluded.
• Several source objects became one destination object.
• Historic records were archived.
• Invalid records were quarantined.

Every difference should be explainable.

2. Field reconciliation

Check whether key values survived correctly:

• Names
• Emails
• Telephone numbers
• Dates
• Rates
• Statuses
• Owners
• Sources
• Consent
• Opt-outs
• Legal basis
• Retention dates
• Custom fields

Use automated comparisons where possible, followed by human review.

3. Relationship validation

Confirm that:

• Contacts belong to the right companies.
• Candidates remain linked to jobs.
• Submissions retain the correct stage.
• Interviews connect to the right candidate and vacancy.
• Placements connect to the correct client.
• Notes and documents belong to the right record.
• Tasks remain assigned to the correct user.

4. Document validation

Check counts, file sizes, categories and opening success.

5. Permission validation

Test real user roles and tenant separation.

6. Workflow validation

Ask users to complete realistic tasks:

• Find a known candidate.
• Open their latest CV.
• Review their historic submissions.
• Add them to a live vacancy.
• Send a message.
• Create an interview.
• Record feedback.
• Produce a placement.
• Access the correct compliance documents.
• Run a report.
• Find an opted-out contact and confirm that outreach is blocked.

7. Exception validation

Review what did not migrate cleanly.

A good migration produces an exception report showing:

• Rejected records
• Missing parents
• Unsupported values
• Duplicate conflicts
• Files that failed
• Truncated fields
• Records needing manual review

Zero reported errors may indicate that failures were silently ignored rather than that the source data was perfect.

Use more than random spot checks

Random checks are valuable, but they should be combined with risk-based testing.

Select examples from:

• Oldest records
• Newest records
• Largest notes
• Largest documents
• Candidates with several placements
• Companies with many contacts
• Records with unusual characters
• International addresses
• Duplicate candidates
• Former consultants
• Active temporary workers
• Restricted records
• Opted-out contacts
• Custom-field-heavy records
• Records from acquired businesses
• Historic data imported into the old CRM

The records most likely to break are often the ones that differ from the normal pattern.

Agree who signs off the migration

Different people should sign off different aspects.

Data sign-off

Counts, mappings, transformations and exceptions are understood.

Operational sign-off

Consultants can complete the required workflows.

Compliance sign-off

Retention, restrictions, lawful-basis records, documents and access controls have been considered.

Technical sign-off

Integrations, authentication, performance and recovery are ready.

Commercial sign-off

Fees, cutover support, legacy access and remediation responsibilities are clear.

The migration should not go live because the calendar says it is time. It should go live because the agreed acceptance criteria have been met—or because the remaining exceptions have been consciously accepted.

Plan the final cutover

Between the test migration and the live switch, users will continue adding and editing information in the old CRM.

That creates a delta: the information changed after the earlier export.

The cutover plan should state:

• When the final source export begins
• Whether the old CRM becomes read-only
• Which users can still make changes
• How final changes are captured
• Whether the migration is full or incremental
• When integrations stop
• When integrations start in the new system
• When users receive access
• When the old system becomes unavailable
• Who confirms success
• What triggers rollback

A typical sequence might be:

1. Complete final user acceptance testing.
2. Notify users of the cutover timetable.
3. Pause bulk campaigns and non-essential integrations.
4. Take a final secure backup.
5. Make the old CRM read-only.
6. Export the final delta.
7. Import and validate the delta.
8. Reconcile high-risk counts and relationships.
9. Enable the new integrations.
10. Give users access.
11. Run agreed day-one tests.
12. Confirm or reverse the cutover.

Do not allow users to update both systems after cutover unless there is a defined synchronisation process. Otherwise neither system remains authoritative.

Aim for controlled disruption, not a fictional promise of zero downtime

Some migrations can be completed with very little interruption. Others require a period in which the old system is read-only or certain actions are paused.

The honest aim is controlled and understood disruption.

Schedule the final cutover around:

• Payroll
• Timesheet deadlines
• Invoice runs
• Major client campaigns
• Month-end reporting
• Temporary-worker starts
• Compliance deadlines
• Staff availability
• Vendor support coverage

A quiet weekend may appear attractive, but it is not useful if neither vendor has the right technical staff available when something fails.

Make sure users know:

• When to stop entering information
• What they can still access
• Where urgent information should be recorded
• When the new system becomes authoritative
• How to report a problem
• Who decides whether to roll back

Have a rollback plan

A rollback plan is not an admission that the migration is likely to fail.

It is a control for a project affecting critical operational information.

Define rollback triggers such as:

• Material numbers of missing records
• Broken candidate-job relationships
• Unavailable documents
• Cross-tenant data exposure
• Incorrect permissions
• Inability to process active placements
• Critical integrations failing
• Data corruption
• Unacceptable performance

The plan should answer:

• Can users safely return to the old system?
• Which changes made in the new CRM would need to be preserved?
• How long is rollback practical?
• Who has authority to trigger it?
• How will staff be notified?
• What happens to emails or updates created during the attempted cutover?

Without those answers, "we can always go back" may be false reassurance.

Do not switch off the old system immediately

The legacy CRM may need to remain available temporarily for:

• Validation
• Historical comparison
• Missing information
• Audit
• Data-rights requests
• Commercial disputes
• Troubleshooting
• Records deliberately not moved into the live CRM

That does not mean leaving it fully operational indefinitely.

A controlled legacy period might involve:

• Read-only access
• Access limited to a small number of authorised users
• Multi-factor authentication
• No new data entry
• No active integrations
• A defined end date
• Recorded reasons for each access
• A plan for remaining data
• A documented deletion or archive decision

Running two editable CRMs indefinitely creates conflicting versions of the truth and doubles the security and compliance burden.

Decommission the legacy environment properly

Once the agency is satisfied that the new CRM is complete and stable, it should close the old environment deliberately.

The decommissioning checklist should include:

• Confirm final acceptance.
• Resolve or record migration exceptions.
• Export any agreed archive.
• Cancel integrations and API credentials.
• Disable user accounts.
• Revoke third-party access.
• Confirm contractual termination.
• Instruct the provider to return or delete personal data.
• Obtain confirmation of deletion where appropriate.
• Understand backup-deletion timescales.
• Delete temporary migration files.
• Review local copies held by staff or suppliers.
• Update records of processing.
• Update privacy information where necessary.
• Record the final decommissioning decision.

Article 28 processor contracts must allow the controller to choose the return or deletion of personal data at the end of the service, with remaining copies deleted unless UK law requires storage.

Ask specifically about backups. A supplier may remove live data immediately while retaining encrypted backups for a defined recovery period. That may be reasonable, but it should be understood and documented.

Train users on process differences, not only buttons

A technically successful migration can still fail because the team continues trying to operate the old CRM inside the new one.

Training should explain:

• What has changed
• Why it has changed
• Which system fields replaced old ones
• How duplicates are handled
• How ownership works
• Where notes and documents now live
• Which actions are automated
• Which reports have changed
• How restrictions and opt-outs appear
• How to report incorrect migrated data

Do not attempt to teach every feature before launch.

Prioritise the workflows users need immediately:

• Search
• Candidate records
• Client records
• Jobs
• Submissions
• Interviews
• Placements
• Communications
• Tasks
• Documents

Give the team a clear issue-reporting route and capture:

• Source record
• Destination record
• What was expected
• What happened
• Severity
• Screenshot or example
• Whether other records may be affected

A migration issue found in one record should trigger a search for the same pattern elsewhere.

Monitor the first weeks after launch

Migration does not finish when users log in.

The early-support period should monitor:

• Failed logins
• Missing permissions
• Search complaints
• Duplicate creation
• Document failures
• Email and calendar synchronisation
• Job-board publishing
• Reporting differences
• Incorrect statuses
• Unassigned records
• Failed automations
• Opt-out enforcement
• User workarounds
• Outstanding exceptions

Hold short operational reviews during the first week.

Classify each issue as:

• Migration error
• Configuration problem
• Training need
• Product defect
• Source-data problem
• Expected process change

That prevents every unfamiliar feature being treated as data loss—and prevents genuine loss being dismissed as user confusion.

What commonly goes wrong

Only the obvious tables are migrated

Candidates, contacts and jobs arrive, but submissions, notes, activities and documents do not.

Relationships are reconstructed from names

Names are not reliable identifiers. Two companies may have the same name, and one company may have several spellings.

Historic stages are forced into current workflows

A placement from 2019 suddenly appears as an active candidate in a current pipeline.

Notes lose dates or authors

The history survives as text but becomes misleading.

Opt-outs are not migrated

People who previously objected are eligible for campaigns again.

Custom fields become free text

The information is technically present but unusable for filtering and reporting.

Former users are ignored

Their records become unowned or are incorrectly reassigned without preserving authorship.

Documents move without categories

Thousands of files appear under generic attachments with no indication of what they are.

The test migration uses only clean data

The real migration then fails on old, unusual or imported records.

Users continue updating both systems

Two inconsistent versions of the client and candidate database emerge.

The legacy system is cancelled too soon

The agency discovers missing data after its access has ended.

The old system is never decommissioned

Personal data remains in a forgotten platform with active accounts and unclear retention.

Questions to ask a new CRM provider

Scope

• Which record types are included?
• Are relationships included?
• Are notes, emails and activity history included?
• Are documents included?
• Are custom fields and option values included?
• Are consent, lawful-basis and suppression records included?
• Which information cannot be migrated?

Extraction

• Do you work from an API, database export or CSV?
• Who obtains the data from the existing supplier?
• Can you migrate attachments at full volume?
• Do you preserve source identifiers?
• How are deleted or archived records represented?

Mapping

• Will we receive a field-mapping document?
• Who decides how unsupported values are transformed?
• How are dates, currencies and option sets handled?
• How are former users mapped?
• How are duplicate records handled?
• Can migration rules be tested before the final import?

Validation

• How many test migrations are included?
• What reconciliation reports will you provide?
• How are failed records reported?
• How are relationship failures detected?
• Who corrects migration errors?
• What acceptance period is included?

Security

• How are exports encrypted?
• Where are staging files stored?
• Who can access them?
• Are transfers logged?
• When are temporary copies deleted?
• Which sub-processors are involved?
• Is data accessed outside the UK?
• What contractual safeguards apply?

Cutover

• Will the old system need to become read-only?
• How is the final delta migrated?
• What downtime should we plan for?
• Who is available during cutover?
• What is the rollback process?
• When is the new system considered authoritative?

Legacy and exit

• How long should we retain read-only legacy access?
• Who handles outstanding data-rights requests?
• When should the old provider delete its copies?
• Can the new CRM export our full data later?
• Does that export include relationships and documents?
• Are there exit or extraction charges?

A vendor's answer to the final question matters before you sign.

The next migration should not be made difficult by the system you are moving into now.

Where ATSpro fits

ATSpro treats supported migration as an onboarding project rather than leaving the agency with a blank spreadsheet template and an import button.

Its migration process can include:

• Source-data review
• Field mapping
• Import of candidates, companies, contacts and jobs
• Reconstruction of supported relationships
• Transfer of notes and documents where available from the source
• Test imports
• Validation and exception review
• Final cutover support

Dedicated migration routes are available for systems including Influence, Recruit CRM and JobAdder.

The exact scope still depends on what the existing supplier makes available.

No new CRM can migrate information that:

• Was never recorded
• Has already been deleted
• Is inaccessible in the source
• Is omitted from the export
• Is corrupt
• Cannot legally or securely be transferred
• Has no usable relationship identifier

The migration scope should therefore be agreed after reviewing the source data, not promised from a logo alone.

ATSpro provides free supported migration as part of onboarding, but "free" should not mean unexamined. The same requirements still apply: documented mapping, test imports, reconciliation, user acceptance and a controlled final cutover.

A practical migration checklist

Before signing

• Confirm the full migration scope.
• Understand export access and charges.
• Review the processor contract.
• Review hosting, sub-processors and international transfers.
• Confirm legacy access and deletion terms.
• Agree acceptance and remediation responsibilities.

Discovery

• Appoint the project owner.
• Inventory records, relationships, documents and integrations.
• Define success criteria.
• Identify high-risk and sensitive data.
• Identify ongoing disputes and rights requests.
• Decide whether a DPIA is required.

Design

• Create the data dictionary.
• Define inclusion and exclusion rules.
• Map users and permissions.
• Define duplicate rules.
• Define document categories.
• Define validation measures.
• Agree rollback triggers.

Test

• Run representative early samples.
• Run a full rehearsal.
• Reconcile counts.
• Validate relationships.
• Open documents.
• Test permissions.
• Test normal workflows.
• Review the exception report.
• Obtain user acceptance.

Cutover

• Notify users.
• Pause relevant integrations.
• Back up the source.
• Make the old system read-only.
• Export and import the final delta.
• Reconcile high-risk data.
• Test integrations.
• Confirm or roll back.
• Declare the new authoritative system.

After launch

• Monitor errors and user behaviour.
• Resolve migration exceptions.
• Retain controlled legacy access temporarily.
• Review privacy and processing records.
• Delete temporary copies.
• Decommission the legacy CRM.
• Confirm deletion or return by the old supplier.

The takeaway

A recruitment CRM migration is not a gamble, but it is also not a one-click import.

A reliable migration requires:

• A clear definition of success
• An inventory of what the agency holds
• Deliberate retention decisions
• Careful field and relationship mapping
• Secure handling of export files
• Full rehearsal
• Multi-level validation
• A final delta process
• A rollback plan
• User testing
• Controlled legacy access
• Proper decommissioning

The most valuable information is often not the candidate or company record itself.

It is the network of relationships around it: who spoke to whom, about which vacancy, what was agreed, what happened next and which restrictions still apply.

Preserve that meaning and the new CRM begins with the agency's accumulated knowledge intact.

Move only the obvious rows and the database may arrive looking full while much of its real value has been left behind.

**Sources: Information Commissioner's Office, *A guide to the data-protection principles*; Information Commissioner's Office, *Data minimisation*; Information Commissioner's Office, *Accuracy*; Information Commissioner's Office, *Storage limitation*; Information Commissioner's Office, *Contracts between controllers and processors*; Information Commissioner's Office, *International transfers*; Information Commissioner's Office, *Data Protection Impact Assessments*; Information Commissioner's Office, *Respect people's marketing preferences*; Information Commissioner's Office, *Right of access*; National Cyber Security Centre, *Data in transit protection*; National Cyber Security Centre, *Backing up your data*; user per month.*.**