Migrate from eRecruiter to Crelate

eRecruiter Candidates map to Crelate Person records. We resolve the Person by email address during import, creating new records when no match exists. Contact details, skills, work history, and application answers migrate as structured fields. CV Parsing output stored as custom candidate fields in eRecruiter requires schema discovery during scoping because field names vary by CV template and parsing version; we treat all parsed CV fields as custom fields and validate Crelate's target schema before writing to avoid silent mapping failures.

eRecruiter Applications link a Candidate to a Job and carry status, stage, rating, and notes. We migrate Application records as first-class objects, preserving the pipeline stage name and any custom application fields. The Crelate Application requires a resolved Person (candidate) and Job reference before insert; we ensure parent record lookups are satisfied by sequencing Jobs before Applications in the migration load order.

Job postings in eRecruiter include title, description (HTML), location, department, employment type, and publication status. We migrate Jobs as independent records and deactivate them in Crelate pending re-publication so that the customer's recruiting team can review and activate postings on their schedule. Location data (city, region, country) migrates as structured address components compatible with Crelate's location field model.

eRecruiter Company entities migrate to Crelate Client records. The Company Import API endpoint in eRecruiter uses ExternalId matching for updates, which we replicate using Crelate's lookup pattern. Client Name is a required attribute in Crelate's API, so we validate that the company name field is populated before attempting insert. If the eRecruiter Company record has no name, we flag it for customer review during scoping.

eRecruiter User records (name, email, role, department assignment) map to Crelate Users. We match by email address and resolve the Crelate User ID as the Owner reference on migrated records. Role naming differs between platforms, so we capture the eRecruiter role name in a custom field on the Crelate User for audit during the migration window. Users not yet provisioned in Crelate go to a reconciliation queue for the customer's admin to resolve before record import resumes.

Department in eRecruiter is a referenced entity on Jobs and Users. Crelate handles Department as a property on the Job record or as a separate organizational unit depending on the customer's configuration. We detect the target's schema during scoping and migrate Department records accordingly, mapping department names and any parent-department hierarchy present in eRecruiter.

Location data on Jobs (city, region, country) migrates as structured address components. If eRecruiter stores multi-location job postings, we handle location mapping to Crelate's location model during Job migration. We preserve all location fields as independent address components rather than collapsing them into a single address string to maintain searchability in Crelate.

Candidate attachments in eRecruiter are identified by DocumentTypeName, Filename, and the parent Candidate's ID. Crelate uses a ContentDocument model for linked files. We transfer binary attachments provided the linked Person record has been created in Crelate first; this creates a hard migration dependency where Candidates must reach Crelate before their attachments can be processed. Orphaned documents without a valid parent Person reference are flagged in the migration report for customer review.

Application attachments follow the same dependency chain as Candidate attachments: Applications must reach Crelate before their documents. The eRecruiter DocumentTypeName becomes a tag or category value on the Crelate document record. We validate that the parent Application ID resolves in Crelate before attempting document transfer to avoid orphaned binary records.

Structured evaluation ratings on Applications in eRecruiter are stored as part of the Application record or as linked feedback entries. We serialize scorecard data into structured custom fields on the Crelate Application record, preserving rating values, evaluator name, and timestamp. The Crelate Job settings determine whether ratings are required or optional on applications.

Both Candidate and Application records support custom fields in eRecruiter. We discover the full custom field schema during scoping, including CV Parsing-derived fields, and map them to equivalent custom properties in Crelate. Field type mapping requires type detection (text, number, date, picklist, boolean) to select the correct Crelate field type. CV Parsing fields are the highest risk here because they lack a universal schema; we validate each field against Crelate's target schema before writing.

Application custom fields migrate to Crelate Application custom fields following the same type-detection and schema-validation approach as Candidate custom fields. Application-level custom fields often include answers to screening questions, intake form data, and interviewer feedback fields. We map these to Crelate's Application custom field model, preserving the original field labels in a migration metadata field for reference during post-migration validation.