Migrate from iRecruit to Recruit CRM & ATS

iRecruit Job postings map to Recruit CRM Job records. Each iRecruit job carries internal/external visibility flags, social and job-board auto-posting settings, and a distinct set of knock-out questions defined at the job level. We preserve the job title, description, location, and status as standard fields. Job-board posting settings do not transfer automatically; the customer re-configures these in Recruit CRM post-migration using the platform's job multiposting to 5,000+ channels. The iRecruit Exporter scope must be built per job to capture the correct knock-out question answers per candidate-application context.

iRecruit Candidate records apply to one or more Jobs and carry resume, application date, source, stage progression, and any responses to per-job knock-out questions. We map candidate name, email, phone, resume (as a document attachment), application date, source, and current stage. When a candidate has applied to multiple jobs, their knock-out question responses may differ per job; we flag this dual-answer scenario and ask the customer to confirm which application's response context takes priority for the destination pipeline. Recruit CRM's AI resume parsing activates automatically on ingest.

iRecruit Enterprise requisition records with approval routing state map to Recruit CRM Jobs with a custom requisition_status field carrying the original approval state. The linear approval chain from iRecruit does not replicate as a workflow; we document the approval chain as a written record for the customer's admin to rebuild using Recruit CRM's no-code workflow automation at Business or Enterprise tier.

iConnect onboarding records include active e-signature sessions, in-progress I-9 forms, and benefits enrollment workflows tied to a candidate after offer acceptance. These sessions are authenticated against iRecruit's infrastructure and cannot be transferred as live sessions. We preserve the onboarding checklist state, completed document records, and all form field data so that the destination system can restart onboarding from the correct stage. The customer must re-send onboarding invite emails from Recruit CRM on go-live day for each active candidate.

iRecruit mass personalised email templates tied to specific candidate stages migrate as email template body text and subject lines into Recruit CRM's template library. Active sending queues and scheduled send-time triggers do not migrate; these are platform-specific scheduling constructs. We deliver a written template inventory with candidate-stage mapping so the customer's admin can re-activate the sending sequences in Recruit CRM's workflow automation.

iRecruit Enterprise EEO and affirmative action reporting flags stored at the candidate record level migrate as custom candidate fields in Recruit CRM. The one-click report generation function does not transfer; we deliver a written field inventory of every EEO-related field and its values so the customer's compliance team can rebuild the report logic in Recruit CRM's analytics module or export to a compliance reporting tool.

Work Opportunity Tax Credit qualification flags, category assignments, qualification date, and credit amount range migrate as custom fields on the candidate record in Recruit CRM. The actual credit capture depends on the destination payroll or HRIS system actively processing WOTC; the customer must re-submit qualifying hires to their payroll provider's WOTC programme post-migration. Failure to submit within the WOTC filing window, typically 28 days of hire, forfeits the credit.

iRecruit user accounts representing recruiters, hiring managers, and admins map to Recruit CRM user accounts with role assignments preserved as user-level properties. Session-based data such as login history and active sessions does not transfer and is not relevant in Recruit CRM. We resolve users by email match. Any iRecruit user without a matching Recruit CRM user goes to a reconciliation queue for the customer's admin to provision before record import resumes.

iRecruit knock-out questions are defined per job and determine whether an applicant is automatically disqualified. These are stored as field-level configurations on the Job record, not as global field definitions. We capture each knock-out question's field name, question text, and answer options and pre-create corresponding custom fields in Recruit CRM using the Jobs > Associated Fields API endpoint. Field IDs are assigned at creation time and must be resolved before candidate-answer migration, since Recruit CRM's associated-field update endpoint requires field_id references in the request body.

iRecruit exports to Sage HRMS and MyPayrollHR use a custom file format that customers on other HRIS platforms have extended or replicated independently. We document the source field schema and destination field mapping from the customer's existing export definitions. The actual export pipeline to Sage HRMS or MyPayrollHR must be rebuilt post-migration using Recruit CRM's API, Zapier, or Workato. We do not build the replacement integration pipeline as part of the standard migration scope.

iRecruit Enterprise requisition approval routing stored as a workflow state on the requisition record migrates as a written approval chain record attached to the corresponding Job in Recruit CRM. Recruit CRM's workflow automation at Business and Enterprise tiers can replicate parallel or conditional approval routing; we deliver a written requisition workflow inventory with the original routing logic so the customer's admin can rebuild the automation post-migration.

iRecruit placement records, where a candidate has been hired through a job requisition, map to Recruit CRM Placements. We preserve placement date, client name, job reference, candidate reference, and any fee or bill rate data stored in iRecruit. Placement history is often the highest-value data for agencies because it represents confirmed revenue-generating activity.