Migrate from Built to BambooHR

Built Employee records map directly to BambooHR Employee records. Name fields (first, last, preferred name), title, employment type, start date, and employee ID migrate as typed fields. We extract the full ADP-sourced field configuration from Built's Imports section during schema discovery and explicitly map any preferred name field that was enabled there. BambooHR's standard Employee Fields page is configured before migration to match the field set being imported.

Built stores the reporting manager as an Employee-to-Employee relationship rather than a standalone manager field. BambooHR references managers through the supervisor field on the Employee record, which points to another Employee record by internal ID. We perform a two-pass import: first loading all Employee base records without manager references, then resolving manager IDs using the destination-assigned Employee IDs and writing the supervisor relationship in the second pass. Circular manager assignments are detected and flagged before the second pass to prevent impossible hierarchies.

Built Department records map cleanly to BambooHR Departments. We preserve the department name, department code if present, and the head-of-department relationship where Built surfaces that as a field or as a manager assignment. Department records are imported before Employee records so that the department reference is satisfied at the moment of Employee insert.

Built Location records represent office sites or remote-work designations. Field naming and structure vary significantly between HRMS platforms. We review the source location schema during discovery, map Built location names to BambooHR Locations, and flag any multi-field address data that needs to be flattened or split to match BambooHR's location field structure. Remote-work designation fields are mapped to a BambooHR location named 'Remote' or equivalent if no specific remote designation field exists.

Job title is stored as a field on the Employee record in Built and migrates as a free-text string to BambooHR's Job Title field. No transformation is required unless the destination uses a controlled job title vocabulary, in which case we flag the discrepancy during scoping and the customer decides whether to map to a picklist or keep open text.

Built tracks whether an employee is full-time, part-time, contractor, or temporary. BambooHR uses an Employment Status field with a standard enumeration (Full-Time, Part-Time, Contractor, Intern, etc.). We check the source enumeration values against the destination's standard list during discovery and map or flag any non-matching values. Custom employment type values in Built require a custom field in BambooHR or a mapped value in the standard field.

Built organizations can define custom properties on Employee records, and these are not always visible in the admin UI without browsing individual profiles. We extract the full custom field schema from Built's API at the start of migration, compare it against BambooHR's standard Employee Fields, and pre-create any matching custom fields in BambooHR before import begins. Custom field data types (text, date, dropdown, checkbox) are mapped to their BambooHR equivalents. Note: BambooHR cannot pass custom fields for certain tab sections (Time Off, Benefits, Performance, Onboarding) via its API, per documented integration limitations; we flag any Built custom fields that fall in these sections for manual re-entry or manual configuration post-migration.

Built stores documents and uploaded files against Employee profiles. Attachments are not included in Built's standard API export — this is a documented limitation. We request a separate file-level export from Built support as a parallel workstream, extract files to a folder structure keyed by Employee ID, and re-link them manually in BambooHR if the customer's BambooHR plan supports document attachments on employee records. We do not automate this step because both the export and re-link require manual intervention from Built support and BambooHR admin access respectively.

The visual org chart in Built is a rendering of underlying Employee and manager relationship data, not a separate data object. We do not migrate the visualization. Instead, we ensure the Employee, Department, Location, and manager relationship data is correctly sequenced in BambooHR so that BambooHR's own org chart module renders the hierarchy from the migrated records. We document the original org chart structure in the migration handoff document so the customer's BambooHR admin can visually validate the result after migration.

Built's Position Management and Headcount Planning modules track position-level data (headcount plans, position history, approval workflows) that does not map directly to a single BambooHR object. Employee-level position context (job title, department assignment, employment type) migrates as part of the Employee record. Headcount planning data is not a standard BambooHR object and is documented in the handoff report for the customer to evaluate against BambooHR's Advanced Analytics or a third-party headcount planning tool.