HRMS migration
Field-level mapping, validation, and rollback between In-recruiting and BambooHR. We move data and schema; workflows are rebuilt natively in BambooHR.
In-recruiting
Source
BambooHR
Destination
Compatibility
7 of 10
objects map 1:1 between In-recruiting and BambooHR.
Complexity
BStandard
Timeline
2-3 weeks
Overview
In-recruiting is a European ATS built for recruitment agencies managing the full candidate lifecycle. BambooHR is a US-based HRIS with a lightweight ATS module designed for internal HR teams handling inbound applicants. The migration from In-recruiting to BambooHR crosses from a purpose-built ATS into an HRIS that happens to include an ATS add-on. The schema difference is significant: In-recruiting tracks candidates, applications, pipeline stages, and placements as first-class objects; BambooHR's ATS stores Candidates and Job Openings, with pipeline stages implemented as status fields and workflow-driven transitions. We map In-recruiting pipeline stages to BambooHR Hiring statuses and preserve the original stage labels as custom fields for reporting continuity. Custom fields, localized date formats, and multi-language data from In-recruiting require field-by-field translation to BambooHR's supported field types before import. We do not migrate In-recruiting workflows, automations, or email templates; we deliver a written inventory of every active workflow for the customer's BambooHR admin to 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 In-recruiting object lands in BambooHR, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
In-recruiting
Candidate
BambooHR
Candidate (People module)
1:1In-recruiting Candidate records map to BambooHR People as Candidate records (not Employee records, which are reserved for hired employees). The In-recruiting candidate first name, last name, email, phone, address, and source channel map to the equivalent BambooHR fields. We resolve duplicate candidates by email dedupe before import. Any In-recruiting GDPR consent flags map to BambooHR custom fields; the customer's BambooHR admin configures the corresponding consent records post-migration.
In-recruiting
Job
BambooHR
Job Opening
1:1In-recruiting Job records map to BambooHR Job Openings. The In-recruiting job title, description, department, location, and employment type map to the equivalent BambooHR fields. Open/closed status maps directly. Active In-recruiting jobs are handled last in the migration sequence so that live job postings remain functional through cutover. In-recruiting job fields with HTML-formatted descriptions are stripped to plain text before insertion into BambooHR.
In-recruiting
Application
BambooHR
Candidate (linked to Job Opening)
1:1In-recruiting Application records (the join entity between Candidate and Job) map to BambooHR Candidate records linked to a Job Opening. The Application ID is preserved in a custom BambooHR field for reconciliation. If the In-recruiting source system uses a separate Application object rather than a direct candidate-to-job relationship, we flatten it by linking the Candidate to the corresponding BambooHR Job Opening and preserving the application timestamp and status.
In-recruiting
Pipeline Stage
BambooHR
Candidate Status (custom workflow field)
lossyIn-recruiting pipeline stages (Configured Pipeline Stage 1, Stage 2, etc.) do not have a direct BambooHR equivalent because BambooHR uses a simpler candidate status model (Applied, Phone Screen, Interview, Offer, Hired). We map each In-recruiting stage to the nearest BambooHR status and preserve the original stage label in a custom multi-select picklist field original_pipeline_stage__c on the Candidate for reporting continuity. If In-recruiting uses more than five custom pipeline stages, we recommend consolidating during migration because BambooHR's status workflow is less flexible.
In-recruiting
Interview
BambooHR
Interview (BambooHR ATS feature)
1:1In-recruiting Interview records map to BambooHR Interview records on the Candidate. We transfer the interview date, interviewer name (resolved to a BambooHR User by email), interview type, duration, and interviewer score if present. Interviewer feedback notes migrate as a text custom field on the Interview record. If In-recruiting stores scorecard ratings in structured fields, we flatten them to a text field since BambooHR's ATS interview model does not support structured scorecard fields by default.
In-recruiting
Note
BambooHR
Note (attached to Candidate)
1:1In-recruiting Notes linked to Candidates, Applications, or Jobs map to BambooHR Notes attached to the corresponding Candidate or Job Opening. We preserve the note creation date, author (resolved to a BambooHR User by email), and note body. Rich-text notes from In-recruiting are converted to plain text with bullet points preserved. Notes attached to Placement records are migrated to the hired Employee's BambooHR People record.
In-recruiting
Company / Client
BambooHR
Company (BambooHR ATS) or Employee's employment data
1:1In-recruiting Company or Client records (used by staffing agencies to track client organizations) map to BambooHR Company records if the BambooHR account has the ATS Company feature enabled. If the destination BambooHR account does not use ATS Companies, we store the client organization name as a custom text field on the Candidate or Employee record. The customer chooses the strategy during scoping.
In-recruiting
User / Consultant
BambooHR
Employee (People module)
1:1In-recruiting User records (internal recruiting team members) map to BambooHR Employee records in the People module if the customer wants to manage their recruiting team within BambooHR. For organizations that only use BambooHR for candidate and employee data and not for internal user management, In-recruiting Users are not migrated; instead we map Owner references on records to the corresponding BambooHR User by email resolution.
In-recruiting
Tag / Skill
BambooHR
Custom fields (multi-select picklist)
lossyIn-recruiting tags (used to label candidates by skill, source, or category) map to BambooHR custom multi-select picklist fields. We create the custom field in BambooHR before migration, populate it with the unique tag values, and link it to the Candidate object. Tags used for candidate classification migrate to the custom field; tags used for sourcing attribution migrate to the candidate_source custom field. The customer specifies the tag strategy during scoping.
In-recruiting
Custom Fields
BambooHR
Custom Fields
lossyIn-recruiting custom fields on Candidate, Application, Job, and Interview migrate to BambooHR custom fields of the closest matching type. We translate In-recruiting field types (text, number, date, dropdown, checkbox, multi-select) to their BambooHR equivalents. Localized date formats from In-recruiting are converted to the format configured in the BambooHR destination account. Any In-recruiting custom fields with unsupported data types are flagged during discovery and resolved by the customer before migration.
| In-recruiting | BambooHR | Compatibility | |
|---|---|---|---|
| Candidate | Candidate (People module)1:1 | Fully supported | |
| Job | Job Opening1:1 | Fully supported | |
| Application | Candidate (linked to Job Opening)1:1 | Fully supported | |
| Pipeline Stage | Candidate Status (custom workflow field)lossy | Fully supported | |
| Interview | Interview (BambooHR ATS feature)1:1 | Fully supported | |
| Note | Note (attached to Candidate)1:1 | Fully supported | |
| Company / Client | Company (BambooHR ATS) or Employee's employment data1:1 | Fully supported | |
| User / Consultant | Employee (People module)1:1 | Fully supported | |
| Tag / Skill | Custom fields (multi-select picklist)lossy | Fully supported | |
| Custom Fields | Custom Fieldslossy | Mapping required |
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.
In-recruiting gotchas
Public API details are not surfaced in reviewer documentation
Tier structure couples user count, active jobs, and feature flags
Multiposting integrations are tier-gated and per-board configured
Reporting/statistics weakness flagged by reviewers
BambooHR gotchas
Undocumented API rate limits can trigger 503 errors
Per-employee pricing model requires active record count verification
API credentials must be sent on every request to avoid extra round trips
Custom field schema varies per account and requires manual inventory
Document and attachment exports are not covered by standard report exports
Pair-specific challenges
Migration approach
Discovery and data audit
We audit the In-recruiting account across all modules: Candidates, Jobs, Applications, Pipeline Stages, Interviews, Notes, Companies, Users, Tags, and Custom Fields. We document the count of each object, the structure of custom fields (type, required, multi-value), the pipeline stage definitions, and the active workflow inventory. We verify the export method available from In-recruiting (CSV export or REST API) and flag any localized data formats, multi-language fields, or GDPR consent records that require special handling. The discovery output is a written migration scope with object counts and a pre-flight checklist.
Field mapping and schema design
We build the destination schema in BambooHR before any data moves. This includes creating custom fields on the Candidate and Employee objects (mapped from In-recruiting custom fields), configuring the candidate status workflow (mapped from In-recruiting pipeline stages), and setting up any required BambooHR Job Opening fields. For GDPR compliance, we create consent-related custom fields on the Candidate record. We design the custom field original_pipeline_stage__c to carry the In-recruiting stage label through the migration. The schema is reviewed with the customer before any import begins.
Sandbox validation migration
We run a full migration into a BambooHR sandbox or a test environment using a representative subset of production data (at minimum 50 candidates, 20 jobs, 10 interviews, and 5 candidates per pipeline stage). The customer's HR admin reviews the migrated records, verifies that custom field values appear correctly, confirms that pipeline stage consolidation is acceptable, and spot-checks search and filter functionality. Any field mapping corrections are documented and applied before the production migration begins. Sandbox validation is non-negotiable for this pair because of the pipeline stage consolidation step.
Active job handling strategy
We sequence the migration so that active job postings and open applications are migrated last, after all other record types are validated in BambooHR. During the active-job migration window, we freeze writes in In-recruiting for a brief cutover period (typically 4-8 hours) to capture any final application submissions. Live job postings remain functional in In-recruiting until the moment of cutover, then redirect to BambooHR if the customer has set up a careers page integration. Any applications submitted during the cutover window are captured in a delta migration and inserted into BambooHR before go-live.
Production migration in dependency order
We run production migration in record-dependency order: first Job Openings (no dependencies), then Candidates (no upstream dependencies), then Applications (linked to Job Openings and Candidates by ID), then Interviews (linked to Candidates), then Notes (linked to Candidates), then Tags (linked to Candidates by ID). Custom fields are created in BambooHR via the BambooHR API before data insertion. We use batched inserts with exponential backoff on API rate limit responses. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and workflow inventory handoff
We freeze In-recruiting writes at cutover, run a final delta migration for any records modified during the migration window, then enable BambooHR as the system of record. We validate record counts, spot-check 25-50 migrated records for field accuracy, and confirm that pipeline stage consolidation appears correctly in the BambooHR Hiring dashboard. We deliver the In-recruiting workflow and email template inventory document to the customer's BambooHR admin. We do not rebuild In-recruiting automations as BambooHR Automations inside the migration scope.
Platform deep dives
In-recruiting
Source
Strengths
Weaknesses
BambooHR
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 In-recruiting and BambooHR.
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
In-recruiting: Not publicly documented.
Data volume sensitivity
In-recruiting 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 In-recruiting to BambooHR migration scoping. Not seeing yours? Book a call.
Walk through your In-recruiting to BambooHR migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave In-recruiting
Other ways to arrive at BambooHR
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.