HRMS migration
Field-level mapping, validation, and rollback between Greenhouse and Recruit CRM & ATS. We move data and schema; workflows are rebuilt natively in Recruit CRM & ATS.
Greenhouse
Source
Recruit CRM & ATS
Destination
Compatibility
9 of 11
objects map 1:1 between Greenhouse and Recruit CRM & ATS.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Migrating from Greenhouse to Recruit CRM is a shift from a structured-in-house ATS built for enterprise hiring processes to an ATS-plus-CRM hybrid designed for recruitment agencies and staffing teams. Greenhouse organizes hiring around structured scorecards, interview kits, and configurable pipeline stages; Recruit CRM unifies candidate management, client relationships, and job postings in a single recruiting CRM with AI-powered resume parsing and matching. The migration preserves all Candidate profiles, Application histories, Job records, Offers, and Greenhouse custom field values, but Greenhouse Scorecards serialize into text blocks or custom fields since Recruit CRM does not expose a native structured interview evaluation object. We extract from Greenhouse via the Harvest API v3 with cursor-based pagination and load into Recruit CRM via its documented bulk import endpoints, sequencing parent records before child records to satisfy lookup dependencies. Active candidates in flight at migration cutover require a manual export step performed by the customer's team in the Greenhouse UI, which we coordinate within the migration plan. Workflows, interview plans, and scorecard templates do not migrate as configuration; we deliver a written inventory of Greenhouse automation objects for the customer's admin to rebuild in Recruit CRM.
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 Greenhouse 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.
Greenhouse
Candidate
Recruit CRM & ATS
Contact
1:1Greenhouse Candidate records map to Recruit CRM Contact (candidate mode). We preserve name, email, phone, social URLs, tags, and all Greenhouse custom field values including single_select, multi_select, currency, date, and user-reference types. Phone number formatting is normalized during transform. Tags migrate as label arrays. Source attribution (referral, job board, direct apply) and any UTM data stored in custom fields migrate as Contact fields or custom fields in Recruit CRM.
Greenhouse
Application
Recruit CRM & ATS
Candidate Record (Application sub-record)
1:1Greenhouse Application records — which link a Candidate to a Job and store the application date, rejection or hire status, current stage, stage history timestamps, and rejection reasons — map to Recruit CRM's application-level sub-records on the Contact. We preserve the full stage history timeline and application-level scorecards as notes or custom fields. Active applications in flight at cutover require a manual export step from the customer's Greenhouse UI as documented in the gotchas section.
Greenhouse
Job
Recruit CRM & ATS
Job
1:1Greenhouse Job records (requisition-level: title, department, office location, open/closed status, opening date, job description) map directly to Recruit CRM Job records. Job posting URLs and job board distribution references migrate as metadata fields. We map Greenhouse office and department assignments to Recruit CRM's organization hierarchy and flag tiered office structures (Plus/Pro) for validation against the Recruit CRM schema before import.
Greenhouse
Offer
Recruit CRM & ATS
Offer
1:1Greenhouse Offers (compensation package attached to an Application: start date, salary, equity, custom offer fields, and status) migrate to Recruit CRM Offer records. Offer status values (pending, accepted, declined, retracted) map to Recruit CRM's offer status field. Custom offer fields translate directly to Recruit CRM custom fields by type.
Greenhouse
Scorecard
Recruit CRM & ATS
Custom Fields / Candidate Notes
lossyGreenhouse Scorecards store structured evaluator feedback (rating fields, follow-up questions, interviewer notes) tied to interview plans and pipeline stages. Recruit CRM does not expose a native structured scorecard object. We serialize scorecard content — interview type, scorecard questions, selected ratings, and evaluator notes — into a formatted text block stored in a custom field on the Candidate record, or as a chronological note entry in the activity timeline. The customer receives a written map of every Greenhouse scorecard template for admin-level rebuild as a Recruit CRM form or custom field set if structured evaluation tracking is required.
Greenhouse
User / Hiring Team Member
Recruit CRM & ATS
User
1:1Greenhouse Users (Site Admin, Recruiter, Hiring Manager) map by email match to Recruit CRM Users. We extract all distinct owner references from Candidate, Application, Job, and Offer records and reconcile against Recruit CRM's User table. Any Greenhouse user without a matching Recruit CRM account enters a provisioning queue; migration of records owned by unresolved users pauses until the customer provisions the corresponding Recruit CRM User.
Greenhouse
Custom Field
Recruit CRM & ATS
Custom Field
1:1Greenhouse custom fields across all supported value types — short_text, long_text, yes_no, single_select, multi_select, currency, number, date, url, user_reference — map directly to Recruit CRM custom fields of the equivalent type. We validate field type compatibility during scoping and flag any Greenhouse field type that requires transformation (e.g., user_reference values resolve to the corresponding Recruit CRM User ID before import). Multi-select values migrate as comma-separated strings or as Recruit CRM's multi-select format depending on destination field configuration.
Greenhouse
Office / Department
Recruit CRM & ATS
Organization Hierarchy
lossyGreenhouse flat offices and departments (Core tier) map to Recruit CRM's organizational structure directly. Tiered office and department hierarchies available on Greenhouse Plus and Pro are validated against Recruit CRM's hierarchy model; if the customer's Plus/Pro tier hierarchy is deep or complex, we flag it for admin-level reconstruction in Recruit CRM rather than automated mapping, because Recruit CRM's org hierarchy has different modeling conventions.
Greenhouse
Tag
Recruit CRM & ATS
Tag / Label
1:1Greenhouse tags on Candidate and Application records migrate as label arrays in Recruit CRM. Greenhouse allows unlimited tags; Recruit CRM's tagging model supports equivalent labeling. We preserve tag names exactly and map them to the destination's tagging fields on the Contact record.
Greenhouse
Activity / CRM Event
Recruit CRM & ATS
Activity Log
1:1Plus and Pro tier CRM events (calls, emails, notes) from Greenhouse migrate to Recruit CRM activity log entries. Core tier customers are limited to a single CRM event type in Greenhouse; we document this constraint during scoping and collapse available events into the single Recruit CRM activity type. Activity timestamp ordering is preserved. For Greenhouse Core customers, we advise upgrading to Plus before migration if comprehensive activity history migration is a requirement.
Greenhouse
Candidate Document / Attachment
Recruit CRM & ATS
Attachment
1:1Resume, cover letter, and portfolio files attached to Greenhouse Candidates or Applications migrate as binary blobs linked to the corresponding Recruit CRM Contact record. We handle file type detection during extraction and map file links to the Recruit CRM attachment model. Attachment filenames and file size metadata are preserved for reconciliation validation.
| Greenhouse | Recruit CRM & ATS | Compatibility | |
|---|---|---|---|
| Candidate | Contact1:1 | Fully supported | |
| Application | Candidate Record (Application sub-record)1:1 | Fully supported | |
| Job | Job1:1 | Fully supported | |
| Offer | Offer1:1 | Fully supported | |
| Scorecard | Custom Fields / Candidate Noteslossy | Fully supported | |
| User / Hiring Team Member | User1:1 | Fully supported | |
| Custom Field | Custom Field1:1 | Fully supported | |
| Office / Department | Organization Hierarchylossy | Fully supported | |
| Tag | Tag / Label1:1 | Fully supported | |
| Activity / CRM Event | Activity Log1:1 | Fully supported | |
| Candidate Document / Attachment | Attachment1: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.
Greenhouse gotchas
Bulk candidate import requires Plus or Pro tier
Active candidate migration is entirely manual
Historical migration takes 4–6 weeks for Greenhouse to process
Developer sandbox and audit log are Pro-only
CRM event limits in Core tier constrain activity history
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 tier validation
We audit the source Greenhouse instance across subscription tier (Core/Plus/Pro), candidate volume, job count, active application count, custom field inventory (count, types, dependencies), scorecard templates, tag sets, and engagement volume. We extract a sample of 50-100 records via the Harvest API v3 to validate field-level type compatibility and identify any Greenhouse-specific data (e.g., user_reference fields, tiered office hierarchies, anonymized scorecard fields) that requires special handling. The discovery output is a written migration scope document with record counts per object, custom field mapping table, and a tier-gating assessment that flags any Core-tier limitations requiring manual steps.
Active candidate manual-step planning
We coordinate the active candidate migration step with the customer before any automated extraction begins. This includes defining the export template from Greenhouse (which fields, which status filters for active applications), agreeing the dedupe strategy for candidates with multiple applications, and scheduling the manual export window. For Plus/Pro customers, we evaluate whether the Harvest API extraction covers all active candidates programmatically; if so, we remove the manual step from the plan. For Core customers, we document the manual step requirements clearly and provide a structured checklist so the customer's team can complete it withoutFlitStack AI intervention in the Greenhouse UI.
Recruit CRM schema preparation
We pre-create the destination schema in Recruit CRM before any data loads begin. This includes provisioning all custom fields required by the Greenhouse custom field inventory, configuring organization hierarchies to match Greenhouse office/department structures, setting up job record types for each Greenhouse job pipeline, and creating custom fields for serialized Greenhouse scorecard content. Recruit CRM's bulk import requires that all referenced lookups (e.g., User owner assignments) exist before child records import; we validate that the Recruit CRM User table is provisioned with the correct users before candidate import begins.
Data extraction, transformation, and sandbox import
We extract all Greenhouse objects via the Harvest API v3 with cursor-based pagination, handling rate-limit responses with exponential backoff. Transformation applies field-type mapping (Greenhouse value types to Recruit CRM types), owner resolution (Greenhouse user email to Recruit CRM User ID), dedupe application per the agreed strategy, and scorecard serialization to custom fields or candidate notes. We load transformed data into a Recruit CRM sandbox or staging environment first, validate record counts against source extraction totals, spot-check 25-50 records per object for field-level accuracy, and resolve any import errors before staging sign-off.
Production migration in dependency order
With staging validated, we run production migration in record-dependency order: Recruit CRM Users first (validated against the owner reconciliation queue), then Organizations or organizational units, then Job records, then Candidate records with Application data embedded, then Offers, then Activity history (call logs, emails, notes as available on the source tier), then Attachments. Each phase emits a row-count reconciliation report. Any records rejected on import are captured in an error log for customer admin review and reimport within the migration window.
Cutover, validation, and automation rebuild handoff
We freeze Greenhouse writes during cutover, run a final delta migration of any records modified during the migration window (captured via a timestamp filter on the Harvest API), then enable Recruit CRM as the system of record. We deliver a written inventory of Greenhouse workflows, interview plans, scorecard templates, and automation objects with a Recruit CRM rebuild recommendation for each. Post-migration, we support a one-week reconciliation window where we resolve data quality issues raised by the customer's team. We do not rebuild Greenhouse workflows or scorecard templates as Recruit CRM configuration within the migration scope; those are documented for the customer's admin to implement as a follow-on configuration engagement.
Platform deep dives
Greenhouse
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 Greenhouse 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
Greenhouse: Not publicly documented with specific numbers; rate limits are applied separately for custom integrations and partner integrations with separate policies for each.
Data volume sensitivity
Greenhouse exposes a bulk API — large-volume migrations stream efficiently.
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 Greenhouse to Recruit CRM & ATS migration scoping. Not seeing yours? Book a call.
Walk through your Greenhouse 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 Greenhouse
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.