Migrate from eRecruiter to Recruit CRM & ATS

eRecruiter Candidates migrate directly to Recruit CRM Candidates. The eRecruiter CandidateId becomes an external_id field in Recruit CRM for deduplication on re-migration. Contact details (name, email, phone, address), work experience, education, and skills tags migrate as structured fields. GDPR consent flags from eRecruiter's RODO module migrate to Recruit CRM's consent tracking fields. If the eRecruiter candidate has a Company linkage, we preserve it via a custom field until the Client record is created in Recruit CRM.

eRecruiter Applications link a Candidate to a Job and carry pipeline stage, status, rating, and notes. We migrate Application records as first-class objects in Recruit CRM, resolving the CandidateId and JobId references before writing. Pipeline stage names from eRecruiter map to Recruit CRM pipeline stages, with any custom stage labels preserved in a custom field. Custom application questions migrate as structured text fields.

eRecruiter Job postings include title, HTML description, location, department, employment type, and publication status. We migrate Jobs as independent records and deactivate them in Recruit CRM pending the customer's decision to republish. Department and location data migrate as structured fields; if Recruit CRM uses a different department taxonomy, we preserve the eRecruiter values in a custom field for manual reassignment.

eRecruiter Company entities migrate to Recruit CRM Clients (organizations in Recruit CRM's data model). ExternalId matching identifies existing clients for updates versus new record creation. Company address, industry, and size data migrate as structured Client fields. Company records linked to Candidates in eRecruiter are resolved via the Candidate-Client relationship in Recruit CRM after both objects land.

eRecruiter Users (recruiters with name, email, role, and department) map to Recruit CRM Users. Role naming differs between platforms, so we capture the eRecruiter role in a custom field on the Recruit CRM User for audit and reporting during the transition period. Any eRecruiter User without a matching Recruit CRM account is held in a reconciliation queue for the customer's admin to provision before record import.

Department is a referenced entity on Jobs and Users in eRecruiter. We migrate Departments as independent records if Recruit CRM treats them as such, or as structured properties on Job if Recruit CRM's schema handles department as a picklist field. The customer's Recruit CRM admin confirms the target schema during scoping.

Location data on Jobs (city, region, country) migrates as structured address components in Recruit CRM. If the destination job posting supports multi-location assignment, we create each location as a separate entry linked to the same Job.

Documents attached to Candidates are transferred as binary files linked to the parent Candidate record. This migration requires the Candidate record to land in Recruit CRM first, establishing the target record ID. We use the eRecruiter DocumentTypeName and Filename as metadata against the uploaded file. Orphaned attachments (where the parent Candidate was excluded from migration) are flagged and reported but not transferred.

Application-level attachments migrate after both the Candidate and Job parent records are present in Recruit CRM. We sequence Application document migration after the Application record itself is written and its CandidateId and JobId references are resolved. This prevents attachments from landing on records that do not yet exist in the destination.

Structured evaluation ratings in eRecruiter are stored as part of the Application record or as linked feedback entries. We serialize scorecard data into custom fields on the Recruit CRM Application record. The field types (number, picklist, text) are determined during the schema discovery phase and created in Recruit CRM before application migration begins.

Both Candidate and Application support custom fields in eRecruiter. We discover the custom field schema during scoping, including any CV Parsing output fields that vary by template and parsing version. Recruit CRM custom fields are pre-created with type-mapped equivalents (text, number, date, picklist) before any record migration. CV Parsing fields that lack a stable schema are mapped as text fields to avoid silent type mismatches.