Migrate from HR-ON to Crelate

HR-ON Employee records map to Crelate Candidate records. We extract firstName, lastName, dateOfBirth, and contact fields directly. HR-ON systemFields that contain organizational metadata (department, manager, location) map to Candidate custom fields because Crelate stores candidate-specific organizational preferences in custom fields rather than in a separate org chart. Language preference (da_DK or en_US) from HR-ON carries into Crelate's candidate language field. We flag any Employee with a startDate in the future as a recruiting-stage candidate rather than an active hire to preserve the pipeline distinction.

HR-ON embeds org metadata (department, reporting manager, cost center, employment type) inside systemFields on Employee records rather than as separate objects. We parse these key-value pairs during extraction, create matching custom fields on the Crelate Candidate object, and populate them during import. The customer reviews the custom field schema before deployment to ensure naming aligns with their Crelate data governance standards.

HR-ON Document Templates (with fields name, description, documentType, dateFormat, and language) map to Crelate as candidate attachments with a custom field storing the source HR-ON template reference. Crelate does not have a native document template library for employee documents, so we preserve the template metadata in a custom text field on the attachment so the customer's admin can relink or recreate templates post-migration. Language variants from HR-ON (da_DK, en_US) attach as metadata on each document.

HR-ON generates documents from templates and stores them with dateFormat and language metadata. We export these as binary blobs or PDF links and associate them with the relevant Candidate record in Crelate via the CandidateAttachments endpoint. We preserve the original document name, creation date, and language variant. Documents without a corresponding Candidate (orphaned records where the employee was deleted in HR-ON) are archived separately and flagged for manual review.

HR-ON custom properties on Employees map to Crelate Candidate custom fields. We extract all non-systemField properties during scoping, validate each against Crelate's supported field types (text, number, date, picklist, checkbox, multi-select), and flag any with incompatible types—for example, HR-ON multi-select checkboxes that have no direct Crelate equivalent require either a custom text field or a delimited picklist. We pre-create the destination schema in a Crelate sandbox before migration begins.

HR-ON user accounts map to Crelate Users. We match by email address and map HR-ON roles to Crelate's permission structure. HR-ON-specific permissions that have no Crelate equivalent (such as Danish payroll configuration access) are flagged as a manual configuration item for the customer's admin. Inactive HR-ON users map to inactive Crelate users pending admin reactivation decisions.

HR-ON stores dates in four distinct formats: DD-MM-YYYY, DD/MM/YYYY, YYYY-MM-DD, and written form (July 20, 2021). We normalize all date values to ISO 8601 during extraction and validate each normalized date against Crelate's date field requirements before loading. Birth dates, start dates, and document creation dates are processed separately to ensure each date type maps to the correct Crelate field. Any unparseable dates are logged and set to a null value pending manual correction.

HR-ON stores language at da_DK (Danish) and en_US (English) per template and employee. We carry this through to Crelate's candidate language field, preserving the locale value so that any downstream communication templates render in the correct language. If the customer plans to use Crelate's email sequencing, the language preference informs which email template variant is sent.

HR-ON stores employment type (full-time, part-time, contractor, intern) in systemFields on Employee records. We map this to a Candidate custom field during migration. For organizations that also plan to use Crelate's placement or contracting workflows, the employment type maps to the Crelate placement type so that temp-to-perm or contract placements carry the correct classification.

HR-ON embeds onboarding workflow stages in systemFields on Employee records. These stages have no direct Crelate equivalent because Crelate models recruiting pipelines rather than HR onboarding workflows. We migrate the last-known onboarding stage as a static custom field value on the Candidate record, flagging it as a historical marker rather than an active workflow state. The customer's admin rebuilds any active onboarding tracking in Crelate's task and pipeline tools post-migration.

If HR-ON stores benefits enrollment information in custom fields on Employee records, we migrate these as read-only custom fields on the Crelate Candidate. Crelate has no native benefits management module, so benefits data is preserved for reference only and the customer's HR admin handles benefits administration separately from the recruiting CRM.

HR-ON stores organizational hierarchy within systemFields on Employee records rather than as a separate structure. We flatten this into a department custom field on the Crelate Candidate record. If the customer requires a Crelate departmental structure for reporting, we can create a Department custom object and populate it with the extracted hierarchy, but this requires Crelate's Business Plus or Enterprise tier and is scoped as an optional configuration item during discovery.