Migrate from Rippling to Crelate

Rippling Workers map to Crelate Contacts when the Worker represents a candidate, former employee, or recruiting-related person record. The mapping excludes EOR employee records (which carry jurisdiction-specific compliance data not applicable to Crelate's recruiting scope) and IT-managed device users who are not recruiting contacts. We extract the worker's legal name, email, phone, job title, department, work location, and hire date as Contact fields. Termination date, if present, maps to a Crelate custom field rather than a native field because Crelate does not have a native employment-status field for contacts.

Rippling Job records (titles, levels, compensation bands) map to Crelate Job Requisitions when the use case is internal hiring, or to Opportunities when the use case is a staffing or agency engagement. The job title maps to the Job Name or Opportunity Name field, the compensation band maps to a custom Crelate field, and the department assignment maps to a Crelate custom field or tag. We flag whether the Rippling Job is tied to an open headcount versus a historical/closed role to set the Job status in Crelate appropriately.

Rippling Department hierarchies map to Crelate Tags or a custom Department field on Contact and Job records. Crelate does not have a native hierarchical department object, so we flatten the Rippling department tree into a dot-notation string (e.g., Engineering.Backend.Senior) or as separate Tags that the customer selects during scoping. Parent-child department relationships are preserved as separate Tags if the customer requires the full hierarchy for reporting.

Rippling Work Locations (address, type, jurisdiction flags) map to custom address fields in Crelate. Legal entity work locations are flagged separately in a custom field because they carry compliance-relevant data that Crelate does not natively interpret. Actual work site addresses (remote, hybrid, on-site) migrate to the Contact or Job record as location context for recruiting purposes.

Rippling's effective-dated employment changes (title changes, compensation changes, transfers) are recorded as Crelate Activity records on the Contact with timestamps and descriptions. Crelate's activity log serves as the audit trail for employment history without requiring a native effective-dated data model. We sequence changes chronologically and flag the most recent title and department as primary Contact fields, with historical changes preserved as activities.

Rippling pay rates, salary, bonuses, and equity information migrate as Crelate custom fields on the Contact or Job record. Crelate does not have a native compensation object, so compensation data is stored as numeric custom fields. We flag custom compensation structures (commission-heavy roles, CA/NY-specific pay rules) as requiring manual verification post-migration because Crelate does not enforce pay compliance logic. Historical payroll runs and W-2 data do not migrate to Crelate; we export those separately for the customer's records.

PTO balance snapshots are time-sensitive and depend on Rippling's accrual engine, which has no equivalent in Crelate. We do not migrate PTO balances to Crelate because Crelate does not have a PTO accrual or balance tracking module. We extract the final PTO balance snapshot at cutover date as a separate export for the customer's records, and flag that Crelate requires a third-party PTO tool or manual spreadsheet for ongoing accrual tracking post-migration.

Benefit plan assignments, carrier details, and FSA/HSA balances at cutover date do not map into Crelate's schema. Crelate has no benefits administration module. We export benefits enrollment records as a static file at cutover and recommend the customer maintain benefits records in a dedicated HRIS or manually in their new payroll provider's system. Active claim histories and FSA/HSA balances are out of scope for Crelate entirely.

Rippling Custom Objects (certifications, equipment assignments, business-unit-specific fields) migrate as Crelate custom fields on the appropriate Core Record (Contact, Company, or Opportunity). We export the Rippling Custom Object field definitions (API names, data types, required flags) during discovery, then create matching Crelate custom fields with equivalent types (Text, Number, Date, Dropdown). Multi-select and checkbox fields map to Crelate multi-select or checkbox fields. We validate the field count against Crelate's per-plan limits (10 Advanced Custom Fields on Business, higher limits on Business Plus).

Rippling employee documents (offer letters, contracts, tax forms) migrate as file metadata and links to the Crelate Contact record. Actual file content migration depends on whether Rippling's file storage is accessible via API. We export document metadata (filename, type, upload date, associated worker) and attach it as a Crelate Activity or file link on the Contact. If Rippling file access is restricted, we provide a file inventory spreadsheet with download instructions for the customer's admin to re-upload manually.

Rippling's device inventory and MDM enrollment records are tightly coupled to Rippling's IT stack and do not have a clean export path to Crelate. Crelate is a recruiting platform, not an IT management system. We do not migrate device records. Laptop assignment and MDM status should be offboarded separately through Rippling's offboarding workflows or exported manually as part of the IT offboarding process.

Spend management data — corporate card transactions, expense reports, bill pay records — lives in Rippling's finance module and is out of scope for Crelate. Crelate is a recruiting platform with no expense management module. We do not migrate spend data. If the customer uses Rippling Spend, we recommend they move to a dedicated spend management tool (Ramp, Brex, or similar) separately from the Crelate migration.