Migrate from Webrecruit to Crelate

Webrecruit Candidate records map to Crelate Contact. We map standard fields (first name, last name, email, phone, address) directly. The Webrecruit GDPR consent flag (boolean with timestamp) migrates to a Crelate custom field gdpr_consent_date__c (date) and gdpr_consent_withdrawn__c (checkbox) on the Contact record. Candidates with withdrawn or expired consent are flagged but not migrated unless the customer explicitly requests otherwise. Application history attaches as a custom multi-line text or related list entry on the Contact.

Webrecruit Job records (title, description, department, location, status, posting dates) map to Crelate Opportunity with custom fields capturing the Webrecruit-specific properties. The job title becomes the Opportunity name; department becomes a custom picklist field; location maps to a custom text field. Webrecruit job status (active, paused, closed) maps to Opportunity Stage values that we configure in Crelate before migration.

Webrecruit Application records (linking a Candidate to a Job with a timestamp and current stage) have no direct Crelate equivalent because Crelate's model uses Opportunity as the candidate placement record. We map Application data as custom fields on the Crelate Opportunity: application_date__c, current_stage__c, rejection_date__c, withdrawal_date__c, and rejection_reason__c. The candidate Contact attaches to the Opportunity via a Contact lookup or Opportunity Contact Role.

Webrecruit's fixed stage pipeline maps to Crelate Opportunity Stage values. We define a Crelate Sales Process with stage values that match or approximate the Webrecruit pipeline. Webrecruit bespoke stages (aptitude tests, competency evaluations) that have no native representation in the system are flagged as custom fields on the Opportunity (e.g., assessment_outcome__c) and we ask the customer to confirm whether these are stored elsewhere and whether they need to be migrated as notes or custom field values.

Webrecruit Hiring Managers assigned to Jobs map to Crelate User records by email match. We resolve the owner relationship at migration time. If a Hiring Manager has no matching Crelate User, they are placed in a reconciliation queue for the customer's admin to provision before record import resumes. Hiring Manager feedback attached to Applications migrates as Activity records on the corresponding Opportunity.

Webrecruit approval workflows defining job requisition movement from creation to posting do not migrate as code. We export workflow step definitions and attempt to document them in a written handoff document that maps each Webrecruit workflow step to a recommended Crelate equivalent (manual checklist, email template, or approval flow). The customer's admin rebuilds these in Crelate post-migration. We do not implement Crelate workflow automation inside the migration scope.

CVs, cover letters, and attachments stored per Webrecruit Application migrate as ContentDocument records in Crelate. We export document blobs, upload them to Crelate's document storage, and link them to the corresponding Contact record via ContentDocumentLink. The original filename and any associated notes migrate as the document description. If document storage limits apply at the customer's Crelate tier, we flag this during scoping.

Webrecruit custom fields vary by account and do not have a standardized schema. We export field definitions and values, then map them to Crelate custom fields on the equivalent core record (Contact, Company, or Opportunity). Crelate supports custom fields as Text, Number (Integer), Number (Decimal), Number (Money), and other types. We map field types accordingly and flag any fields with no matching Crelate type for manual re-entry. If the customer is on a Crelate tier with a limit on custom field count, we flag this during scoping and prioritize the most critical fields.

Webrecruit User accounts (name, email, role, permissions) map to Crelate User records by email match. We extract all distinct Webrecruit Users referenced on Candidate, Job, and Application records and match them against the Crelate destination org's User table. Any Webrecruit User without a matching Crelate User goes to a reconciliation queue for the customer's admin to provision before migration resumes.

Webrecruit integrations with BreatheHR and CIPHR are connection-level configurations that do not carry over to Crelate. We document which integrations are active, note their purpose, and include re-connection steps in the post-migration checklist. The customer re-authenticates and reconfigures each integration in Crelate. Crelate's broader integration ecosystem (RingCentral, Zapier, Bullhorn, Indeed, Google Workspace, HireEZ, and others) provides replacement connectivity options that we document during scoping.

Webrecruit stores organizational data on the Job record (department, hiring team) but does not have a standalone Company object equivalent to Crelate's Company core record. If the customer uses Webrecruit's employer brand or client organization data, we map it to Crelate Company records with the organization name as the Company name. The Webrecruit employer entity (the customer's own organization) is created as a Crelate Company record for reference.

Webrecruit GDPR consent flags are stored as a boolean per Candidate with a consent timestamp. We export the consent timestamp and flag alongside each Candidate record and map them to Crelate custom fields on Contact: gdpr_consent_date__c (date), gdpr_consent_withdrawn__c (checkbox), gdpr_consent_source__c (text, capturing the original consent mechanism). UK law requires that consent status is preserved and honored in the destination system. Candidates with withdrawn or expired consent are flagged but not migrated unless the customer explicitly requests otherwise. The customer is responsible for configuring Crelate's suppression list workflow post-migration.