Migrate from ZingHR to BambooHR

ZingHR employee records exported via the Reports module map to BambooHR employee profiles. We extract personal details (name, date of birth, gender, marital status), contact information (email, phone, address), employment history (hire date, termination date, employment status), job title, department, location, and reporting manager. ZingHR's employment status and employee type map to BambooHR's status field and pay type. The migration dedupes by employee email as the primary key. Terminated employees migrate with their termination date and status set toInactive in BambooHR.

ZingHR department hierarchies and cost center structures export as a standard organization report. We map each ZingHR department to a BambooHR department using the department name as the dedupe key. BambooHR departments are flat (no sub-department nesting by default), so nested ZingHR hierarchies are flattened to the lowest level with the parent path preserved as a custom field department_path__c for reporting.

ZingHR location data includes name, address, and geo-coordinates. BambooHR locations store name, address, and state/province. We extract location names and address components from ZingHR and map them to BambooHR location records. Geo-coordinates and location-specific configurations (where present) are stored as custom fields location_latitude__c and location_longitude__c since BambooHR does not natively store geographic coordinates.

ZingHR stores raw punch-in/punch-out timestamps per employee per day. We aggregate daily attendance summaries (total hours worked, overtime, first punch-in, last punch-out) to avoid inflating record counts in BambooHR, which does not natively store raw attendance timestamps. Daily attendance summaries are stored in a custom table or as time-off entries for days marked as absent. Any unpaid leave or absence detected from attendance gaps is flagged for leave balance verification.

ZingHR leave types (earned leave, sick leave, casual leave, compensatory off, maternity leave, paternity leave) map to BambooHR time-off policies. Each ZingHR leave type becomes a separate BambooHR time-off type (Pro and Elite allow multiple types; Core uses a single PTO policy). Current entitlement, accrued, used, and pending balances migrate as the opening balance for each time-off type on the employee's start date in BambooHR. Compensatory off balances require explicit verification in ZingHR before migration cut-off due to reported refresh issues in the source system.

ZingHR payslip data (earnings, deductions, net pay per pay period) exports per pay period but does not have a direct BambooHR equivalent since BambooHR does not include native payroll. We migrate payroll history as a custom field block on each employee record: last_salary__c (most recent gross), last_pay_date__c, last_pay_period__c, and a payslip_count__c indicating total pay periods on record. Full payslip PDF files (where stored in ZingHR ESS) are migrated as BambooHR employee documents attached to the employee file.

ZingHR PMS module goals, goal progress, ratings, and reviewer comments are extracted as structured records. Since BambooHR Performance Management is an Elite add-on, we migrate performance data as custom fields on the employee record: last_review_date__c, last_rating__c, last_reviewer__c, and goal_summary__c (text). Where structured goal data exists in ZingHR, we export it as a PDF report and attach it to the employee file in BambooHR under the Documents tab.

ZingHR manager-employee associations export as reporting lines. We map each employee's manager in ZingHR to the supervisorId field on the corresponding BambooHR employee. The Manager Hierarchy is the object most affected by Maker-Checker pending states: if a manager change is pending approval in ZingHR, we migrate the current approved hierarchy and flag the pending change as a BambooHR approval workflow task for the customer's admin to process post-migration.

ZingHR's Attribute Master API exposes company-specific custom attributes and units defined by the customer. We enumerate all custom fields during scoping, map each to a BambooHR custom field with the matching type (text, number, date, dropdown, checkbox, etc.), and create picklist values where ZingHR uses enumerated options. Custom field names are preserved as the field label with API-safe names generated (lowercase, underscores). BambooHR's documented limitation that custom fields do not sync with integrations is noted and communicated to the customer during scoping.

ZingHR employee documents (offer letters, ID proofs, experience letters, certificates) stored in the ESS are mapped to BambooHR employee documents by category. We extract documents by type, upload them to the corresponding BambooHR employee file under the appropriate document category (Offer Letter, ID Document, Employment Certificate, etc.). Document upload preserves the original filename and attaches it to the correct employee record in BambooHR.

ZingHR Talent Acquisition records including active job postings, candidate profiles, and onboarding checklist progress are extracted as structured data. If the customer licenses BambooHR ATS post-migration, candidate data migrates to the BambooHR applicant model (Job and Applicant objects). If BambooHR ATS is not licensed, we export candidate and job data as a structured CSV report for the customer's admin to use in their chosen ATS, and we flag that active onboarding task lists require manual recreation in BambooHR's onboarding module.