HRMS migration
Field-level mapping, validation, and rollback between Tracker and Recruit CRM & ATS. We move data and schema; workflows are rebuilt natively in Recruit CRM & ATS.
Tracker
Source
Recruit CRM & ATS
Destination
Compatibility
7 of 10
objects map 1:1 between Tracker and Recruit CRM & ATS.
Complexity
BStandard
Timeline
3-5 weeks
Overview
TrackerRMS has no documented public REST API, making CSV export the primary extraction path for most customers. Recruit CRM enforces per-tier candidate and contact limits (Pro: 10,000 per user, Business: 20,000 per user, Enterprise: unlimited), which means migrating from Tracker's unlimited-record model requires a deduplication pass against name, email, and phone before import to avoid triggering a cost spike on the destination. We resolve the Tracker-to-Recruit CRM schema difference on Placements — Tracker stores placements as a first-class billable object, while Recruit CRM represents placement outcomes as candidate status changes — by preserving placement date, compensation, bill rate, and client reference in custom fields on the candidate record. Automation Playbook sequences, email drips, and recruiter alerts do not export from Tracker and require rebuild in Recruit CRM's workflow automation; we deliver a written inventory of every active automation for the customer's admin to reference during rebuild.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Tracker object lands in Recruit CRM & ATS, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Tracker
Candidate
Recruit CRM & ATS
Candidate
1:1Tracker Candidates map 1:1 to Recruit CRM Candidates. We extract name, contact info, skills, availability, source, status, and current stage from the CSV export and map each to the corresponding Recruit CRM field. Resume files are extracted as attachments and re-associated to the candidate profile post-import. Tracker's unlimited-candidate model means we run email deduplication against name and email before import to avoid hitting Recruit CRM's per-tier data limits on Pro (10,000 per user) and Business (20,000 per user). Active candidates, hot candidates, and recent placements take priority during scoping; stale records older than 24 months are flagged for customer decision before import.
Tracker
Company
Recruit CRM & ATS
Company
1:1Tracker Companies (client organizations and staffing firm profiles) map 1:1 to Recruit CRM Companies. We map company name, website, industry, address, and size to the corresponding Recruit CRM fields. The company domain is used as a dedupe key during import. Tracker Companies function as parent records for both Candidates and Contacts, and we preserve those associations by resolving the Tracker Company ID on candidate records and mapping it to the Recruit CRM Company ID at import time.
Tracker
Job
Recruit CRM & ATS
Job
1:1Tracker Jobs map 1:1 to Recruit CRM Jobs. We map job title, location, requirements, description, status, assigned recruiter, and pipeline stage from Tracker CSV exports to the corresponding Recruit CRM Job fields. Pipeline stages are reconfigured in Recruit CRM's pipeline settings to match Tracker's stage names and order; stage-level automation rules (trigger-based field updates on stage change) do not migrate and are flagged in the automation inventory delivered to the customer. Open jobs and jobs with recent activity (placed within 6 months) are prioritized in migration scope.
Tracker
Contact
Recruit CRM & ATS
Contact (within Company or standalone)
1:manyTracker distinguishes between client-side Contacts (hiring managers, stakeholders, client-side relationships) and Candidate-side contact records. We map Tracker Contacts to Recruit CRM Contact records, preserving their association with the parent Recruit CRM Company (resolved via company name and domain matching). Contact roles (hiring manager, decision-maker, approver) are preserved in a custom field on the Contact record if no native role field exists in the target tier. Contact type (client contact vs candidate contact) is used to route records to the correct Recruit CRM context during import.
Tracker
Placement
Recruit CRM & ATS
Candidate (status and custom fields)
lossyTracker Placements record placed candidates with start date, compensation, bill rate, and client reference as a first-class object with links to both the Candidate and the Job. Recruit CRM represents placement outcomes as candidate status changes rather than a standalone placement object. We preserve the full placement record — start date, end date, compensation, bill rate, client name, and job reference — in custom fields on the candidate record in Recruit CRM, ensuring billing relationship history is not lost during migration. The candidate status in Recruit CRM is set to Placed to reflect the outcome. If the customer's workflow relies on a separate placement report, we configure a candidate-level custom view that surfaces the placement custom fields for reporting.
Tracker
Activity (calls, emails, notes, tasks)
Recruit CRM & ATS
Activity log entries on Candidate and Job
1:1Tracker Activities (logged calls, emails, notes, and task completions linked to candidates and jobs) map to Recruit CRM activity log entries attached to the candidate profile and job record. We extract the activity type, timestamp, body, and associated recruiter from Tracker CSV exports and insert them as notes or activity records in Recruit CRM tied to the resolved Candidate and Job IDs. One known limitation: Recruit CRM's Google Calendar sync does not propagate deleted calendar events back to the platform, which may affect teams relying on calendar deletion reconciliation; we flag this as a post-migration verification step.
Tracker
Pipeline Stage
Recruit CRM & ATS
Pipeline status values
lossyTracker Pipeline Stages (customizable stage names and statuses defining candidate progression through a job) map to Recruit CRM's pipeline configuration. We enumerate Tracker's stage names, probabilities, and order during discovery, then configure matching pipeline status values in Recruit CRM's job pipeline settings. Stage-level automation rules (status-update triggers, recruiter alerts on stage entry) are not portable and are listed in the automation inventory delivered to the customer for rebuild in Recruit CRM's workflow automation.
Tracker
Automation Sequence
Recruit CRM & ATS
Workflow automation (rebuild required)
1:1Tracker Automation Playbook sequences — email drips, SMS triggers, recruiter alerts, status-update automations — are stored as platform-native workflow logic that does not export. We do not migrate automation as code. We enumerate every active Tracker automation during discovery, document its trigger conditions, actions, and sequence steps, and deliver a written inventory with recommended Recruit CRM workflow equivalents for the customer admin to rebuild post-migration. This inventory is a standard deliverable in the migration scope.
Tracker
Document / Attachment
Recruit CRM & ATS
Candidate document attachment
1:1Resume files, cover letters, and uploaded attachments stored against Tracker candidate records are extracted from the CSV export package and re-associated to the corresponding candidate profile in Recruit CRM as document attachments. We handle file naming conventions, encoding issues, and file type validation during extraction. File format compatibility (PDF, DOCX, DOC) is checked against Recruit CRM's supported attachment types before import. Large resume batches are processed in chunks to avoid timeout during the attachment re-association step.
Tracker
Custom Field (candidate, job, company)
Recruit CRM & ATS
Custom field
1:1Tracker custom fields on Candidate, Job, and Company objects are enumerated during discovery and mapped to Recruit CRM custom fields of equivalent data type. Text, number, date, dropdown, and checkbox fields map directly; multi-select dropdown fields require type validation against Recruit CRM's supported field types. Custom field values attached to candidate records are inserted during the relevant object import phase. Custom fields that drive stage-level automation in Tracker are flagged separately in the automation inventory since the automation itself cannot migrate.
| Tracker | Recruit CRM & ATS | Compatibility | |
|---|---|---|---|
| Candidate | Candidate1:1 | Fully supported | |
| Company | Company1:1 | Fully supported | |
| Job | Job1:1 | Fully supported | |
| Contact | Contact (within Company or standalone)1:many | Fully supported | |
| Placement | Candidate (status and custom fields)lossy | Fully supported | |
| Activity (calls, emails, notes, tasks) | Activity log entries on Candidate and Job1:1 | Fully supported | |
| Pipeline Stage | Pipeline status valueslossy | Fully supported | |
| Automation Sequence | Workflow automation (rebuild required)1:1 | Fully supported | |
| Document / Attachment | Candidate document attachment1:1 | Fully supported | |
| Custom Field (candidate, job, company) | Custom field1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Tracker gotchas
Automation workflows do not migrate as functional rules
CSV export is the primary migration path for most customers
Unlimited record model can mask deduplication needs
Recruit CRM & ATS gotchas
API rate limits are license-scaled and can throttle bulk migration
Custom field schemas vary per organization and require field-level mapping
Files and email attachments require separate extraction and re-upload
Email sequences and automation logic do not transfer between platforms
Pair-specific challenges
Migration approach
Discovery and CSV extraction
We extract candidate records, job postings, company profiles, contact records, placement history, and activity logs from Tracker via CSV export. We enumerate custom fields on each object, review active Automation Playbook sequences, and assess record volume and age distribution. We map the Tracker-to-Recruit CRM field schema during discovery and identify deduplication candidates (records sharing the same name and email). The discovery output is a written migration scope, field mapping document, and deduplication candidate list for customer review before import begins.
Deduplication and record cleanup
We run candidate deduplication against name, email address, and phone number against the Tracker CSV export. Duplicates are presented to the customer with a resolution recommendation (keep the most recently updated record, merge where activity history is richest). We apply the agreed deduplication rules and produce a cleaned import set sized against the destination Recruit CRM plan tier (Pro: 10,000 per user, Business: 20,000 per user, Enterprise: unlimited) to confirm headroom before any records are loaded. We also filter records older than the agreed age cutoff to manage volume.
Recruit CRM schema configuration
We configure the destination Recruit CRM environment ahead of data import. This includes setting up job pipelines and status values to match Tracker's pipeline stage names and order, creating custom fields on Candidate, Job, and Company to receive Tracker's custom field values (including placement metadata: start date, compensation, bill rate, client name), and configuring user seats and role assignments aligned with the customer's team size. We validate that the configured plan tier has sufficient data headroom for the cleaned import set.
Sandbox validation
We run a full migration into Recruit CRM's environment using a subset of production data representing typical record types (active candidates, open jobs, recent placements, sample activity history). We validate record counts, field mapping accuracy, custom field population, pipeline stage assignment, and document attachment integrity. The customer reviews the sandbox import and signs off the mapping before production migration begins. Any field mapping corrections are applied at this stage.
Production migration in dependency order
We run production migration in record dependency order: Companies first (as parent records), then Contacts (linked to companies), Candidates (with deduplication applied and company association resolved), Jobs (with pipeline and stage assignment), Placements (as candidate status changes with billing metadata in custom fields), Activity history (calls, emails, notes attached to the resolved Candidate and Job records), and Documents (re-attached to candidate profiles). Custom field values are inserted during the relevant object import phase. Each phase emits a row-count reconciliation report.
Cutover, validation, and automation rebuild handoff
We freeze Tracker writes during cutover, run a final delta migration of records modified during the migration window, then switch Recruit CRM to active. We validate the candidate count against Recruit CRM's data usage dashboard to confirm no plan tier limits are breached. We deliver the Automation Playbook inventory document to the customer admin for rebuild in Recruit CRM's workflow automation. We support a one-week hypercare window to resolve any record linkage issues, duplicate residues, or custom field gaps surfaced by the customer's team.
Platform deep dives
Tracker
Source
Strengths
Weaknesses
Recruit CRM & ATS
Destination
Strengths
Weaknesses
Complexity grading
Standard HRMS migration. 1 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Tracker and Recruit CRM & ATS.
Object compatibility
1 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Tracker: Not publicly documented.
Data volume sensitivity
Tracker doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Tracker to Recruit CRM & ATS migration scoping. Not seeing yours? Book a call.
Walk through your Tracker to Recruit CRM & ATS migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Tracker
Other ways to arrive at Recruit CRM & ATS
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.