HRMS migration
Field-level mapping, validation, and rollback between JOIN and Recruit CRM & ATS. We move data and schema; workflows are rebuilt natively in Recruit CRM & ATS.
JOIN
Source
Recruit CRM & ATS
Destination
Compatibility
10 of 11
objects map 1:1 between JOIN and Recruit CRM & ATS.
Complexity
BStandard
Timeline
2-3 weeks
Overview
Moving from JOIN to Recruit CRM is a platform-to-platform ATS migration within the SMB-to-mid-market recruiting segment. JOIN uses Jobs as the parent container with Candidates and Applications as child records, and exposes a Candidate-level API for profile extraction. Recruit CRM uses a unified Candidate object that consolidates contact info, work history, skills, and pipeline activity in one record type. The primary migration risk is JOIN's undocumented activity log API: internal email threads, scheduled interviews, and call logs must be exported manually as a CSV before cutover because they are not accessible via JOIN's documented endpoints. Pipeline stage names are not standardised in JOIN — each job carries its own stage sequence — so we extract the full stage list per job during the scan phase and build a customer-specific mapping table for Recruit CRM. Custom fields on Candidates have no standardised schema in JOIN and require customer confirmation of the intended Recruit CRM equivalents during scoping. Automations, email sequences, and employer branding assets do not migrate; we deliver a written inventory of these for the customer's team to rebuild post-migration.
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 JOIN 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.
JOIN
Candidate
Recruit CRM & ATS
Candidate
1:1JOIN Candidates map directly to Recruit CRM Candidates. We extract contact info (name, email, phone, location), work history, education, skills tags, source attribution, and current pipeline stage via the JOIN API. The candidate's current stage is resolved against the per-job stage mapping table built at scoping. Any JOIN custom fields on Candidate are extracted as associated_fields and require customer confirmation of the Recruit CRM field ID equivalents before migration.
JOIN
Job
Recruit CRM & ATS
Job
1:1JOIN Jobs map to Recruit CRM Jobs with title, description, department, location, employment type, and posting status transferred directly. Job status (active, paused, closed) maps to the Recruit CRM status field. Job department and employment type become custom dropdowns or text fields in Recruit CRM depending on the plan configuration.
JOIN
Application
Recruit CRM & ATS
Candidate-Job Association
1:1JOIN Applications link a Candidate to a Job with applied date, referral source, and rejection or offer flags. Recruit CRM models this relationship as a Candidate record with associated Job records via the associated-fields endpoint. We map the application date to the candidate's applied_date on the job association, and the rejection or offer status to the Recruit CRM status field on the associated job.
JOIN
Pipeline Stage
Recruit CRM & ATS
Stage
lossyJOIN does not enforce a universal stage schema — each job carries a custom stage sequence. We extract the full stage list per job during the scan phase and build a customer-specific mapping table. Recruit CRM uses a configurable stage list per job. Where JOIN has fewer stages than the target job, we collapse intermediate stages and preserve stage-entry dates as associated field metadata so timing context is not lost.
JOIN
Scorecard / Interview Feedback
Recruit CRM & ATS
Candidate Notes or Custom Fields
1:1Interview evaluations and structured feedback stored in JOIN migrate as Candidate notes or custom fields in Recruit CRM. Where Recruit CRM's job associated fields support structured evaluation data, we populate those fields using the JOIN scorecard values. Free-text interview notes migrate as attached notes on the Candidate record.
JOIN
Custom Fields (Job-level)
Recruit CRM & ATS
Job Custom Fields
1:1JOIN supports employer-defined custom fields on the Job object. These have no standardised schema. We extract the full schema during scan, then map each custom field to a Recruit CRM job custom field equivalent or flag it as a free-text property. Recruit CRM exposes custom fields via the API with explicit field IDs that must be confirmed before import.
JOIN
Custom Fields (Candidate-level)
Recruit CRM & ATS
Job Associated Fields
1:1JOIN Candidate custom fields migrate to Recruit CRM job associated fields (the per-candidate, per-job property store). The associated_fields endpoint in Recruit CRM accepts field_id and value pairs for each candidate-job combination. We extract all JOIN Candidate custom fields during scan and require the customer to confirm Recruit CRM field ID mappings before migration. Unmapped fields land as free-text associated fields.
JOIN
Resume / Attachment Files
Recruit CRM & ATS
Candidate Resume and Attachments
1:1Candidate resume files and supporting documents export from JOIN with non-standard filenames derived from internal IDs. We normalise filenames to a consistent convention (CandidateName_JobTitle_Date) during the export phase to prevent filename collisions in bulk downloads and ensure files are identifiable upon ingestion. Files are uploaded to Recruit CRM as linked attachments on the Candidate record.
JOIN
Owner
Recruit CRM & ATS
User
1:1JOIN Owners map to Recruit CRM Users. We resolve owners by email match. Any JOIN Owner without a matching Recruit CRM User is held in a reconciliation queue for the customer's admin to provision before record import resumes. Inactive JOIN owners are mapped to inactive Recruit CRM users to preserve assignment history.
JOIN
Activity and Communication History
Recruit CRM & ATS
Not Migrated (Manual CSV Required)
1:1JOIN does not expose email threads, scheduled interview events, or activity log entries through a documented API endpoint. Internal activity timeline records cannot be extracted via API and must be exported manually as a CSV from the JOIN dashboard before cutover. We ingest the CSV alongside the API extract and load the activity data as Candidate notes in Recruit CRM. We flag this requirement at scoping and coordinate the manual export timing with the customer.
JOIN
Tags / Skills
Recruit CRM & ATS
Skills Tags
1:1JOIN Candidate skills tags and source attribution (e.g., LinkedIn, referral, job board) map to Recruit CRM skills fields or custom multi-select fields. Skills are migrated as comma-separated or multi-select values depending on the Recruit CRM field configuration at the destination.
| JOIN | Recruit CRM & ATS | Compatibility | |
|---|---|---|---|
| Candidate | Candidate1:1 | Fully supported | |
| Job | Job1:1 | Fully supported | |
| Application | Candidate-Job Association1:1 | Fully supported | |
| Pipeline Stage | Stagelossy | Fully supported | |
| Scorecard / Interview Feedback | Candidate Notes or Custom Fields1:1 | Fully supported | |
| Custom Fields (Job-level) | Job Custom Fields1:1 | Fully supported | |
| Custom Fields (Candidate-level) | Job Associated Fields1:1 | Fully supported | |
| Resume / Attachment Files | Candidate Resume and Attachments1:1 | Fully supported | |
| Owner | User1:1 | Fully supported | |
| Activity and Communication History | Not Migrated (Manual CSV Required)1:1 | Not supported | |
| Tags / Skills | Skills Tags1: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.
JOIN gotchas
Activity log and communication history are not exported via JOIN API
Pipeline stage names vary per job and per plan
Custom fields on Candidates require manual equivalence review
Resume and attachment export format is non-standard
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 scoping
We audit the source JOIN account for candidate record count, active job count, application volume, custom field schema (job-level and candidate-level), owner list, stage sequences per job, and any active workflows or email sequences. We also confirm whether the manual activity log CSV export has been or can be completed by the admin. The discovery output is a written migration scope document listing record counts, schema inventory, stage mapping requirements, and any manual export tasks assigned to the customer.
Schema preparation and field ID confirmation
We create the destination schema in Recruit CRM including job custom fields, candidate associated fields, stage configuration per job, and user provisioning for all JOIN owners. Recruit CRM requires custom fields to be pre-created with explicit field IDs before bulk import. We require the customer to confirm the Recruit CRM field ID for each custom field in the mapping table before we proceed to the import phase. Owner reconciliation matches JOIN owners to Recruit CRM users by email; missing users go to a queue for admin provisioning.
Activity log manual export coordination
We coordinate with the customer to complete the manual activity log CSV export from the JOIN dashboard. This is the customer's responsibility and must be completed before the cutover window. We provide the customer with instructions for the export format, advise on the required fields (date, type, content, related candidate), and ingest the CSV file alongside the API extract. Without this export, the internal activity timeline does not migrate.
Staging migration and reconciliation
We run a full migration into a staging or test environment in Recruit CRM using representative data volume. The customer's recruiting operations lead reviews record counts (Candidates in, Jobs in, Applications in, stage assignments), spot-checks 20-30 records against JOIN, and signs off the mapping before production migration begins. Stage mapping and custom field mapping corrections happen in staging, not in production.
Production migration in dependency order
We run production migration in record-dependency order: Jobs first (parent records), then Candidates (with owner resolution), then Applications (candidate-to-job associations via associated_fields API), then stage assignments via the associated_fields endpoint, then activity notes from the manual CSV. Each phase emits a row-count reconciliation report. JOIN API rate limits are respected with batch chunking and exponential backoff. Active WRITE access to JOIN is frozen during the cutover window to prevent delta records from being created after the final extract.
Cutover, validation, and automation handoff
We freeze JOIN write access during cutover, run a final delta migration of any records modified during the window, then enable Recruit CRM as the system of record. We deliver the automation and email sequence inventory document to the customer's admin team with recommended Recruit CRM workflow configurations. We support a three-day hypercare window where we resolve any reconciliation issues raised by the recruiting team. We do not rebuild JOIN automations as Recruit CRM workflows inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
JOIN
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 JOIN 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
JOIN: Not publicly documented.
Data volume sensitivity
JOIN 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 JOIN to Recruit CRM & ATS migration scoping. Not seeing yours? Book a call.
Walk through your JOIN 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 JOIN
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.