Migrate from Candidate Management System to Crelate

Job records migrate 1:1 to Crelate Jobs with status, department, location, and posting dates preserved. We map the internal job ID from Candidate Manager to a custom reference field in Crelate for audit traceability. If the source Job has associated pipeline stages, we configure matching stages in Crelate's workflow builder before Applications are loaded so that stage assignments resolve correctly on import.

Candidate profiles migrate to Crelate Person records with name, email, phone, work history, education, and skills. We deduplicate by email address and flag duplicate candidates for customer review before final insert. Skills tags map from Candidate Manager's skills list to Crelate's tag system on Person records.

Applications link Candidates to Jobs and carry status, source, and submission timestamp. We create the Job Application in Crelate after resolving both the Person (Candidate) and Job references, preserving the application-to-candidate relationship explicitly rather than inferring it. Application status maps to the corresponding Crelate pipeline stage name.

Stage names and order from Candidate Manager are enumerated during discovery and configured as Crelate Workflow Stages per Job or globally. We map the source stage sequence explicitly and flag any Applications in stages that have no equivalent in the destination pipeline configuration for customer decision.

Custom fields added by the tenant on Candidate or Application objects vary by organization and have no unified schema catalog. We enumerate every custom property during discovery, map text and numeric fields to Crelate Custom Fields by type, and flag any orphaned custom fields (fields with no clear destination equivalent) for customer review. Fields without a destination are stored in a catch-all JSON blob as a Crelate custom field for manual retrieval.

Ranking scores and pre-profiling data stored as properties on the Candidate or Application record map directly to Crelate Custom Fields on the Person or Job Application. Numeric scores transfer as typed numeric fields; textual scoring rubrics that are not structured as key-value pairs are flagged as requiring manual re-entry in Crelate's rating interface.

Recruiter notes attached to Candidates or Applications export as free-text blobs. We preserve note content and authorship and map each note to the corresponding Crelate Person or Job Application record. Non-structured notes that reference specific stage names or dates are flagged if the destination pipeline stages differ from the source.

Resume files, cover letters, and portfolio documents export as binary blobs. We extract text content where parsable for Crelate's resume parser enrichment, and re-upload original file types to Crelate's document storage linked to the correct Person or Job Application record. File naming conventions preserve the original filename for recognition by the recruiting team.

Hiring manager portal configurations, approval chains, and scorecard templates in Candidate Manager are not migratable as configuration code. We document the existing portal structure, approval chain steps, and scorecard field definitions in a written handoff document for the customer's admin to rebuild in Crelate's workflow builder.

Staffing agency portal access settings, client visibility permissions, and external stakeholder configurations in Candidate Manager have no direct Crelate equivalent in the migration scope. We inventory the existing portal roles and access scopes and deliver them as a configuration checklist for the admin to implement in Crelate's client management settings.

Candidate source attribution (job board, referral, direct) stored as a property on the Application record migrates to Crelate's Source field on Job Application. This preserves the sourcing analytics that teams rely on for job board ROI reporting.

Recruiter assignments on Candidate, Application, and Job records resolve by email match against Crelate User records. Any Candidate Manager Owner without a matching Crelate User is held in a reconciliation queue for the customer's admin to provision before record import resumes. Owner history (which recruiter last touched a record) is preserved as a custom field if the source captures it.