HRMS migration

Migrate from iTrent to Crelate

Field-level mapping, validation, and rollback between iTrent and Crelate. We move data and schema; workflows are rebuilt natively in Crelate.

iTrent logo

iTrent

Source

Crelate

Destination

Crelate logo

Compatibility

60%

9 of 15

objects map 1:1 between iTrent and Crelate.

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

iTrent logo

iTrent

What's pushing teams away

  • Customer support response times deteriorate during payroll periods and legislative update windows, leaving HR teams without timely help when they need it most.
  • The breadth of configuration options creates complexity — new users report steep learning curves and inconsistent process adoption across departments.
  • Customers switch to platforms perceived as easier to configure and maintain, citing frustration with getting basic functionality to work as intended.
  • Some organisations report slower system performance during high-volume periods, which directly impacts payroll processing confidence.
  • Negative reviews mention poor communication from MHR and a sense that the product is difficult to work with, prompting exploration of alternatives.

Choosing

Crelate logo

Crelate

What's pulling them in

  • Affordable per-seat pricing with transparent tiers makes Crelate accessible for small-to-mid staffing firms evaluating ATS platforms for the first time.
  • Fast implementation reported by customers—some describe getting live in a matter of minutes with support team assistance.
  • Unified ATS + CRM in a single product eliminates the need to buy and synchronize separate recruiting and sales tools.
  • Flexible custom fields across Contacts, Companies, and Opportunities allow recruiting teams to capture firm-specific data without developer involvement.
  • Positive reviews highlight the product's intuitive interface and functional breadth for teams that need recruiting workflows without enterprise overhead.

Object mapping

How iTrent objects map to Crelate

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

maps to

Crelate

Job

1:1
Fully supported

iTrent 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

maps to

Crelate

Candidate

1:1
Fully supported

iTrent 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

maps to

Crelate

Application

1:1
Fully supported

Each 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

maps to

Crelate

Activity (Interview)

1:1
Fully supported

iTrent 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

maps to

Crelate

Task

1:1
Fully supported

iTrent 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

maps to

Crelate

Pipeline Stage

lossy
Fully supported

iTrent'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

maps to

Crelate

Tag

lossy
Fully supported

iTrent 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

maps to

Crelate

User

1:1
Fully supported

iTrent 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

maps to

Crelate

Note

1:1
Fully supported

iTrent 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)

maps to

Crelate

Contact

1:1
Fully supported

iTrent 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

maps to

Crelate

Custom Field (picklist)

lossy
Fully supported

iTrent 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

maps to

Crelate

Custom Field

lossy
Fully supported

Background 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

maps to

Crelate

Custom Field

1:1
Fully supported

iTrent 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

maps to

Crelate

Custom Field

lossy
Fully supported

Assessment 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

maps to

Crelate

Tag

lossy
Fully supported

iTrent 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.

Gotchas + challenges

What specifically takes care here

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 logo

iTrent gotchas

High

Pay period cycle boundary alignment

High

Custom field proliferation and schema variance

High

Limited public API and export tooling

Medium

ESS salary breakdown configuration dependency

Medium

Workflow definitions not stored as data

Crelate logo

Crelate gotchas

High

120 req/min API rate limit throttles bulk migrations

High

20 custom field per-entity cap forces data model decisions

Medium

15,000-record export ceiling on single operations

Medium

Sequences and automation workflows do not migrate

Low

API key is a querystring parameter, not a header

Pair-specific challenges

  • Crelate API throttles at 120 requests per minute

    Crelate's API v3 ingestion rate is throttled at 120 requests per minute per IP address. For large candidate databases, migration scripts that do not respect this limit will encounter 429 rate-limit responses and stalls. We implement batch chunking, exponential backoff on rate-limit responses, and queue management to keep the migration within the 120 rpm ceiling. We monitor API response headers during migration and dynamically adjust request pacing to avoid throttling while maximising throughput.

  • Application stage fidelity requires custom field preservation

    iTrent's multi-stage application lifecycle (Received, Screening, Interview, Assessment, Offer, Hired, Rejected, Withdrawn) has more granular states than Crelate's native candidate status model, which uses Active, Hired, Rejected, and Withdrawn. We create a custom field itrent_application_stage__c on the Crelate Candidate or Application record to preserve the full iTrent stage history. The current stage value maps to Crelate's native status field. Migrations that do not capture the full stage history lose the candidate's progression record, which is critical for compliance and audit trails in regulated industries.

  • Limited public API requires MHR coordination for iTrent exports

    iTrent does not publish comprehensive public API documentation for self-service data extraction. Bulk exports from iTrent's recruitment module typically require MHR-assisted data extracts rather than programmatic API calls. We coordinate with MHR's technical team to request structured CSV or JSON exports of Vacancies, Candidates, Applications, and related records. This adds lead time to migration planning, and the customer must authorise MHR data sharing before extraction begins. Self-managed migration attempts frequently stall because iTrent's export endpoints are not publicly documented.

  • Workflow and automation logic does not transfer between platforms

    iTrent's conditional approval chains, recruitment workflow rules, and automated routing conditions are platform configuration artefacts, not data records. Crelate's pipeline configuration and task automation operate under a different model. We do not migrate workflow definitions as executable code. We deliver a written inventory of every active iTrent recruitment workflow, automation rule, and approval condition with its trigger logic, conditions, and actions described in plain language. The customer's talent team rebuilds these in Crelate's pipeline stage configuration and task automation tools post-migration.

  • Duplicate and outdated records must be cleaned before migration

    Duplicate candidate records, outdated contact information, and empty fields accumulate in iTrent over time, particularly in organisations where multiple recruiters enter candidate data independently. These data quality issues carry into Crelate if not addressed before migration and create duplicate records, broken candidate profiles, and search-result noise. We run a data audit during the discovery phase, identify duplicate candidates (matched on email, name, and phone), flag records with more than 40 percent empty required fields, and present a deduplication and cleanup plan to the customer before migration begins.

Migration approach

Six steps for a successful iTrent to Crelate data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

iTrent logo

iTrent

Source

Strengths

  • UK-specific payroll compliance with automatic legislative updates for tax and employment law.
  • Integrated HR, payroll, ESS, and analytics in a single tenant without module stitching.
  • Configurable workflow approval chains and conditional routing without developer involvement.
  • Scalable from small businesses to large enterprises with industry-specific configurations.
  • MHR Shield provides security layer aligned with UK data protection standards.

Weaknesses

  • Limited public API documentation restricts automated export approaches and increases migration reliance on MHR-supported exports.
  • Customer support response times degrade during peak payroll periods, which can delay migration support requests.
  • Highly configurable platform means no two tenants share the same schema, requiring extensive scoping per migration.
  • Sparse review volume across G2, Capterra, and Gartner limits independent quality signal for buyers.
  • Performance can degrade during high-volume processing windows, creating risk during live payroll cutover.
Crelate logo

Crelate

Destination

Strengths

  • Unified ATS and CRM in a single platform reduces data synchronization overhead for recruiting teams.
  • Fast setup with guided implementation reported as a significant time saver for small teams.
  • Transparent per-seat pricing without surprise fees at the base tier.
  • Flexible custom field configuration across core objects without developer dependency.
  • Export capability supports up to 15,000 records per operation for Contacts, Companies, and Opportunities.

Weaknesses

  • API rate limit of 120 requests per minute restricts bulk migration throughput.
  • Custom field cap of 20 per entity requires field consolidation for complex recruiting schemas.
  • All advanced features (Activities, Activity Forms, Core Record Field customization) are tier-gated add-ons.
  • Customer service responsiveness receives consistent negative feedback in reviews.
  • Resume parsing quality trails competitors and generates support requests.

Complexity grading

How hard is this migration?

Standard HRMS migration. 1 of 7 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across iTrent and Crelate.

  • Object compatibility

    B

    1 of 7 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    7-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    iTrent: Not publicly documented.

  • Data volume sensitivity

    B

    iTrent doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your iTrent to Crelate migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about iTrent to Crelate data migrations

Answers to the questions buyers ask most during iTrent to Crelate migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your iTrent to Crelate migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Straightforward migrations covering fewer than 5,000 candidates, 500 active jobs, and limited interview history land in three to five weeks. Migrations with extensive interview notes and ratings, multiple pipeline stages, onboarding task lists with hundreds of items, or data quality issues requiring deduplication move to eight to twelve weeks because of the API-rate-limited ingestion, staging validation cycles, and cleanup work. We confirm the timeline estimate during discovery based on actual record volumes.

Adjacent paths

Related migrations to explore

Ready when you are

Move from iTrent.
Land in Crelate, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day