Migrate from gradar to Crelate

gradar Job records are the core evaluated entity. We migrate Jobs to Crelate Opportunity records, with the Job title as Opportunity Name, evaluation date as a custom date field, and factor-level scores stored as custom number fields on the Opportunity. The Opportunity's Account lookup links to the associated Client or Department as configured during scoping. Crelate's native Opportunity record type and stage model are repurposed to represent the job evaluation status rather than a recruiting placement stage, requiring a custom Sales Process configuration.

gradar Grade values (1-25) migrate as a custom integer field on the Crelate Opportunity record. The Grade Name (where gradar assigns labels like Associate, Mid-Level, Senior) migrates as a custom text field. We create both fields during schema pre-build. The grade value drives any downstream reporting segmentation the customer's admin configures in Crelate's Advanced Reports.

gradar's three career paths are represented as a custom picklist field on the Opportunity record. We extract the career path assignment from each Job record during export processing and map it to the corresponding picklist value. Custom picklist values are created in Crelate during schema pre-build to match the customer's actual career path labels exactly.

gradar's AI-assisted job description body migrates as a custom long-text field on the Crelate Opportunity record. The field supports rich text. Crelate's custom field type for long-form text accommodates descriptions of any length. We note that Crelate's native Job Posting feature references Opportunity fields, so the description field can be surfaced in candidate-facing job posts if the customer uses Crelate's publishing tools post-migration.

gradar competency profiles linked to each Job migrate as a custom text field on the Opportunity record. Structured competency lists are serialized as comma-separated values or JSON within the field. We flag any custom competencies that have no standard gradar equivalent and document them separately for the customer's admin to normalise in Crelate. Crelate's Activity Forms and custom questions can be used post-migration to capture competency assessment against the migrated profile.

Individual factor-level point scores that contribute to the overall grade are stored per job evaluation in gradar's advanced exports. We create a corresponding set of custom number fields on the Crelate Opportunity record for each factor used in the customer's gradar configuration (typically 6-12 factors). Total point score migrates as a separate custom integer field. We request the factor-level export explicitly during scoping as standard exports may not include this granular data.

gradar pay band definitions with min/mid/max per grade and currency migrate as custom currency fields on the Crelate Opportunity record. Currency ambiguity is resolved during scoping by requesting the customer confirm the correct currency per compensation structure. We create separate custom currency fields for each currency in use if the migration involves multiple regions. Crelate's custom field type for money fields handles currency formatting. We flag that Crelate does not natively manage pay band structures as a hierarchical object; bands are stored per Opportunity as indicative compensation ranges rather than a structured pay band table.

Market benchmarking data comparing roles to external market rates migrates as custom fields on the Opportunity record. We create a custom currency field for the market rate value and a custom text field for the benchmark source (e.g., Mercer, Radford, Aon). The linked Job reference is preserved through the Opportunity mapping. We note that third-party benchmarking datasets sourced from providers integrated into gradar are migrated as data records only, not as live integration connections; the customer must re-establish any benchmarking API integrations in their analytics environment post-migration.

gradar's gender pay gap regression analysis outputs are datasets, not standard CRM records. Crelate's ATS schema has no object that represents regression analysis results. We document the equal pay analysis as a written dataset export for the customer's HR analytics team to load into their preferred analytics platform (Excel, Power BI, Workday Analytics, or dedicated pay equity tools). The audit trail of how gradar calculated the gap is not migratable as a functional component; the source data (salary, grade, demographic fields) can be migrated to support a rebuild in a dedicated pay equity platform.

gradar user accounts and role-based access assignments migrate to Crelate as Contact records. We map gradar's user email as Contact Email, user name as Contact Name, and permission group assignments as custom text fields on the Contact. The Customer's Crelate admin provisions the actual Crelate User accounts post-migration, mapping the gradar user identities to Crelate User records with the appropriate access level. We deliver a user mapping document identifying which gradar users should become Crelate Users versus Contacts.

gradar evaluation dates and grade change history are not available in standard exports and require an explicit extended export request during scoping. We migrate the most recent evaluation date as a custom date field on the Opportunity. Historical grade progression is not migratable as a full audit trail unless the extended export is available; we document the gap in the migration handoff report and flag it for the customer's HR team to determine whether manual reconstruction is required.

gradar's Grade Map (the 25-grade structure with point-threshold boundaries and grade labels) is a platform configuration object. Crelate has no equivalent configuration schema for job grading. We deliver the Grade Map as a written reference document that the customer's HR team uses to define grade labels and boundaries as picklist values on the custom grade field post-migration. This is not an automated migration step; it is a configuration handoff requiring admin input.