HRMS migration
Field-level mapping, validation, and rollback between gradar and Recruit CRM & ATS. We move data and schema; workflows are rebuilt natively in Recruit CRM & ATS.
gradar
Source
Recruit CRM & ATS
Destination
Compatibility
6 of 10
objects map 1:1 between gradar and Recruit CRM & ATS.
Complexity
BStandard
Timeline
3-5 weeks
Overview
gradar and Recruit CRM serve fundamentally different functions — gradar is a job evaluation and compensation structuring platform that uses a 25-grade point-factor system, while Recruit CRM is a recruitment ATS and CRM built for agencies managing candidates, clients, and placements. There is no direct object-level parity between them. We treat the migration as a scoped data extract from gradar's reporting exports followed by targeted import into Recruit CRM's Jobs and Custom Fields, with compensation-related data (pay bands, grades, career paths, equal pay analysis) documented as gap items rather than migrated records. The migration requires significant preprocessing of gradar's non-standard export formats before Recruit CRM's API can accept the data. We do not migrate evaluation workflows, pay structure rules, or benchmarking datasets as these have no equivalent object in Recruit CRM.
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 gradar object lands in Recruit CRM & ATS, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
gradar
Jobs (Roles)
Recruit CRM & ATS
Job
1:1gradar Job records migrate to Recruit CRM Job. Each Job carries the role title, evaluation date, and total point score from gradar. The job title maps to the Recruit CRM job name field, and the evaluation date maps to a custom field gradar_evaluation_date__c. Total point score maps to a numeric custom field gradar_point_score__c for audit and reporting in Recruit CRM.
gradar
Grade
Recruit CRM & ATS
Custom Field on Job
lossygradar grades (1-25) have no native equivalent in Recruit CRM. We migrate the numeric grade as a custom integer field gradar_grade__c on the Job object, and the grade name (where available from the export) as gradar_grade_name__c text field. This preserves the evaluation result in the destination system even though Recruit CRM does not use grades in its workflow.
gradar
Career Path
Recruit CRM & ATS
Custom Field on Job
lossygradar's three career paths (Management, Specialist, Individual Contributor) have no native Recruit CRM equivalent. We map career path assignment to a custom picklist field gradar_career_path__c on Job. The picklist values are confirmed during scoping against the customer's actual gradar career path configuration.
gradar
Job Description
Recruit CRM & ATS
Description Field on Job
1:1gradar AI-assisted job descriptions migrate as rich text into Recruit CRM's job description field. The full description body transfers intact. If Recruit CRM strips formatting, we preserve the plain text version as a fallback and note the format difference in the reconciliation report.
gradar
Competencies
Recruit CRM & ATS
Custom Fields or Custom Object
1:1gradar competency profiles are structured exports that can be mapped to Recruit CRM custom fields on Job. For organisations with fewer than 20 competencies per role, we use individual custom text or picklist fields (gradar_competency_1__c through gradar_competency_n__c). For larger competency sets, we create a Custom Object in Recruit CRM named gradar_competency and link it to Job via a lookup field, which requires the customer to configure the object via Recruit CRM admin before migration.
gradar
Pay Band / Compensation Structure
Recruit CRM & ATS
Custom Fields on Job or Separate Documentation
lossygradar pay bands (min/mid/max per grade) have no native Recruit CRM object. We migrate pay band data as custom numeric fields on Job: gradar_pay_band_min__c, gradar_pay_band_mid__c, gradar_pay_band_max__c. Currency assignment requires explicit confirmation during scoping because gradar's export does not consistently tag currency per row. Where currency is ambiguous, we flag the record and document the gap rather than migrate with an assumed currency.
gradar
Grade Factor Scores
Recruit CRM & ATS
Custom Fields on Job
lossyIndividual factor-level point scores from gradar evaluation exports migrate as custom numeric fields (gradar_factor_score_1__c through gradar_factor_score_n__c) on the Job record. The factor count depends on the customer's gradar configuration. We confirm the exact factor names and count during scoping and create fields dynamically for each migration.
gradar
Users
Recruit CRM & ATS
User
1:1gradar user accounts and their access levels migrate as User records in Recruit CRM. We match by email address. gradar permission groups have no direct Recruit CRM role model equivalent, so we flag the access level assignments in the migration documentation for the customer's Recruit CRM admin to reconfigure manually post-migration.
gradar
Benchmarking Data
Recruit CRM & ATS
Documentation Only
1:1gradar market benchmarking datasets have no equivalent object in Recruit CRM. We export the benchmarking records, identify the linked Job in Recruit CRM post-migration, and deliver the benchmark values as a written dataset inventory alongside the migration. The customer's admin decides how to surface this data — whether as notes, a separate spreadsheet, or a custom reporting setup.
gradar
Equal Pay Analysis
Recruit CRM & ATS
Documentation Only
1:1gradar's gender pay gap regression analysis outputs are datasets, not system configuration. These do not map to any Recruit CRM object. We export the analysis results and deliver them as a structured dataset with job references for the customer to maintain externally. The audit trail from gradar's equal pay analysis cannot be preserved inside Recruit CRM without a separate reporting or analytics tool.
| gradar | Recruit CRM & ATS | Compatibility | |
|---|---|---|---|
| Jobs (Roles) | Job1:1 | Fully supported | |
| Grade | Custom Field on Joblossy | Fully supported | |
| Career Path | Custom Field on Joblossy | Fully supported | |
| Job Description | Description Field on Job1:1 | Fully supported | |
| Competencies | Custom Fields or Custom Object1:1 | Mapping required | |
| Pay Band / Compensation Structure | Custom Fields on Job or Separate Documentationlossy | Fully supported | |
| Grade Factor Scores | Custom Fields on Joblossy | Mapping required | |
| Users | User1:1 | Fully supported | |
| Benchmarking Data | Documentation Only1:1 | Mapping required | |
| Equal Pay Analysis | Documentation Only1:1 | Mapping required |
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.
gradar gotchas
No public API forces reliance on manual exports
Evaluation history and grade change records require explicit extraction
Pay band data uses multiple currencies in multinational deployments
Recruit CRM & ATS gotchas
API rate limits are license-scaled and can throttle bulk migration
Custom field schemas vary per organization and require field-level mapping
Files and email attachments require separate extraction and re-upload
Email sequences and automation logic do not transfer between platforms
Pair-specific challenges
Migration approach
Scoping and export coordination
We audit the gradar configuration to identify all required exports: Job list with titles and IDs, Grade assignments, Career Path assignments, Job Descriptions, Competency profiles, Pay Band definitions, Grade Factor Scores, and User accounts. Because gradar has no API, a gradar user initiates each export manually. We provide a written export checklist and support the customer through each download, confirming field completeness and format before the migration team receives the data.
Export preprocessing and data normalisation
We convert gradar's non-standard export formats into structured JSON ready for Recruit CRM's API. This includes parsing nested evaluation records, flattening competency arrays, normalising date formats to ISO 8601, and encoding grade factor scores into named custom fields. Currency-confirmed pay band values are isolated in this phase. Any records with missing required fields are flagged and returned to the customer for confirmation before they enter the migration pipeline.
Recruit CRM schema extension
We create the custom fields required in Recruit CRM: gradar_grade__c, gradar_grade_name__c, gradar_career_path__c, gradar_point_score__c, gradar_evaluation_date__c, and pay band fields (gradar_pay_band_min__c, gradar_pay_band_mid__c, gradar_pay_band_max__c). If the customer has more than 20 competency fields per role, we provision a custom object gradar_competency with a lookup to Job. All schema additions are deployed via Recruit CRM admin tools before data import begins.
Job and role data migration
We migrate Job records via the Recruit CRM API, inserting job titles, descriptions, and custom field values in dependency order. Job records are created first because other objects (Competencies, Pay Bands) may have lookups referencing them. We use batch inserts with rate-limit handling and exponential backoff. Each batch emits a row-count reconciliation report.
Compensation and evaluation data migration
Grade, Career Path, Point Score, and Pay Band data are migrated as custom fields on the corresponding Job records after the core job data has validated successfully. Grade Factor Scores are added as additional custom fields per factor identified in the gradar export. Compensation data migrations receive a separate reconciliation pass because currency and pay band completeness require explicit customer sign-off on any flagged records.
User migration and admin handoff
gradar user accounts are migrated to Recruit CRM User records matched by email. Permission group assignments are documented in the migration report for the customer's Recruit CRM admin to reconfigure. We deliver the Benchmarking Data and Equal Pay Analysis as structured dataset exports alongside the migration, with written guidance on how to surface these in Recruit CRM or an external analytics tool. We do not rebuild gradar evaluation workflows, pay rules, or compensation automations as these have no equivalent in Recruit CRM.
Platform deep dives
gradar
Source
Strengths
Weaknesses
Recruit CRM & ATS
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 gradar and Recruit CRM & ATS.
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
gradar: Not publicly documented.
Data volume sensitivity
gradar 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 gradar to Recruit CRM & ATS migration scoping. Not seeing yours? Book a call.
Walk through your gradar to Recruit CRM & ATS migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave gradar
Other ways to arrive at Recruit CRM & ATS
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.