The Definitive Guide to Migrating to Recruit CRM

Recruit CRM is operated by Workforce Cloud Tech, Inc. and headquartered in Norwood, New Jersey ¹. The platform packages applicant tracking, CRM, sequencing and a Chrome sourcing extension into a single subscription aimed at recruitment agencies and executive-search firms, and is SOC 2, GDPR and AICPA-aligned ³.

The typical Recruit CRM customer is an agency of two to a hundred recruiters running perm, contingent or executive search desks. Compared with Bullhorn, Recruit CRM positions on a flatter onboarding curve, a unified Candidate/Contact/Company/Job/Deal model and a Chrome Extension that turns LinkedIn profiles into candidate records in one click ⁴. Compared with Crelate or JobAdder, it positions on AI tooling — an AI Resume Parser, AI Sourcing, and the Recruit CRM AI Voice agent for outbound calls ⁴.

The shapes of migration that actually land on Recruit CRM tend to fall into four patterns. First, homegrown replacements: an agency moving off a spreadsheet, a shared Google Drive of resumes, or a bespoke in-house tool. Second, enterprise-ATS downshifts, where the source is Bullhorn, Vincere or PCRecruiter and the agency wants a lighter platform with the same agency workflow but less administrative overhead ⁹.

Third, vertical-ATS swaps — Crelate, JobAdder, Loxo, Tracker — where object parity is reasonable but custom fields and pipeline stage names diverge. Fourth, generalist-CRM exits, where Zoho Recruit, HubSpot or a Salesforce build is being replaced by a recruitment-native tool. A Bullhorn-to-Recruit-CRM migration usually has clean entity parity but a much tighter custom-field budget; a Zoho-Recruit migration has cleaner picklist labels but loses Blueprint state machines on cutover ⁹.

What makes migrating *to* Recruit CRM easier than the category average is the built-in bulk importer — accessible from the candidates, contacts, companies and jobs pages, accepting XLS and CSV, and supporting an *Override Data* toggle and a *Merge Duplicates* matching parameter ⁷. Recruit CRM's own data-migration team also runs free imports for paid plans on basic Excel and CSV files ³⁶.

What makes it harder than the average is the strict bulk-load throughput budget that paces every migration script. The base subscription tier also caps custom fields at 15 and total candidate records at 10,000 — small migrations sail through but mid-size agencies often need to upgrade just to land their data.

Email and SMS Sequences, automation triggers, the Recruit CRM AI Agent rules and Kanban board configurations do not import — they are rebuilt from documentation. Teams that scope for that work up front finish on time; teams that assume parity do not.

Teams that scope for the rebuild work up front finish on time; teams that assume parity do not.

Recruit CRM's ATS is built around five core modules — Candidates, Contacts, Companies, Jobs and Deals — plus engagement modules (Tasks, Meetings, Notes, Call Logs), collection modules (Hotlists, Lists), and operational modules (Placements, Timesheets, Invoices, Files).

Before you can map a field on the source side, you need to know which destination module the row belongs on, which fields it requires, and which value will serve as its upsert key. The table below summarises the modules you will touch.

Recruit CRM does not expose a customer-settable external ID property in the same way Bullhorn does. Instead, the bulk importer matches on one of three unique parameters — email, phone or name — chosen on the *Merge Duplicates* dropdown at import time ⁷. The canonical key is the slug Recruit CRM assigns each record on creation; capture it in your source for re-runs.

Plan an external-ID strategy on day one: create a custom single-line text field named *Legacy ID* on each module, stamp the source primary key into every row before export, and use it both as the import-time match column (where supported) and as a stable reconciliation key in every post-cutover audit query.

Custom field types determine validation and storage; the catalogue below covers what you can model and the limits that apply.

Relationships in Recruit CRM are modelled as to-one and to-many associations. A Job belongs to one Company and one primary Contact; a Candidate can be attached to many Jobs through assignments and Hotlists.

There is no native cascade-delete: deleting a Job does not delete its assigned Candidates, Hotlists, Notes or Tasks — a behaviour to reproduce via scripted cleanup or workflow automation if your source relied on it.

The single best predictor of a clean Recruit CRM migration is how much work you do on the source side before the first import button is pressed. Recruit CRM's own data-migration guidance is explicit that stale candidate records, duplicate emails and outdated tags are the main reason post-migration search results drift from what recruiters expect ⁹.

The single best predictor of a clean migration is how much work you do before the first import button is pressed.

Treat the source export as raw material that needs shaping to Recruit CRM's expected formats — email lowercased, phone in a single canonical format, picklist values rewritten to destination dropdown values, dates in the account timezone, and owners resolved to Recruit CRM user emails.

Source-side prep

• Audit and dedup the source candidate database before export — Recruit CRM's bulk importer offers email / phone / name dedup, but the more cleaning you do up front, the fewer surprise merges you discover post-load ⁷.
• Stamp a Legacy ID on every source record — Candidate, Contact, Company, Job, Deal and Placement. Use the source primary key or a UUID and load it into a custom single-line text field. Every re-run and reconciliation query will lean on this.
• Normalise picklist values for Candidate Status, Job Hiring Stage, Job Status and every custom dropdown. Recruit CRM matches dropdown options exactly; rows targeting an undefined option arrive with an empty field, not an error.
• Decide resume-file scope. Each candidate has zero, one or many resumes. Decide latest-only, all-versions, or none — the resume leg is its own pipeline that runs *after* candidate rows land, and the AI Resume Parser will rewrite candidate fields if you let it ¹⁹.
• Confirm the account timezone and base currency before loading historical dates and salary fields. Recruit CRM stores dates per account timezone; mismatched offsets surface as one-day shifts on candidate timelines ¹³.

Destination-side prep

• Choose the right subscription tier for the migration. The base plan caps custom fields at 15 per module and total candidate records at 10,000 — mid-size agencies usually need Pro or Business before they can load their data.
• Provision Users first under Admin Settings → Account Management → Users, ideally via SSO, and assign roles before importing — owner assignment falls back to the importing user if a referenced owner email does not exist ¹⁶.
• Pre-create every custom field under Admin → Custom Fields on the right module with the right type. Field types are not easily changed after rows arrive; get this right before the first import.
• Build Hiring Pipelines and Hiring Stages for each job type before importing Jobs. Multiple pipelines are supported and each job is assigned to one pipeline; Hiring Stage internal labels must exist before candidate assignments can target them.

People prep

Cutover only works if humans cooperate. Lock down a source-system freeze window — typically 24 to 72 hours — and train recruiters on candidate search, Hotlist creation, Hiring Stage transitions, the Kanban board, and the Chrome Extension before go-live. A small-agency migration handled by the in-house team typically runs one to two weeks; a mid-size firm with resume backfill, Custom Field rebuilds and Sequence reconstruction runs two to four weeks of elapsed time ⁹.

Recruit CRM exposes two main load paths and the right one depends on dataset size and module mix. The Bulk Importer covers most one-shot Candidate, Contact, Company and Job loads. Recruit CRM's own data-migration team runs managed imports for paid plans and is usually the cheapest path for small agencies ⁶.

Bulk Importer (UI)

The native Bulk Importer is reached from any module index page — Candidates, Contacts, Companies, Jobs — via the *Import* button ⁷. It accepts XLS and CSV, walks through a column-mapping step, and exposes two import-time toggles that change the load semantics: Merge Duplicates (with a one-of-three match parameter — email, phone or name) and Override Data (whether incoming values overwrite existing values on a matched row).

With *Merge Duplicates* off, every row is a fresh insert and the importer will happily create candidates with the same email. With *Override Data* off, matched rows only update empty fields — non-empty existing values stay untouched ⁷. The right combination for most migrations is Merge Duplicates on, Override Data on, with email as the match parameter, but verify on a 50-row pilot before scaling.

Managed migration (Recruit CRM team)

Recruit CRM offers a free data-migration service to paid customers on basic Excel and CSV imports of Candidates and Companies ⁶³. The service runs against a three-step process — Data Discovery (export from the old ATS), Importing (the Recruit CRM engineer loads into your account), and Deployment & Reviewing (quality check) — and is bundled with the implementation contract for Pro and above tiers ³.

For more complex migrations — multiple modules, large resume estates, picklist remapping, Hotlist reconstruction — the in-house service caps at what their team can do in CSV without writing custom scripts, and the residual work goes to either a third-party migration vendor or an in-house engineering effort.

Mapping is where every agency-ATS migration earns its scars. The schema decisions in your mapping spreadsheet determine whether recruiters find candidates on day two, whether Hotlists rebuild correctly by day five, and whether placement reports trust the data by day thirty.

Work module by module in strict import order: Companies first (so Contacts and Jobs can associate), then Contacts, then Candidates, then Jobs, then Hotlists and assignments, then Notes / Tasks / Meetings / Call Logs, then resume files, and Deals / Placements last.

Candidates and resume files

The Candidate module is the centre of gravity for an ATS migration. Each candidate has a profile (name, email, phone, address, status, owner), one or more resumes attached as files, a set of skills and tags, optional EEOC fields (typically as custom dropdowns), and timeline activity from Notes, Tasks, Meetings and Call Logs.

Recruit CRM's AI Resume Parser can extract candidate fields from an uploaded resume — name, email, phone, current employer, skills ¹⁹. This is brilliant for net-new sourcing but dangerous on migration: a resume uploaded against a candidate you just loaded can overwrite your carefully-mapped fields. Either disable parser overwrite via Account Settings before resume backfill, or load resumes as plain document attachments rather than triggering the parse flow ¹⁹.

Companies and Contacts

Jobs, Hiring Pipelines and Hiring Stages — the ATS deep dive

The job-requisition pipeline runs Job → Candidate Assignment → Hiring Stage transitions → Placement, with each candidate-on-a-job tracked as an assignment that moves through Hiring Stages on the Job's Hiring Pipeline. A Job is the open requisition (e.g. *Senior RN, Boston*), an assignment is a candidate's application against it (often rendered as a card on the Kanban board), and a Placement is the confirmed hire.

Recreate every Hiring Pipeline and every Hiring Stage (Sourced, Screened, Submitted to Client, Interview Scheduled, Offer Extended, Placed, Rejected) in Admin → Settings before loading Jobs. Multiple pipelines are supported — agencies typically run separate pipelines for Perm, Contract and Executive Search. Jobs that target an undefined Hiring Stage on the named pipeline arrive at the pipeline's default stage with no error.

Hiring Stage transition history is one of the most-asked-about pieces of an ATS migration and one of the least-supported on import. Recruit CRM has no stage-history table — the audit trail is built by repeated updates that each shift the assignment's current Hiring Stage. To preserve the timeline, capture each transition as (assignment_id, hiring_stage, timestamp, user) and replay updates in date order, accepting that the *modifying user* will be the migration user.

Alternatively, store the legacy stage history verbatim in a Candidate-level paragraph custom field named *Legacy Stage History* so it stays searchable, and let live history accrue forward from cutover. Most agencies pick the second path because it costs zero throughput and zero attribution loss.

Hotlists — candidate shortlists per job or pitch

Hotlists are Recruit CRM's lightweight candidate-collection construct — a recruiter builds a Hotlist of, say, *Boston RN shortlist – Memorial Hospital*, adds five candidates, and shares it with the hiring manager. Hotlists do not behave like Jobs or Assignments — they are tags-of-tags, not pipeline records ⁴. On migration, source equivalents (Crelate Lists, Bullhorn Tearsheets, JobAdder Folders) map cleanly to Hotlists.

Build the Hotlist load as a second pass after Candidates have slugs assigned. Create the Hotlist, then attach each candidate individually. There is no bulk-attach in a single operation; every member is a separate write, which makes Hotlists a non-trivial fraction of total throughput on agencies with hundreds of named lists.

Candidate sources, EEOC and consent

Candidate source tracking lives on the Source dropdown plus, often, a custom *Legacy Source* text field that preserves the original verbatim value. Source-effectiveness reporting in Recruit CRM keys off the standard Source field — populate it during candidate load rather than letting it default to blank.

EEOC data (ethnicity, gender, veteran status, disability) is typically modelled as a set of custom dropdown fields on Candidate. Treat them as sensitive: confirm the source export is permitted under your retention policy and that the destination's privacy posture matches. Recruit CRM is GDPR-aligned and stores data in AWS-managed data centres with AES-256-bit encryption ³.

Notes, Tasks, Meetings, Call Logs — historical activity

Recruit CRM supports importing Notes, Tasks, Meetings and Call Logs against existing Candidates, Contacts, Companies and Jobs. Each Note carries a body, owner, timestamp, and one or more parent associations. The bulk importer does not cover these — they are a follow-up leg via the platform's bulk-load workflows.

Rich-text formatting on Notes is partially supported via the UI editor but does not always survive a programmatic write — paste-from-Word, embedded images and complex table markup get flattened. Convert source rich-text bodies to plain text or a Markdown-style structure during transform, and archive the original HTML in a Candidate-level paragraph custom field if downstream search depends on the original wording.

Custom-field mapping strategy

Resist the urge to map every source custom field one-to-one. The base plan limits you to 15 custom fields per module; even on Business and Enterprise tiers, excess fields weaken search relevance, slow the Kanban board and make the AI Resume Parser less effective. Migrate only the custom fields used by an active recruiter workflow or report in the last 12 months.

For picklist fields whose source values do not match the destination, either: (1) extend the destination dropdown in Admin → Custom Fields, (2) collapse adjacent values during transform, or (3) introduce a parallel single-line text field holding the legacy value verbatim. Calculated / formula fields do not import — Recruit CRM has no formula field type, so source formulas must be pre-computed before export or replicated via external automation.

Audit trail, ownership and original timestamps

Recruit CRM maintains an account-level Audit Log accessible to admins for monitoring user activity ¹⁷. The modifying user on every imported row is recorded as the migration user, which means historical attribution to the original recruiter is not preserved unless you stamp a custom *Legacy Owner* text field with the source user's name.

Created Date and Modified Date on every record are system-managed and stamped to import day — you cannot override them through the bulk importer. Create a *Legacy Created Date* datetime custom field on each module and populate it from the source export. Owner assignment during import works only if the user email exists in Recruit CRM at load time; unresolved owners default to the migration user, silently breaking per-recruiter reporting until cleaned up ¹⁶.

Validation is the bridge between the import finishing and recruiters being allowed in. A three-stage validation works best: a 10 percent pilot load with recruiter spot-checks, the full load with real-time row-count monitoring, and a 30-day audit driven by Recruit CRM's Reports module ⁹. The most reliable signal is recruiters verifying their own desks — they know what right looks like better than any reconciliation script.

Build a reconciliation queries spreadsheet that compares source and destination on each of these counts. Anything outside a 0.5 percent variance gets investigated before users get login access.

• Total Candidates loaded vs. source — minus deliberately excluded rows (stale, opt-out, duplicate emails). Confirm none of the excluded rows landed by accident.
• Total Companies and Contacts loaded vs. source — checking that name-based collapse via the Merge Duplicates toggle did not over-merge separate clients.
• Total Jobs per Hiring Stage vs. source, plus distinct Hiring Pipeline counts — a non-trivial variance signals a stage-mapping error or a pipeline-routing mistake.
• Total Candidate Assignments per Job vs. source, and assignment counts per Hiring Stage — confirms the candidate pipeline shape per requisition matches.
• Hotlist membership — count candidates per Hotlist and compare against the source list. Hotlists are easy to miss because they sit outside the Job → Assignment chain.
• Notes / Tasks / Meetings / Call Logs per parent record with timestamp round-tripped — date-bucket the comparison to confirm Legacy Created Date conversion worked.
• Owner distribution per module — group by owner email and confirm no record landed owned by the migration user that should not have been ¹⁶.
• Resume-file counts per Candidate — count attached files per candidate and compare against the source. Missing files surface on day two as recruiters look up profiles.
• Legacy ID integrity — count distinct Legacy IDs per module; any nulls or duplicates indicate the upsert key was not consistently set.

On top of reconciliation, run a manual spot-check: pick 30 random Candidates across statuses and verify each field against the source UI. Pick five high-value Jobs and trace the full association graph — Company, Contact, Assignments, Hiring Stage, Hotlists, Notes, Files. If discrepancies show up in three or more of the 30, halt the load, fix the root cause, and re-import the affected rows by Legacy ID upsert.

Recruit CRM does not ship a native bulk-undo. The recovery path: every imported row carries a Custom Text field stamped *Import Batch ID*, and if catastrophe strikes, a bulk-delete in each module filtered by that batch ID rolls the import back ¹⁴. Recruit CRM Support can run a full account purge for catastrophic scenarios, but the operation is one-way and irreversible; it is queued like any support request.

Before the load starts, take a full export via Admin Settings → Account → Full Export — this captures CSVs of all candidates, contacts, jobs, companies and deals plus attached files for each, and can be run once every 90 days ¹⁴. The lighter Data Export (CSV only, once per day) is fine for daily backups, but the Full Export with files is the one to take immediately before any non-trivial import.

Cutover sequencing: (1) source ATS goes read-only and the desk is notified; (2) a final delta export captures everything changed during the test-import window; (3) delta is loaded via Bulk Importer against Legacy ID; (4) reconciliation runs; (5) recruiters get login access and a 48-hour hyper-care window; (6) source decommission is scheduled 30 to 90 days out, never same-day.

Recruit CRM ships a free in-house data-migration service to paid customers — Pro, Business and Enterprise tiers — that covers basic Excel and CSV imports of Candidates, Contacts, Companies and Jobs end-to-end, with a three-step process of Data Discovery, Importing and Deployment & Reviewing ³⁶. For most small agencies moving off a spreadsheet or a homegrown database, this is the cheapest and lowest-risk path.

Where the in-house service runs out of road is multi-module migrations from another ATS (Bullhorn, Crelate, JobAdder, Vincere, PCRecruiter), resume-file backfill at scale, Hotlist reconstruction, Hiring Stage history replay and Sequence rebuilds. Those workloads exceed what a CSV-driven import can handle and either move to a specialist migration vendor or to an in-house engineering effort.

On the third-party side, a small cohort of recruitment-tech consultancies offer Recruit CRM-bound migration packages with extraction-from-source plus programmatic loading. Pricing typically tracks record volume and resume-file depth, with a setup fee plus per-module line items for Candidates, Companies, Jobs, Hotlists and resumes.

ETL and iPaaS tools — Fivetran, Airbyte, Workato, Integrate.io — do not yet ship native Recruit CRM connectors as broadly as they do for Salesforce or HubSpot. Plecto and a small number of analytics integrations exist for read-side reporting, but write-side migration is almost always custom work or a Workato recipe written for the project.

Managed-migration cost ranges vary widely. A clean spreadsheet-to-Recruit-CRM load of under 10,000 Candidates with no resume backfill often lands free on the in-house service, or in the $1,500–$6,000 range with a specialist vendor. A Bullhorn-to-Recruit-CRM or Crelate-to-Recruit-CRM project with Hiring Stage history, Hotlist rebuild, resume backfill and Sequence reconstruction typically runs $8,000–$40,000, driven by record count, custom-field complexity and resume-file volume.

For teams that want to outsource the migration end-to-end, FlitStack specialises in Recruit CRM migrations and handles the field mapping, Legacy ID design, resume-file pipeline, Hotlist reconstruction, Hiring Stage history rebuild and validation work described in Sections 5 and 7. Pricing is fixed-fee, based on record count and source platform, with separate line items for resume-file depth and Hotlist volume so scope is transparent before signature.

This is one of several legitimate paths — the right choice depends on whether you want the free in-house Recruit CRM migration team, a Workato- or Fivetran-driven build, or a specialist migration vendor. Explore FlitStack →