Migrate from Sage People to Recruit CRM & ATS

Sage People Employee records map to Recruit CRM Candidate records. We extract standard fields including name, email, phone, address, department, job title, employment dates, and manager reference. Custom fields with UD_ or UDF_ prefixes are inventoried against Recruit CRM's available candidate fields and mapped to custom fields where the destination schema supports them; non-standard fields without equivalents are flagged for explicit customer decision during scoping. The Sage People manager hierarchy is preserved as a reference field on the Candidate record for reporting and org-chart reconstruction.

Sage People Vacancy records map to Recruit CRM Job records. We map vacancy title, description, requirements, compensation band, location, and status. Vacancy status (Draft, Open, On Hold, Filled, Cancelled) maps to Recruit CRM's job status equivalents. Sage People compensation bands migrate as custom fields if Recruit CRM's standard salary range fields do not accommodate the granularity of the source data.

Sage People creates application records linking Candidates to Vacancies. In Recruit CRM, this relationship is represented through the candidate record's associated job applications. We migrate the application status, submission date, source channel, and any interview stage history as activity log entries or custom fields on the candidate record. The migration resolves the candidate ID and job ID independently before establishing the association to avoid orphaned application records.

If the source Sage People org has the Recruitment module active, candidate records from that module map directly to Recruit CRM Candidates. The mapping includes name, contact information, resume content (as a document attachment), skills, and source attribution. We flag any candidate records with duplicate email addresses against the Employee-to-Candidate mapping to prevent double-creation during the final load.

Sage People Department records map to Recruit CRM Organizations if the destination org uses the Organizations feature for company-level candidate context, or to Tags if the organization prefers a flat tag-based taxonomy. We preserve parent-child department hierarchy as a custom field or tag hierarchy depending on the customer's preference set during scoping. Cost center codes migrate as a custom field on the Organization or as a tag value.

Sage People stores Job Templates as reusable position definitions separate from filled Position records. We map job template fields including title, grade, department, location, and description to Recruit CRM Job records with a template flag set. If the destination org does not use Recruit CRM's template feature, the templates migrate as standard Job records and the customer decides which to activate as open positions post-migration.

Absence records and leave balances from Sage People map to Candidate Notes entries or custom fields on the Candidate record depending on whether the absence history is relevant to the recruiting context. Leave records that indicate planned availability dates are mapped to candidate availability fields where Recruit CRM supports them. This mapping is most relevant when Sage People is used for internal mobility tracking and the candidate pool includes internal applicants.

Effective-dated compensation records (salary, bonus, equity) from Sage People migrate as a custom field group on the Candidate record. We serialize the compensation history as a JSON-formatted custom field or as multiple dated custom fields depending on the customer's reporting needs. Custom compensation components (allowances, car values, commission structures) require explicit value mapping and are flagged for customer review before load.

Employee documents (contracts, certifications, resumes) stored as Salesforce attachments in Sage People are exported as binary blobs with metadata including document type, upload date, and related record reference. We pre-fetch all attachment URLs in a batch queue immediately before insertion to avoid Sage People's two-minute URL expiry window. Documents are re-associated in Recruit CRM by candidate ID mapping and stored against the corresponding Candidate record. PDF and DOCX formats are preserved; unsupported formats are flagged for manual delivery.

Enhanced Objectives and performance review records from Sage People migrate as formatted Notes entries on the Candidate record. The objective text, key results, and review status are preserved as structured note content. Due to Sage People's known state-machine issues with draft versus active review states, we flag any objectives with ambiguous status for manual review before migration and document them in the reconciliation report rather than silently loading ambiguous state records.

Sage People organizations frequently add custom fields with UD_, UDF_, or IM_ prefixes. We inventory all custom fields during discovery, compare the live schema against Sage People's standard field reference, and flag any fields that lack a direct Recruit CRM equivalent. Custom picklist values are mapped as explicit value translations. Custom fields without prefixes are detected by comparing the live schema against the standard reference and flagged for explicit review before mapping decisions are finalized.

Sage People does not expose workflow definitions or approval routing rules through its Salesforce API. We capture every active workflow during discovery as a written configuration inventory document covering trigger conditions, approval stages, escalation paths, and field updates. The customer receives this document at migration close and uses it to rebuild workflows in Recruit CRM's visual workflow builder. This documentation step is the only migration pathway for automation logic and is included as a standard deliverable rather than an optional add-on.