Migrate from PeopleForce to Recruit CRM & ATS

PeopleForce Employee records map to Recruit CRM Candidate records. The employee's name, contact information, employment dates, and department migrate as candidate profile fields. Active Employees migrate as active Candidates with a status flag set during migration; Inactive or Offboarded Employees migrate as archived Candidates with their final status preserved. The employee's original hire_date migrates as a candidate custom field for historical reference.

PeopleForce profile photos, bio data, emergency contacts, and skills stored as sub-objects on Employee flatten into Recruit CRM's candidate profile structure. Skills migrate as tagged skills on the candidate record. Profile photo URLs migrate as a custom field since Recruit CRM stores candidate photos differently. Emergency contacts migrate as a JSON-structured custom field or note attachment.

PeopleForce Positions capture job title, department, employment type, and effective dates. These map to Recruit CRM Jobs where the position title becomes the job title and department maps to an internal job category. The employment_type (full-time, part-time, contract) maps to Recruit CRM's job type field. Where the destination uses a different job-title schema, we apply a mapping table during transformation.

PeopleForce PeopleRecruit Vacancies (open positions with job descriptions, requirements, and posting configurations) map to Recruit CRM Jobs. The vacancy title, description, requirements, and status migrate as job fields. Active vacancies migrate as open jobs; closed vacancies migrate as archived jobs. Multiposting configurations and job board connections do not transfer and require reconfiguration in Recruit CRM's job distribution settings.

PeopleForce PeopleRecruit Application records map to Recruit CRM candidate pipeline entries. Each application maps to a candidate record with the application status (applied, screening, interview, offer, hired, rejected) mapped to the corresponding Recruit CRM pipeline stage. Application timestamps, source (referral, job board, direct), and interview scorecards migrate as activity or custom fields on the candidate.

PeopleForce custom fields on the Employee object migrate to Recruit CRM custom fields on the Candidate object. We inventory all active custom fields during discovery, map their data types (text, number, date, dropdown) to Recruit CRM equivalents, and migrate custom field values as structured candidate attributes. Custom fields that reference other Employee sub-objects require manual mapping during scoping.

Employee documents (contracts, ID copies, certifications) stored per PeopleForce Employee record migrate as candidate documents in Recruit CRM. Document metadata (filename, upload date, document type) transfers; actual file content migrates where accessible via PeopleForce API or export. We note that file attachments may require re-upload in Recruit CRM if the API returns URLs rather than binary content. Document categorization (contract vs. ID vs. certification) maps to Recruit CRM's document type taxonomy.

PeopleForce recognition records (Kudos given between employees with timestamps and messages) migrate as historical supplemental records. Recruit CRM does not have a native recognition module, so kudos migrate as internal notes on the candidate profile or as a custom activity type. We document the limitation so the customer can decide whether to include recognition history in the candidate profile or store it separately.

PeopleForce custom triggers and automated sequences built on the workflow engine with employee profile attributes and key dates do not migrate as code. We document every active workflow during discovery: trigger conditions, attribute-based rules, automated actions, and resulting status changes. The inventory is delivered as a written specification for the customer to rebuild in Recruit CRM's workflow builder post-migration.

PeopleForce leave policies, accrual rules, and leave balances are HR-specific data that has no direct equivalent in Recruit CRM's recruitment-focused data model. Leave data is migrated as supplemental candidate profile data only if the agency's workflow requires leave-related context on the candidate. Otherwise, leave policies and balances are flagged as out-of-scope and the customer manages leave in a separate HR system post-migration.