Migrate from CIPHR to Crelate

CIPHR employee records map to Crelate Contacts. We extract first name, last name, email address, phone number, job title, department, employment type, start date, and manager relationship. Crelate's Contact requires the Name field; CIPHR's first name and last name are concatenated at import time. Custom CIPHR employee properties (for example, NI number stored as a custom field) are mapped to Crelate custom fields of the equivalent type — short answer, numeric, or picklist — with the customer's chosen field name in Crelate. Active employees migrate as Contacts; leavers are migrated with a Contact status value that Crelate supports.

CIPHR organisations and department hierarchy map to Crelate Companies. The org structure (departments, cost centres, locations) migrates as Company records with the department name as Company Name and parent-child relationships preserved via Crelate's parent_company lookup if the customer's Crelate configuration supports it. CIPHR cost centre codes map to a Crelate custom text field on the Company record. Location and address data from CIPHR transfers to the Company address fields in Crelate.

CIPHR candidate records from the recruitment module map to Crelate Contacts with candidate-specific fields. We extract candidate name, email, phone, source channel, vacancy applied to, application status, and any custom candidate properties. CIPHR custom stages or workflow statuses are preserved as a text value in a custom field since Crelate's pipeline stages are configured separately. The vacancy reference from CIPHR links to the corresponding Job record in Crelate.

CIPHR vacancy records map to Crelate Job records. Job Name is a required field in the Crelate API and maps from the CIPHR vacancy title. Job description, location, employment type, salary range, and opening date transfer to corresponding Crelate Job fields or custom fields. If the CIPHR vacancy has multiple hiring managers assigned, the primary owner maps to Crelate's Assigned Recruiter field; additional managers are stored in a custom field or noted in the activity log for manual assignment post-migration.

CIPHR call engagements map to Crelate Task records with TaskSubtype = Call. We resolve the parent Contact reference from the candidate or employee record mapped in step 3 or step 1, then set TaskWhoId to the Crelate Contact ID. Call duration, disposition, and any notes stored in CIPHR transfer to custom Crelate Task fields. Activity date is preserved by setting the Task due date to the original CIPHR engagement timestamp.

CIPHR email engagements migrate to Crelate as Activity records of the email type. The email subject, body content, sender, and recipient transfer to the corresponding Crelate activity fields. We resolve the recipient and sender as Contact lookups in Crelate using email address as the dedupe key. If the recipient Contact does not yet exist in Crelate at migration time, the email activity is held in a staging queue and resolved when the Contact record is created during the employee or candidate import phase.

CIPHR meeting engagements map to Crelate Activity records of meeting type. Meeting title, scheduled date, duration, location, and attendee list transfer to Crelate's activity fields. Each attendee in the CIPHR meeting record is resolved to a Crelate Contact by email lookup, and the attendee relationship is created as a linked record in Crelate's activity data structure. Notes or agenda content from the CIPHR meeting are stored in the activity description field.

CIPHR note engagements map to Crelate Note records. Note body migrates as text content. The note is linked to the parent Contact (candidate or employee) via Crelate's entity relationship using the Contact ID resolved from the original CIPHR record. If the CIPHR note has any file attachments, the attachment filenames are stored as a text list in a Crelate custom field with a note that the attachments require retrieval from CIPHR's document storage separately.

CIPHR task engagements map to Crelate Task records. Task body is a required field in the Crelate API; if the CIPHR task has no body text, we set a default value using the task type and date. Task status, priority, due date, and assigned owner transfer directly. The assigned owner resolves to a Crelate User by email lookup via the owner reconciliation step. Tasks with no resolvable owner are placed in a queue for the customer's admin to assign post-migration.

CIPHR onboarding tasks, document checklist statuses, and completion records do not have a direct Crelate object equivalent because Crelate is an ATS not an onboarding platform. Completed onboarding tasks are migrated as Crelate Activity records of type Note attached to the employee Contact, with the task name as the activity subject and the completion date as the timestamp. Document acceptance records are stored as a structured text custom field on the Contact listing the document name and accepted date. Any custom onboarding templates from CIPHR are documented in a separate written inventory for the customer's admin to rebuild in Crelate's workflow builder or document management tools post-migration.

CIPHR custom employee and candidate properties map to Crelate custom fields of the closest matching type. Short text properties map to Crelate Short Answer fields, long text to Long Answer, dates to Date fields, numeric values to Numeric fields, and picklist-based properties to Crelate Picklist fields. We create each custom field in Crelate before migration begins, using the CIPHR property name as the display label and a sanitised version of the name as the API field name. The customer reviews and approves the custom field list during scoping before data import starts.

CIPHR payroll module data — pay histories, deductions, tax codes, pension contributions, RTI submission records — has no native object in Crelate's ATS schema. Historical payroll data is not migrated into Crelate. We recommend coordinating the payroll migration separately with a UK payroll provider (Sage, IRIS, BreatheHR, or Personio) that supports RTI/FPS import from HMRC-held records. Year-to-date pay figures can be stored as a structured text custom field on the employee Contact record in Crelate for reference only, but this is not a payroll solution and does not replace a dedicated payroll system for ongoing PAYE compliance.

CIPHR absence and leave balances, accrual histories, and leave type configurations do not map to Crelate. Crelate has no absence management module. The opening balance of annual leave and any active sickness absence records can be recorded as text custom fields on the employee Contact in Crelate, but the leave accrual calculation logic does not transfer. We recommend using a dedicated absence management tool (BreatheHR, Personio, HRnest) to replace this CIPHR module, or retaining CIPHR solely for absence tracking if the team chooses to run CIPHR and Crelate in parallel for different functions.

CIPHR LMS course assignments, completion dates, quiz results, and learning history have no native Crelate equivalent. We can migrate the most recent training completions as Crelate Activity records of type Note attached to the employee Contact, with the course name, completion date, and pass status stored in the activity description. CIPHR's off-the-shelf content library references do not transfer to any Crelate object. If the organisation relies on CIPHR's LMS for mandatory compliance training tracking, a dedicated LMS replacement (Go1, Totara, TalentLMS) should be provisioned before the Crelate go-live date.

CIPHR employee documents — contracts, policies, ID records, offer letters — store as document metadata and file content in CIPHR. Crelate has no native document management module equivalent to CIPHR's document store. We export document metadata (filename, document type, upload date, associated employee) and store it as structured text in Crelate custom fields on the Contact record. The actual document files require retrieval from CIPHR's export separately; we include the document filenames and retrieval instructions in the migration handoff documentation. For GDPR compliance, the customer's admin reviews document retention against the six-year HMRC requirement before export.

CIPHR flexible benefits enrolments, benefit plan names, and contribution amounts have no Crelate object equivalent. We document benefit plan names and active enrolments as structured text in Crelate custom fields on the employee Contact record for reference purposes only. A dedicated benefits administration platform (PeopleHum, Employee Benefits Hub, or the customer's chosen benefits broker system) should be configured to replace this CIPHR module. Crelate is not a benefits administration platform and does not offer open enrolment tracking or benefit plan management features.

CIPHR appraisal cycle records, ratings, and 360 feedback submissions do not migrate to any Crelate object. We document completed appraisal records as Crelate Activity records of type Note attached to the employee Contact, capturing the appraisal period, overall rating, and key comments as structured text. Custom appraisal templates from CIPHR are inventoried in the migration handoff documentation for the customer's admin to rebuild in Crelate's form builder or a dedicated performance management tool. No rating data is lost in the sense that it is documented, but it is not transferred as structured performance management records.

CIPHR expenses module data is not supported for migration. This limitation is documented in CIPHR's own FlitStack AI platform page and applies to all migration destinations, not specifically to Crelate. Expense records, receipt attachments, and expense category data cannot be extracted from CIPHR in a format suitable for Crelate import, and Crelate has no native expenses module. If the organisation requires expense management post-migration, a standalone expense tool (Expensify, PFC, Concur) should be evaluated separately. Expense history in CIPHR should be archived for HMRC record retention purposes before the CIPHR contract ends.