Migrate from iCIMS Talent Cloud to Zoho Recruit

iCIMS Person Profiles map to Zoho Recruit Candidates. The iCIMS resume-parsed structured fields (first name, last name, email, phone, address, work history, education) map to standard Zoho Recruit Candidate fields. Custom fields on iCIMS Person Profiles require pre-creation in Zoho Recruit via Setup > Customization > Modules; we read the full iCIMS custom field schema via the Schema API during scoping and create matching Zoho Recruit custom fields before import. The iCIMS numeric internal field identifier is preserved in a custom Zoho Recruit field icims_field_id__c for audit traceability.

iCIMS Job Profiles map to Zoho Recruit Job Openings. The iCIMS job title, department, location, and hiring stage pipeline fields map to Zoho Recruit Job Opening standard fields. iCIMS Job Profiles store a recruiting workflow that defines pipeline stages; Zoho Recruit Job Openings use a different stage model tied to candidate status values. We extract the iCIMS Job Profile stage names and map them to Zoho Recruit candidate status picklist values, creating custom status values when the iCIMS stage name has no Zoho Recruit equivalent.

iCIMS Submittals represent the Person-to-Job association with submission date, current stage, and routing history. Zoho Recruit's Candidate Job Status (the history subpanel on a Job Opening) tracks the same data. Submittal migration requires both the Candidate and the Job Opening to exist in Zoho Recruit first, so Submittals migrate in the third phase of the import sequence. The iCIMS Submittal ID is stored as a custom field on the Candidate Job Status record for reconciliation.

iCIMS Companies (employer organization data distinct from candidate employer history) map to Zoho Recruit Clients. The iCIMS company name, industry, size, and address fields map directly to Zoho Recruit Client standard fields. Client records are created before Candidate import when the migration includes candidate employer history linked to iCIMS Company records.

iCIMS Offers record compensation package, start date, and offer status against a Submittal. Zoho Recruit does not have a separate Offer object; offer details attach to the Job Opening or Candidate Job Status as custom fields. We create custom fields on the Job Opening object for Salary, Start Date, Offer Status, and Offer Notes, preserving the iCIMS offer data. Customers requiring a dedicated offer letter workflow use Zoho Recruit's document attachment capability or a Zoho Writer integration post-migration.

iCIMS Talent Pools are AI-tiered candidate groupings with Role Fit scores and skill-match metadata. Zoho Recruit does not have a native Talent Pool object. We split the pool membership into two destination structures: the tier level (Tier 1, Tier 2, Tier 3) and Role Fit score are stored as custom fields on the Candidate record, and the pool name becomes a Zoho Recruit Tag on the Candidate. The customer's admin rebuilds active Talent Pool segments as Candidate Portal access lists or Tag-based groups in Zoho Recruit post-migration.

iCIMS custom fields carry a numeric internal identifier and an attribute name. Zoho Recruit custom fields use an API name (auto-generated or admin-defined) without an internal numeric ID. We read the iCIMS Schema API for all custom field definitions during discovery, create matching Zoho Recruit custom fields (with field types validated against Zoho Recruit's supported types: Text, Picklist, Multi-select, Date, Number, Boolean, URL, Phone, Email), and store the original iCIMS field identifier in a custom audit field. Lookup fields require Professional or Enterprise tier in Zoho Recruit and are not available in Standard Edition.

iCIMS Hiring Workflows define pipeline stages, routing rules, and approval chains per Job Profile. These configurations are instance-specific with custom stage names and conditional routing. We do not migrate Hiring Workflows as code. We extract every active iCIMS workflow with its stages, routing conditions, and approval assignments and deliver a written inventory that the customer's admin uses to rebuild equivalent workflow rules and Blueprint sequences in Zoho Recruit's Professional or Enterprise tier. Workflow rebuild is outside migration scope.

iCIMS iForms are electronic documents completed by candidates with a unique completed form ID. A Reddit post from a departing iCIMS customer confirms that the standard data export does not package completed iForms as retrievable files; they appear as data rows in an Excel export without the actual document attachments. We flag this as a data integrity risk during scoping. If the customer's iCIMS account has the iForm document files accessible via the API by completed ID, we extract and attach them to the corresponding Zoho Recruit Job Opening or create a custom iForms module. If the files are not accessible, we document the gap and recommend manual retrieval or rebuilding in Zoho Recruit's document attachment workflow.

iCIMS Connect Events log candidate engagement activities: email opens, career site visits, chatbot interactions. Zoho Recruit does not have a native engagement tracking object equivalent to iCIMS Connect. We do not migrate Connect Events. We deliver a written inventory of engagement event types and dates as a reference document so the customer's admin can evaluate Zoho Recruit's built-in candidate activity tracking or a third-party integration for post-migration engagement monitoring.

iCIMS Employee Referral data is attached to Person Profiles as referral source metadata. Zoho Recruit has a standard Source field on Candidate records with predefined values including Employee Referral. We extract the referral source and employee referrer data from iCIMS Person Profiles and map it to the Zoho Recruit Source field. If the referrer's name or employee ID is needed for reporting, we store it in a custom Candidate field referral_employee__c.

iCIMS Onboard records track post-hire onboarding activity, document completion, and employee setup. Zoho Recruit is an ATS, not an onboarding platform; it does not have a native Onboard object. We do not migrate Onboard records as a full data set. We extract the onboarding completion status and key dates (start date, I-9 completion, benefits enrollment) and attach them as custom fields on the Job Opening record for reference. Full onboarding workflow management should be handled in a dedicated onboarding tool post-migration.