Migrate from Namely to Recruit CRM & ATS

Namely Employee records map to Recruit CRM Candidate profiles. We extract demographics (name, contact, address), employment status, job title, department, and hire date. Employment tenure in Namely maps to a custom candidate field for sourcing context. Active employees being sourced for new roles become Candidates with an initial status; historical employees from the HRMS who were previously candidates or placements map to Candidate records with status reflecting their current relationship. Namely's employee photo does not migrate as Recruit CRM's candidate profile uses a separate media upload.

Namely's departments and cost centers map to Recruit CRM Teams. We preserve the hierarchy as a flat team structure with a custom field dst_department_path__c containing the full Namely department chain for reporting. If the customer uses cost centers for headcount planning, these migrate as a custom picklist field on Candidate rather than as a separate object, since Recruit CRM Teams are scoped to recruiting desk structure rather than enterprise org charts.

Namely compensation records (salary, bonus, equity, effective dates) migrate to custom fields on the Recruit CRM Candidate record. We preserve the most recent compensation figure and effective date as dst_current_salary__c and dst_compensation_effective__c for sourcing and offer-preparation context. Compensation history timelines do not map cleanly to Recruit CRM's candidate data model, so we carry the current snapshot only; historical pay progression is delivered as a supplemental CSV.

Namely job requisitions and postings migrate to Recruit CRM Job records. We map job title, description, department assignment, status, and location fields. Approval chains attached to requisitions are documented in the Workflow inventory (not migrated) since Recruit CRM handles job approvals as a configurable stage step rather than a separate approval object. Open requisitions migrate as active Jobs; closed positions migrate with status mapped accordingly.

Namely supports custom properties on employee records. We discover all custom field definitions via API during discovery, classify them by type (text, number, date, picklist), and create equivalent custom fields on Recruit CRM Candidate. Text fields map directly, numeric fields map to number fields, date fields map to date fields, and picklist values are recreated as picklist options in Recruit CRM. Fields with no equivalent in Recruit CRM's Candidate model are migrated as text with a naming convention flagging their original type.

Employee documents (offer letters, contracts, certifications, I-9s) migrate as file attachments on the corresponding Candidate record in Recruit CRM. We normalize file naming using candidate_id_document_type conventions during extraction to handle Namely's inconsistent document naming. Document metadata (upload date, uploader) is preserved as a JSON sidecar attached to the record. Binary blobs are transferred as-is. We note that Recruit CRM's document viewer supports PDF and common office formats; any non-standard file types are flagged for manual handling.

Namely performance review ratings and feedback migrate as custom notes attached to the Candidate record with type = performance_review. We extract the review date, overall rating, and a plain-text summary of qualitative feedback. Review templates, rating scales, and review cycle configurations do not migrate because Recruit CRM has no native performance review module; these are delivered as a structured document in the configuration inventory for the customer's admin to evaluate in context of their hiring process.

Current PTO, sick leave, and accrual balances migrate as a snapshot custom field dst_pto_balance__c on the Candidate record. We flag the accrual policy type (accrual-based vs unlimited) during extraction so customers understand the data context. For unlimited PTO policies, there is no balance to export; we document the policy name and note this as a null-field in the migration output. This field is informational for sourcing and onboarding handoff, not a live accrual tracking field, since Recruit CRM does not manage PTO.

Namely workflow configurations, approval chains, and automation rules are not structurally portable to Recruit CRM. The two platforms have fundamentally different workflow models: Namely uses role-based approval chains on HR actions, while Recruit CRM uses stage-based pipeline automation and task assignments. We export a written inventory of every active Namely workflow with its trigger, conditions, associated record types, and action steps. The customer's recruiting operations team rebuilds these as Recruit CRM pipeline automations post-migration.

Namely benefits enrollment data (health, dental, vision, 401k elections, carrier plan IDs) does not migrate to Recruit CRM because Recruit CRM has no benefits administration module. Plan IDs are carrier-specific and non-portable regardless of destination. We extract a benefits enrollment summary per employee as a PDF or CSV for the customer's records, but the customer must reconfigure benefit elections at their chosen HRMS destination if they are separating the recruiting desk from a broader HR platform. This is a known gap in the migration scope and is disclosed during scoping.