HRMS migration
Field-level mapping, validation, and rollback between mploy and BambooHR. We move data and schema; workflows are rebuilt natively in BambooHR.
mploy
Source
BambooHR
Destination
Compatibility
8 of 10
objects map 1:1 between mploy and BambooHR.
Complexity
BStandard
Timeline
2-3 weeks
Overview
Moving from mploy to BambooHR is a structural upgrade from a flat-rate ATS to a per-employee HRIS that covers hiring, onboarding, employee records, time tracking, benefits, and performance. mploy has no confirmed public API, so every migration relies on admin-panel CSV exports that the customer must validate for completeness before we begin mapping. BambooHR's documented REST API lets us push data in typed batches with field-level validation, but the source export is the critical path item that determines feasibility. We do not migrate mploy Workflows or automations because mploy's configuration layer is undocumented and cannot be reliably reverse-engineered. We deliver a written schema map of every BambooHR object the customer should configure (pipelines, employee fields, onboarding templates) before the data load so that records land in a usable state on day one.
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 mploy 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.
mploy
Candidate
BambooHR
Candidate (BambooHR ATS)
1:1mploy Candidates map to BambooHR Candidate records using BambooHR's Candidates API endpoint. Standard fields (first name, last name, email, phone, status, rating) migrate directly. Source attribution from mploy becomes the BambooHR custom question field or a standard Source picklist value. We flag any mploy Candidate record without a valid email address for manual review before import because BambooHR requires a bestEmail value for the Candidate to be fully functional.
mploy
Job
BambooHR
Job (BambooHR ATS)
1:1mploy Jobs map to BambooHR Job records using BambooHR's Jobs API. Active and archived jobs migrate with their status preserved; mploy's job description field maps to BambooHR's question set or a custom text field depending on the destination field configuration. Department and location from mploy map to BambooHR's department and location picklists, which the customer configures in the BambooHR admin panel before migration.
mploy
Application
BambooHR
Candidate Application (BambooHR ATS)
1:1mploy Applications (the join records linking Candidates to Jobs) map to BambooHR Candidate records with an associated Application status. The application date, submission source, and pipeline stage migrate as BambooHR custom fields or application status values. Stage transition timestamps from mploy replay as BambooHR application status history entries. If mploy stores application-stage history as a separate data export, we replay it as structured notes on the BambooHR Candidate record.
mploy
Pipeline
BambooHR
Hiring Pipeline or Stage (BambooHR ATS)
lossymploy pipeline stage names and sequence map to BambooHR's hiring pipeline configuration. We preserve the ordered stage sequence (e.g., Applied, Phone Screen, Interview, Offer) as BambooHR pipeline stages, with custom stage names translated to the closest BambooHR status equivalent. Stage probability rates from mploy migrate as informational notes for the customer's admin to configure in BambooHR's pipeline settings.
mploy
User
BambooHR
Employee (BambooHR HRIS)
1:manymploy Users who are also employees (recruiters, hiring managers with employee records) map to BambooHR Employee records via the BambooHR Employees API. Admin-role Users without a corresponding employee record migrate as BambooHR user accounts with the recruiter role assigned. Role assignments (admin, recruiter, hiring manager) from mploy map to BambooHR role permissions that the customer configures in BambooHR Access Control before user provisioning.
mploy
Custom Fields (Candidates)
BambooHR
Custom Fields (BambooHR Candidates)
1:1Custom fields on mploy Candidates require explicit enumeration during discovery because no public schema documentation exists. We extract the field names, data types, and picklist values from the customer's mploy admin panel export, then map each to a BambooHR custom Candidate field. The customer must walk us through their custom field configuration before we can produce the mapping; this enumeration step adds one to two business days to discovery. We flag any mploy multi-select or checkbox fields for translation to BambooHR's custom field picklist format.
mploy
Custom Fields (Jobs)
BambooHR
Custom Fields (BambooHR Jobs)
1:1Custom fields on mploy Job postings migrate to BambooHR custom fields on Job records using the BambooHR Jobs API customField parameter. Like Candidate custom fields, Job custom fields require manual enumeration during discovery. We document the source field name, data type, and value set, then produce a field-level mapping to BambooHR's equivalent custom field configuration.
mploy
Offer
BambooHR
Candidate Record or Custom Object
1:1mploy Offer records (compensation, start date, acceptance status) map to BambooHR Candidate record fields or a custom Offer object depending on the customer's BambooHR configuration. Offer details migrate as structured data on the BambooHR Candidate record with custom fields for compensation, start date, and offer status. If the customer has configured BambooHR's built-in Offer Letter feature, we map to that feature's fields instead.
mploy
Interview
BambooHR
Note or Calendar Event (manual reconstruction)
1:1Interview records are not confirmed as a separately exportable object in mploy. Where interview data exists in mploy, it is typically embedded in the Application record or stored as free-text notes. We attempt to capture interview date, interviewer, and outcome as structured notes on the corresponding BambooHR Candidate record. We flag this as a manual-reconstruction item in the migration scope and recommend the customer's admin configure BambooHR's interview scheduling and feedback tools post-migration to rebuild the interview workflow natively.
mploy
Document Attachments
BambooHR
File Storage (BambooHR)
1:1Resume files and uploaded attachments from mploy require separate export handling because they may not be included in the standard candidate CSV export. We request a separate file archive from mploy (admin-panel or vendor-facilitated) and map each file to the corresponding BambooHR Candidate record using BambooHR's file upload API. Attachment file names are matched to candidate records by email address as the dedupe key. We flag any attachment archive that is unavailable or inaccessible before migration begins as a blocking item.
| mploy | BambooHR | Compatibility | |
|---|---|---|---|
| Candidate | Candidate (BambooHR ATS)1:1 | Fully supported | |
| Job | Job (BambooHR ATS)1:1 | Fully supported | |
| Application | Candidate Application (BambooHR ATS)1:1 | Fully supported | |
| Pipeline | Hiring Pipeline or Stage (BambooHR ATS)lossy | Fully supported | |
| User | Employee (BambooHR HRIS)1:many | Fully supported | |
| Custom Fields (Candidates) | Custom Fields (BambooHR Candidates)1:1 | Fully supported | |
| Custom Fields (Jobs) | Custom Fields (BambooHR Jobs)1:1 | Fully supported | |
| Offer | Candidate Record or Custom Object1:1 | Fully supported | |
| Interview | Note or Calendar Event (manual reconstruction)1:1 | Fully supported | |
| Document Attachments | File Storage (BambooHR)1: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.
mploy gotchas
No public API confirmed for programmatic data extraction
Zero third-party reviews create a reliability blind spot
Custom field schema is customer-specific and must be enumerated manually
Candidate document attachments require separate export handling
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 export capability confirmation
We begin by confirming whether the customer has admin-panel access to mploy and can produce bulk CSV exports of Candidates, Jobs, Applications, and any custom field data. We request a sample export (five to ten records each object) to validate column names, date formats, and boolean representations. If the customer cannot produce exports independently, we flag this as a blocking item and recommend contacting mploy support for vendor-facilitated data extraction. We simultaneously enumerate the custom field schema through a screen-share walkthrough of the mploy admin panel, documenting field names, data types, and picklist values for every custom field in use.
BambooHR destination schema design
We design the BambooHR configuration based on the customer's target HRIS state. This includes setting up BambooHR employee fields (matching mploy source fields to BambooHR's standard and custom employee fields), configuring the ATS pipeline stages to reflect mploy's stage sequence, mapping department and location picklists, and setting up custom Candidate fields aligned with mploy's custom Candidate fields. We use BambooHR's API to pre-create all custom fields before any data import begins, so that the import schema is fully resolved at load time.
Attachment archive collection and validation
We collect the resume and attachment file archive from mploy separately from the record export. We validate that the archive is organized (ideally by candidate email or candidate ID) and that file types are compatible with BambooHR's supported formats. We produce a file-to-candidate mapping by matching attachment file names or archive folder structure against the candidate email addresses in the main export. If the archive is unavailable, we document the gap and recommend the customer requests it from mploy before cutover.
Sandbox or pilot import and reconciliation
We run a pilot import into a test BambooHR account or sandbox environment using a subset of the mploy export (typically 25-50 candidate records). The customer's HR admin spot-checks the imported records against the source mploy data for field accuracy, date correctness, and attachment presence. We resolve any field mapping corrections identified during the pilot before committing to the full production import. This step validates the enumeration work from discovery and catches data quality issues before they affect the full dataset.
Production migration in dependency order
We run the full production migration using BambooHR's REST API in record-dependency order: Jobs first (to configure the ATS job records), then Candidates, then Applications linked to their parent job and candidate records. Custom fields are applied as part of each object's import payload using the BambooHR customField parameter. Resume and attachment files upload via BambooHR's file API, linked to the corresponding Candidate record by email address as the dedupe key. We emit a row-count reconciliation report after each phase.
Cutover, hire-from-candidate handoff, and automation rebuild guide
We freeze mploy write access during cutover and run a final delta migration of any records modified during the migration window. We deliver a cutover checklist to the customer's BambooHR admin that includes running the hire-from-candidate action for each hired Candidate to create the linked Employee record in BambooHR's HRIS. We do not migrate mploy automations or workflows because no automation layer is documented for mploy; we deliver a written guide to BambooHR's built-in hiring pipeline automation features (stage triggers, email templates, onboarding task assignments) for the admin to configure post-migration.
Platform deep dives
mploy
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 mploy 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
mploy: Not publicly documented.
Data volume sensitivity
mploy 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 mploy to BambooHR migration scoping. Not seeing yours? Book a call.
Walk through your mploy 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 mploy
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.