HRMS migration
Field-level mapping, validation, and rollback between iTrent and Crelate. We move data and schema; workflows are rebuilt natively in Crelate.
iTrent
Source
Crelate
Destination
Compatibility
9 of 15
objects map 1:1 between iTrent and Crelate.
Complexity
BStandard
Timeline
3-5 weeks
Overview
iTrent consolidates HR, payroll, talent management, and recruiting within a single tenant, while Crelate is a dedicated ATS built for recruiting and staffing workflows. This migration is scoped to iTrent's recruitment module: active Job postings, Candidate profiles, Application records with stage history, Interview Activities with notes and ratings, and Onboarding Tasks. We do not migrate iTrent's payroll, absence, benefits, performance, or core employee data to Crelate because Crelate does not have objects for these HR functions. We flag this scope boundary explicitly during discovery and confirm it with the customer before any extraction begins. Workflows, automations, and approval chains in iTrent are configuration artefacts and do not migrate; we deliver a written inventory of these for the customer's talent team to rebuild in Crelate's pipeline and task configuration.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a iTrent object lands in Crelate, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
iTrent
Vacancy
Crelate
Job
1:1iTrent Vacancy records map directly to Crelate Job records. We extract the job title, job location, employment type (full-time, part-time, contract), salary range fields, job description, and vacancy status. Active vacancies in iTrent are set to Active status in Crelate; closed vacancies default to Crelate's Closed status. Vacancy owner in iTrent maps to the Crelate User assigned as the hiring manager on the Job via email resolution.
iTrent
Candidate
Crelate
Candidate
1:1iTrent candidate profiles map to Crelate Candidate records. We migrate first name, last name, primary email, primary phone, current job title, current employer, notice period, right-to-work status, and source attribution. iTrent qualifications and education details migrate to custom Crelate fields on the Candidate record. Application date from iTrent is preserved as a custom field since Crelate derives application date from the Application-to-Candidate relationship.
iTrent
Application
Crelate
Application
1:1Each iTrent Application record maps to a Crelate Application record linked to the corresponding Crelate Candidate and Job. We create a custom Crelate field itrent_application_stage__c to preserve the full stage history (Received, Screening, Interview, Assessment, Offer, etc.) because Crelate's native candidate status model uses Active, Hired, Rejected, and Withdrawn values that do not capture the same granularity. The current active stage migrates as the primary Application status value.
iTrent
Interview
Crelate
Activity (Interview)
1:1iTrent interview records with round identifiers, assigned interviewers, structured ratings, scheduling details, notes, and duration map to Crelate Activity records. We create a custom Crelate field interview_type__c to distinguish between screening, technical, panel, and final rounds. Each interviewer from iTrent is mapped to a Crelate User or Contact via email resolution. Interview duration, scheduling timestamp, and location migrate to corresponding Crelate Activity fields. Ratings migrate to custom Crelate rating fields on the Activity.
iTrent
Onboarding Task
Crelate
Task
1:1iTrent onboarding task list items map to Crelate Task records. Each onboarding step becomes a discrete Task linked to the Crelate Candidate and the associated Job. We preserve the task name, due date, assigned user (resolved by email), completion status, and any task description or instructions. Completed tasks retain their historical status; in-progress tasks are flagged for the customer's talent team to action post-migration. Task ordering is preserved by setting a custom sort_order field on each migrated Task.
iTrent
Application Stage
Crelate
Pipeline Stage
lossyiTrent's application stage configuration (Received, Screening, Interview, Assessment, Offer, Hired, Rejected, Withdrawn) maps to Crelate pipeline stages. We configure each Crelate Pipeline Stage with the correct ordering, default status, and probability weight matching the iTrent stage definitions. Stages with no Crelate equivalent are mapped to the nearest Crelate status and flagged in the mapping document for the customer's review.
iTrent
Talent Pool
Crelate
Tag
lossyiTrent talent pool and shortlist assignments are stored as list attributes on the candidate record. These are not standalone objects in Crelate, so we migrate talent pool names as Tags on the Candidate record in Crelate. This preserves the candidate's talent pool classification without requiring the customer to recreate lists manually. Tags are created in Crelate during the configuration phase and assigned to Candidates during migration based on the iTrent talent pool field value.
iTrent
User / Owner
Crelate
User
1:1iTrent users referenced on Vacancy, Candidate, Application, and Interview records map to Crelate Users by email address. We resolve each distinct owner email from iTrent against the Crelate User table. Owners without a matching Crelate User are placed in a reconciliation queue, and the customer's Crelate admin provisions the corresponding Users before the production migration phase begins. Active and inactive status is preserved.
iTrent
Interview Note
Crelate
Note
1:1iTrent interview notes and free-text evaluation comments attached to interview records map to Crelate Notes linked to the corresponding Candidate record. We preserve the note body, creation timestamp, and author (resolved via email to Crelate User or Contact). If iTrent stores notes with attachments, the attachment URLs or file metadata are preserved in a custom Crelate field for manual re-attachment in Crelate's document management.
iTrent
Hiring Manager (vacancy contact)
Crelate
Contact
1:1iTrent stores the hiring manager as a contact on the vacancy record. We migrate the hiring manager contact to a Crelate Contact record with a custom role field set to Hiring Manager. We then link this Contact to the corresponding Crelate Job via a custom field hiring_manager__c to preserve the relationship. If the hiring manager is also a Crelate User, the Contact is associated to the User record by email.
iTrent
Recruitment Source
Crelate
Custom Field (picklist)
lossyiTrent captures candidate source (Employee Referral, LinkedIn, Job Board, Agency, Direct, etc.) as a field on the candidate record. Crelate's native source field is a simple text or picklist field. We create a structured picklist in Crelate matching the iTrent source values during the configuration phase and map source values during migration. Any iTrent source values not in the Crelate picklist are flagged for the customer to confirm before migration.
iTrent
Background Check
Crelate
Custom Field
lossyBackground check status and outcome data stored in iTrent's recruitment module maps to custom fields on the Crelate Candidate record (bg_check_status__c, bg_check_completed_date__c, bg_check_provider__c). Crelate does not have a native background check object. We preserve the status, date, and provider as structured custom fields. The actual background check document file is noted in a custom field for manual upload in Crelate if required.
iTrent
Offer Letter
Crelate
Custom Field
1:1iTrent offer letter records include offer status, proposed salary, start date, and benefits summary. We migrate the offer status and key terms to custom fields on the Crelate Candidate record (offer_status__c, offered_salary__c, proposed_start_date__c). The offer letter document URL is preserved in a custom field. Crelate does not have a native offer management object; the customer may choose to use Crelate's document attachment or a dedicated offer management tool post-migration.
iTrent
Assessment Score
Crelate
Custom Field
lossyAssessment results stored in iTrent as part of the application or interview process migrate to custom fields on the Crelate Application or Candidate record. We map skill assessment scores, psychometric results, and test completion status to named custom fields matching the iTrent field labels. The assessment instrument name and test date are preserved alongside the score value.
iTrent
Candidate Tag / Keyword
Crelate
Tag
lossyiTrent stores candidate tags and keyword flags as multi-select attributes on the candidate record. These map to Crelate Tags on the Candidate record. We extract all distinct tag values from iTrent, create corresponding Tags in Crelate during the configuration phase, and assign them to the migrated Candidate records. Tag preservation enables the customer's talent team to run filtered searches in Crelate immediately after migration without manual re-tagging.
| iTrent | Crelate | Compatibility | |
|---|---|---|---|
| Vacancy | Job1:1 | Fully supported | |
| Candidate | Candidate1:1 | Fully supported | |
| Application | Application1:1 | Fully supported | |
| Interview | Activity (Interview)1:1 | Fully supported | |
| Onboarding Task | Task1:1 | Fully supported | |
| Application Stage | Pipeline Stagelossy | Fully supported | |
| Talent Pool | Taglossy | Fully supported | |
| User / Owner | User1:1 | Fully supported | |
| Interview Note | Note1:1 | Fully supported | |
| Hiring Manager (vacancy contact) | Contact1:1 | Fully supported | |
| Recruitment Source | Custom Field (picklist)lossy | Fully supported | |
| Background Check | Custom Fieldlossy | Fully supported | |
| Offer Letter | Custom Field1:1 | Fully supported | |
| Assessment Score | Custom Fieldlossy | Fully supported | |
| Candidate Tag / Keyword | Taglossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
iTrent gotchas
Pay period cycle boundary alignment
Custom field proliferation and schema variance
Limited public API and export tooling
ESS salary breakdown configuration dependency
Workflow definitions not stored as data
Crelate gotchas
120 req/min API rate limit throttles bulk migrations
20 custom field per-entity cap forces data model decisions
15,000-record export ceiling on single operations
Sequences and automation workflows do not migrate
API key is a querystring parameter, not a header
Pair-specific challenges
Migration approach
Discovery and data audit
We conduct scoping sessions with the customer's iTrent administrator to map the iTrent recruitment schema against Crelate's object model. We identify all custom fields on Vacancy, Candidate, Application, Interview, and Onboarding Task records; enumerate pipeline stage values; count distinct users and hiring managers; and estimate record volumes for each object. We also run a data quality audit to surface duplicate candidates, records with missing required fields, and inactive vacancies that should not migrate. The discovery output is a written migration scope document and a Crelate configuration checklist agreed with the customer.
Crelate configuration design
We design the Crelate destination schema before any data moves. This includes creating all required custom fields (application stage history, interview ratings, onboarding task fields, background check fields, offer terms, assessment scores), configuring pipeline stages to match iTrent's application lifecycle, setting up Tag values matching iTrent talent pools and candidate keyword tags, and configuring user accounts for all migrating owners. The configuration is validated in a Crelate sandbox or trial environment before production setup begins.
Test migration and staging validation
We perform a full test migration into a Crelate staging environment using production-like data volume. The customer's talent operations lead reviews migrated records, validates field mapping accuracy on a random sample of 30-50 records per object, confirms pipeline stage fidelity in the custom itrent_application_stage__c field, and approves the mapping before production migration is scheduled. Any mapping corrections are applied to the migration scripts and re-tested before proceeding.
Production migration in dependency order
We execute the production migration in record-dependency order: Users first (validated against Crelate user provisioning), then Jobs, Candidates, Applications (with stage mapping applied), Interview Activities, Onboarding Tasks, and Tags. Each phase emits a row-count reconciliation report before the next phase begins. We respect Crelate's 120 rpm API rate limit throughout and use exponential backoff on any 429 responses. Activity and note records are migrated last because they reference Candidate and Job parent records that must exist first.
Delta sync and cutover
We freeze writes to iTrent's recruiting module during the final migration window. Any new applications, candidate updates, or interview activities added since the last extraction are migrated as a delta pass. Once the delta pass confirms zero new records, we complete the migration and the customer's talent team begins using Crelate as the system of record. The original iTrent recruiting data is retained in read-only mode until the customer's retention policy specifies archive or export.
Validation, handoff, and automation rebuild inventory
We deliver a post-migration validation report showing record counts by object, mapping completeness, and any unmapped fields with their iTrent values. We deliver the written inventory of iTrent recruitment workflows, automations, and approval conditions for the customer's talent team to rebuild in Crelate. We provide a one-week hypercare window to resolve any data discrepancies raised by the talent team. We do not rebuild workflows or automations in Crelate as part of the standard migration scope; that work is handled by the customer's admin team or a Crelate implementation partner.
Platform deep dives
iTrent
Source
Strengths
Weaknesses
Crelate
Destination
Strengths
Weaknesses
Complexity grading
Standard HRMS migration. 1 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across iTrent and Crelate.
Object compatibility
1 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
iTrent: Not publicly documented.
Data volume sensitivity
iTrent doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during iTrent to Crelate migration scoping. Not seeing yours? Book a call.
Walk through your iTrent to Crelate migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave iTrent
Other ways to arrive at Crelate
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.