Migrate from Darwinbox to BambooHR

Darwinbox Employee records map directly to BambooHR Employee. The Darwinbox employee ID becomes the BambooHR employeeId used as the dedupe key. Core fields (name, date of birth, hire date, employment status, department, job title, location) export cleanly via API. We preserve the Darwinbox employee ID in a BambooHR custom field darwinbox_id__c for audit traceability. Work phone and mobile migrate as BambooHR work phone and mobile number fields.

Darwinbox stores hierarchical org units, cost centres, and location data as separate objects with parent-child relationships. BambooHR models organisation flatly using Department and Location objects. We flatten the Darwinbox org tree by mapping the deepest-level org unit to BambooHR Department and the location branch to BambooHR Location. Cost-centre assignments migrate as a BambooHR custom field cost_center__c. If the organisation uses multiple hierarchy levels (BU, Division, Team), we map the top two levels to Department naming conventions and document the hierarchy in a delivered org chart spreadsheet.

Darwinbox attendance records use employee ID as the primary key with punch arrays containing timestamps, machine IDs, and in/out status codes. BambooHR's Time Tracking module covers time off requests and basic clock-in/out but does not expose raw punch-log data as a first-class API object. We extract Darwinbox attendance records during the migration window and map approved attendance events to BambooHR Time Off entries (where the absence type matches a BambooHR leave policy) and document raw punch history in a CSV delivered alongside the migration for admin reference. Attendance records requiring shift-policy alignment (weekly-off names, policy names) are resolved in a pre-migration policy mapping step.

Darwinbox stores leave types, accrual rules, and current balances per employee with effective-dating. BambooHR Time Off supports multiple leave policies per employee type. We map Darwinbox leave types to BambooHR leave types (Annual Leave to Vacation, Sick Leave to Sick, etc.) using a leave type mapping table agreed during scoping. Current balances migrate as accrued amounts in BambooHR. Darwinbox's multiple leave policies per org unit require us to identify the applicable policy per employee and map it to the corresponding BambooHR policy. Accrual rules are not migrated as configuration; we document them for the customer's admin to configure in BambooHR.

Darwinbox payroll and compensation history includes salary components, deductions, tax codes, and multiple effective-dated rows per employee (salary changes, promotions). BambooHR does not have a native payroll module in its Core tier and lacks multi-country payroll. We extract effective-dated compensation rows from Darwinbox and map the most recent compensation record to BambooHR Pay Compensation custom fields (current salary, pay frequency, currency). Historical compensation rows are delivered as a CSV with effective dates for admin reference. If BambooHR Payroll is in scope, we coordinate its implementation timeline separately because BambooHR Payroll has its own setup and configuration process that is not part of the data migration.

Darwinbox custom fields are tenant-specific and attached to any object. They are not documented in the public API reference and must be introspected from the tenant's live instance during discovery. We request read access to custom field configurations during scoping, enumerate the complete field registry (names, types, attached objects), and map each custom field to an equivalent BambooHR custom employee field. Text, number, boolean, date, and predefined-list types map directly. Multi-select and complex structured fields require admin decision on whether to flatten, store as text, or split into multiple BambooHR fields.

Darwinbox users carry roles (admin, manager, employee) tied to functional permissions. We extract user-role assignments and map them to BambooHR user accounts with the appropriate permission level. BambooHR uses a simpler role model (Full Access, Manager, Employee) versus Darwinbox's more granular permission matrix. We map Darwinbox admin to BambooHR Full Access, Darwinbox manager to Manager, and Darwinbox employee to Employee, then document any permission gaps for the customer's admin to configure post-migration. Inactive Darwinbox users map to inactive BambooHR users.

Darwinbox employee documents (contracts, IDs, certifications) are stored in its document management module and are not exposed via the public REST API. BambooHR has a document storage module for employee files accessible via API. We cannot migrate document blobs directly. We flag document migration as an out-of-scope step requiring manual handling. Customers must either manually download documents from Darwinbox and re-upload to BambooHR or coordinate a vendor-assisted export from Darwinbox. We document the file naming convention and employee folder structure for the manual migration to follow.

Darwinbox workflow configurations (approval chains, routing rules, conditional logic) are stored as platform logic rather than structured data records and are not exported as objects. BambooHR supports basic workflow rules for approvals but does not have a visual workflow builder equivalent to Darwinbox's no-code workflow engine. We do not migrate workflows as configuration. We deliver a written inventory of every active Darwinbox workflow with its trigger, conditions, actions, and recommended BambooHR equivalent. The customer's admin rebuilds workflows post-migration using BambooHR's approval rules and any third-party automation tools in their stack.

Darwinbox performance modules store review cycles, ratings, goals, and manager feedback tied to employees. BambooHR Performance Review supports review cycles, 360 feedback, and goal tracking. We extract review history including ratings and goal content and map them to BambooHR Performance Review records. Multiple rating systems supported in Darwinbox are mapped to BambooHR's rating scale or stored as a custom field if the scales do not align directly. Active review cycles in progress require admin decision on whether to migrate mid-cycle or restart in BambooHR.