HRMS migration
Field-level mapping, validation, and rollback between Factorial and BambooHR. We move data and schema; workflows are rebuilt natively in BambooHR.
Factorial
Source
BambooHR
Destination
Compatibility
6 of 10
objects map 1:1 between Factorial and BambooHR.
Complexity
BStandard
Timeline
2-4 weeks
Overview
Factorial and BambooHR both serve small-to-mid-sized businesses with core HRMS functions, but they differ in payroll strategy, geographic focus, and data architecture. Factorial bundles payroll with country-locked legal entity configurations targeting Spanish and Latin American labor law; BambooHR outsources payroll to a separate product, which requires teams to recompute net-pay figures or connect a third-party payroll provider post-migration. The two platforms share a similar employee data model, making the core employee record migration straightforward, but absence accrual rules, custom fields, and document archives require active mapping work. We do not migrate approval workflows, document automation, or approval chains as code; we deliver a written inventory of every active workflow for the customer's admin to rebuild in BambooHR. Compensation history and time entry timestamps are fully portable; payroll run data (gross pay, deductions, net pay) is exported as structured records but requires recomputation in the destination's payroll logic.
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 Factorial 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.
Factorial
Employee
BambooHR
Employee (core)
1:1Factorial Employee records map directly to BambooHR Employee. We transfer name fields, contact information, employment status, hire date, job title, and department via lookup. Factorial's employment status values (active, inactive, on leave) map to BambooHR's status field. We discover all active custom employee fields during scoping by calling the employee endpoint and enumerate each one for mapping to BambooHR custom fields before production migration.
Factorial
Department and Cost Center
BambooHR
Location and Department (custom)
lossyFactorial departments and cost centers with parent-child relationships map to BambooHR Locations as the primary organizational unit, with a custom department field added to Employee for multi-level hierarchies. We preserve the full organizational tree and flag any departments with no assigned employees for customer admin review.
Factorial
Absence Record
BambooHR
Time-Off (Policy and History)
1:1Factorial absence types and approved records map to BambooHR time-off policies and time-off history. Accrual balances are preserved as snapshots at migration time, but BambooHR's accrual rules must be reconfigured to match the original Factorial accrual logic (monthly, yearly, or anniversary-based). Custom absence types discovered during scoping are mapped to BambooHR equivalents or flagged for policy creation.
Factorial
Document
BambooHR
Files (per Employee)
1:1Factorial documents attached to employee records migrate as files on the corresponding BambooHR Employee. Factorial does not expose a bulk document export endpoint, so we paginate the documents list via API and download each file individually. We flag document-heavy migrations (over 500 files per account) during scoping and set timeline expectations accordingly. BambooHR applies per-file size limits that we verify against the source archive during discovery.
Factorial
Compensation History
BambooHR
Employment Info (Pay) and custom fields
1:manyFactorial stores historical salary changes, bonuses, and equity grants as effective-dated compensation records on each Employee. We migrate these as separate entries on the BambooHR Employee Employment Info tab for current pay, with any additional historical compensation entries stored as custom date-stamped fields or a migration-specific notes field. Effective dates are preserved to maintain the full compensation timeline.
Factorial
Time Entry
BambooHR
Time Tracking (Time Cards)
1:1Factorial clock-in/out records and timesheets with timestamps, hours, and project or cost-center tags migrate to BambooHR time tracking as individual entries in chronological order. Original timestamps are preserved. Factorial project and cost-center tags that have no BambooHR equivalent are stored in a custom field for admin reference. Large time-entry archives (over 50,000 records) require batch processing with reconciliation by employee and date range.
Factorial
Contract
BambooHR
Employment Info
1:1Factorial employment contracts including contract type, working hours, probation period, and legal entity reference map to the BambooHR Employment Info tab. Country-specific legal clauses and mandatory fields that do not map directly to BambooHR standard fields are stored in custom fields or the contract notes section. The customer admin should verify all country-specific contract fields after migration against local labor requirements.
Factorial
Custom Fields (Employee)
BambooHR
Custom Fields
lossyFactorial custom fields on Employee, Contract, and Document objects are discovered during scoping by calling the relevant endpoints. We map each Factorial custom field to a BambooHR custom field of the matching type (text, number, date, dropdown, checkbox). Fields with no direct BambooHR equivalent are flagged in the mapping document for the customer admin to review and resolve before production migration.
Factorial
Workflow and Approval
BambooHR
N/A (documentation only)
1:1Approval chains for time-off, expenses, and documents are defined as Factorial workflow objects with no export representation. BambooHR uses custom approval workflows with a different configuration model. We do not migrate workflows as code. We document the active Factorial workflow structure (trigger, conditions, approvers, actions) during discovery and deliver it as a written map so the customer admin can rebuild approvals in BambooHR's workflow configuration.
Factorial
Payroll Run
BambooHR
N/A (compensation record only)
lossyFactorial payroll runs are tied to the country legal entity and include gross salary, deductions, supplements, overtime, and net pay. We export payroll data as structured compensation records with gross amounts and deduction codes preserved. Net pay calculations, tax withholding, and social security contributions must be recomputed in BambooHR's payroll logic or in the third-party payroll provider the customer selects post-migration. Payroll data is not imported as paid payroll runs in BambooHR.
| Factorial | BambooHR | Compatibility | |
|---|---|---|---|
| Employee | Employee (core)1:1 | Fully supported | |
| Department and Cost Center | Location and Department (custom)lossy | Fully supported | |
| Absence Record | Time-Off (Policy and History)1:1 | Fully supported | |
| Document | Files (per Employee)1:1 | Fully supported | |
| Compensation History | Employment Info (Pay) and custom fields1:many | Mapping required | |
| Time Entry | Time Tracking (Time Cards)1:1 | Fully supported | |
| Contract | Employment Info1:1 | Fully supported | |
| Custom Fields (Employee) | Custom Fieldslossy | Fully supported | |
| Workflow and Approval | N/A (documentation only)1:1 | Fully supported | |
| Payroll Run | N/A (compensation record only)lossy | 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.
Factorial gotchas
No public bulk export API for documents
Custom fields are not discoverable via a schema endpoint
Payroll data is country-locked to the legal entity
Workflow automation does not export
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 scoping
We audit the source Factorial account across all active modules: employee records, departments, absence types and accrual rules, compensation history, time entries, and documents. We enumerate all custom fields by calling the employee and contract endpoints, document active workflows and approval chains, and identify the payroll legal entities in use. The discovery output is a written migration scope with object counts, custom field inventory, document volume estimate, and a recommendation on whether historical time entries require full migration or a reduced lookback window.
Schema design and policy mapping
We design the destination BambooHR configuration: employees with standard and custom fields created by the admin using our discovered field inventory, locations and department structure from the Factorial organizational hierarchy, time-off policies matched to Factorial absence types with accrual rules documented for manual recreation, and a custom migration field for any Factorial data that lacks a direct BambooHR home. Time-off accrual rules are not migrated as code; we deliver a policy-creation checklist for the BambooHR admin.
Sandbox validation and reconciliation
We run a full migration into a BambooHR test account using production-like data volume. The customer reconciles a sample of 25-50 employee records against Factorial source data, verifies department assignments, spot-checks time-off balance totals, and confirms document attachments. Any mapping corrections are made before production migration begins. BambooHR does not offer a native sandbox, so we use a temporary production environment or a separate test account configured identically to production.
Employee and organizational structure migration
We migrate employees in dependency order: organizational structure first (departments and locations), then employee core records with department and location lookups resolved. Each employee's hire date, employment status, job title, and custom field values transfer. We flag any employee record with missing required BambooHR fields for admin resolution before the next phase begins.
Time-off, compensation, and time entry migration
We transfer absence records as time-off history entries with types and dates preserved. Accrual balances are written as snapshot balances at migration time; BambooHR accrual rules start fresh post-migration. Compensation history migrates as effective-dated entries on each employee's Employment Info tab. Time entries migrate in chronological order with original timestamps, and any project or cost-center tags are stored in a custom field. Large time-entry archives are batched and reconciled by employee and date range.
Document transfer and cutover
We transfer documents per employee via individual API retrieval and upload. Document-heavy archives are processed in batches with reconciliation by employee to catch any missing files. We deliver a document index mapping each Factorial file to its BambooHR location. We then freeze Factorial write access during cutover, run a final delta migration of any records modified during the migration window, and enable BambooHR as the system of record.
Validation, handoff, and workflow rebuild map
We run a final reconciliation comparing total employee count, department assignments, time-off balance totals, and document file count between Factorial and BambooHR. We deliver the workflow and approval chain inventory to the customer admin for rebuild in BambooHR's custom approval configuration. We provide a one-week hypercare window for any record-level issues raised during the first days of BambooHR production use. Post-migration admin training, workflow rebuild, and third-party payroll integration setup are outside standard scope and are handled as separate engagements.
Platform deep dives
Factorial
Source
Strengths
Weaknesses
BambooHR
Destination
Strengths
Weaknesses
Complexity grading
Standard HRMS migration. All 7 core objects map 1:1 between Factorial and BambooHR.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Factorial and BambooHR.
Object compatibility
All 7 core objects map 1:1 between Factorial and BambooHR.
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
Factorial: 200 requests per minute for POST requests per Factorial's published API docs. GET-side limits are not separately enumerated; we tune extraction concurrency conservatively against the customer's tenant during scoping..
Data volume sensitivity
Factorial 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 Factorial to BambooHR migration scoping. Not seeing yours? Book a call.
Walk through your Factorial 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 Factorial
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.