Migrate from Alpha Hire to Recruit CRM & ATS

Alpha Hire Candidate profiles, including screening data, vetting records, application history, and any AI-generated screening scores, map to Recruit CRM's Candidate record. We preserve the full name, email, phone, resume URL, skills, and status. Alpha Hire's unsourced candidate records (those without a linked Talent Partner) migrate with status preserved. Custom candidate fields migrate as custom fields in Recruit CRM's candidate schema. Source attribution (VMS vs manual) is preserved in a custom field for billing and reporting reconciliation.

Alpha Hire Job Orders from VMS feeds, manual entry, and other channels map to Recruit CRM Job records. We map job title, description, requirements, status, hiring stages, and assigned recruiter. VMS-sourced jobs may have incomplete source attribution; we flag records with missing client_id or contact_id for customer review before final load to prevent orphaned job records in Recruit CRM's ATS-CRM model.

Alpha Hire Talent Partner records, including associated client assignments and assignment histories, map to Recruit CRM's Client entity. We map company name, contact details, and relationship type. Assignment history migrates as a linked activity record on the Client. Talent Partners without an active client association migrate as standalone Client records with a partner_type tag.

Alpha Hire's three-step hiring process maps to Recruit CRM's pipeline and stage configuration. Stage names migrate as Recruit CRM stage values within the pipeline. If the customer has configured custom stage names per client, we replicate these as Recruit CRM pipeline templates. Stage ordering and probability percentages transfer as configuration metadata.

Alpha Hire's custom assignment rules are internal configuration with no export path. During scoping, we ask the customer to document their active rule set including trigger conditions, assignment criteria, and fallback logic. We reproduce each rule as a Recruit CRM Workflow where the platform's builder supports the equivalent logic. Rules that cannot be recreated (due to VMS-only triggers or proprietary logic) are flagged as requiring manual reconfiguration post-migration with a written description of the original rule behavior.

Alpha Hire subscription metadata including plan tier, billing model (fixed vs percentage), and start dates are preserved as read-only text notes on the migrated account. We do not replicate billing relationships; these are re-established directly with Recruit CRM post-migration. Plan tier information is useful for the customer's finance team to understand prior cost history during the transition period.

Candidate attachments, offer letters, and onboarding documents may be stored within Alpha Hire. Export availability depends on the customer's data export capability from Alpha Hire. We attempt to include all accessible documents as linked file attachments on the corresponding Recruit CRM Candidate record. If Alpha Hire's export does not include binary attachments, we document the gap and advise the customer on manual retrieval options from the Alpha Hire dashboard.

Alpha Hire engagement history (email logs, call records, note entries) associated with Candidates or Job Orders migrates to Recruit CRM's Activity log on the corresponding record. Timestamps and engagement type (call, email, note) are preserved. We map the recruiter owner by email match to the Recruit CRM user. Activities without a resolvable parent record are held in a reconciliation queue for customer review before final load.

Alpha Hire's active integrations (Microsoft Outlook email sync, ADP payroll, QuickBooks billing) are documented during scoping. We identify equivalents in Recruit CRM's integration marketplace and flag any that require rebuild. Outlook email sync maps to Recruit CRM's native email integration; ADP and QuickBooks require checking Recruit CRM's current connector availability and flagging any gap for the customer's admin to address post-migration.

Alpha Hire users mapped by email address to Recruit CRM User accounts. Active and inactive status is preserved. If the customer has a user count that exceeds Recruit CRM's per-seat licensing, we flag the discrepancy during scoping so the customer can adjust their Recruit CRM plan tier before migration begins.