The Definitive Guide to Migrating to Zoho Recruit

Zoho Recruit is an applicant tracking system developed by Zoho Corporation, an India-based technology company founded in 1996 by Sridhar Vembu and Tony Thomas as AdventNet and headquartered in Chennai, with its US office in Austin, Texas ¹. Recruit ships in two editions — Corporate HR for in-house hiring teams and Staffing Agency for recruiting firms — and is sold both standalone and inside the broader Zoho One bundle.

The typical Zoho Recruit customer is a 5-to-500-employee hiring team or a 10-to-200-recruiter staffing agency buying on price and bundle economics. Pricing starts at $0 for the Forever Free edition (1 active job), $25 per user per month on Standard, $50 on Professional, and $75–$90 on Enterprise ³⁷. Zoho positions Recruit on a 50-percent-savings claim versus Bullhorn and JobDiva, with the same suite-discount story across People Plus and Zoho One.

The shapes of migration that land on Zoho Recruit fall into four patterns. First, Freshteam exits, accelerated by Freshworks' decision to discontinue Freshteam — Zoho ships a dedicated Freshteam-to-Recruit migration guide ⁵⁵. Second, Bullhorn and JobDiva exits, driven by per-recruiter pricing on the source side; Zoho explicitly lists Bullhorn, CATS, JobDiva and Workable as completed migration sources on its migration request page ⁵⁶.

Third, suite consolidation: replacing a Greenhouse-plus-Calendly-plus-DocuSign stack with Zoho Recruit plus Zoho Sign plus Zoho People inside Zoho One. Fourth, upgrades from spreadsheets, where small agencies move off shared Excel files onto a real ATS for the first time.

What makes migrating *to* Zoho Recruit easier than the category average is the Data Migration wizard itself — it auto-creates Modules that do not exist on the destination, auto-maps columns to fields, and accepts CSV, XLS, XLSX and VCF ⁵⁵. It also ships a built-in Resume Extractor that parses CVs into Candidate fields, and a Career Site that captures applicants post-cutover.

What makes it harder than the average is the edition-tier architecture, which gates Custom Modules, multiple Hiring Pipelines, and most advanced custom-field types behind Enterprise ³⁷³⁹; the picklist value model that rejects values not on the destination dropdown ¹¹; and the Hiring-Pipeline-to-Status mapping rule that quietly reshuffles Modified Time on every record whose status gets remapped ⁵¹.

Workflow Rules, Blueprint state machines, assignment rules and scoring rules do not import — they are rebuilt from documentation. Teams that scope the rebuild work up front finish on time; teams that assume parity do not.

Zoho Recruit's bundle economics get hiring teams in the door; the edition-tier architecture and Hiring-Pipeline-to-Status coupling decide whether they stay on schedule.

Zoho Recruit is built around Modules — the platform's term for what Greenhouse calls Objects and Bullhorn calls Entities. Each Module carries standard and custom fields, sits behind one or more Layouts, and connects to other Modules through Lookups and Multi-Select Lookups. Permission is governed by Profiles; record visibility by Roles.

Before mapping any source field, you need to know which destination Module the row belongs in, which Layout it inherits, and which value will serve as its duplicate-check key. The table below summarises the standard Modules a Zoho Recruit migration will touch ¹²¹³.

Records get matched by what Zoho calls duplicate check fields — fields marked with the *Do not allow duplicate values* property. Email is the default duplicate check on Candidates and Contacts; Posting Title and Client on Job Openings. Once marked unique, the import upsert flow uses it to decide insert-versus-update ¹⁴.

Applications, Interviews and Custom Modules have no natural unique key — create a custom single-line text field, mark *Do not allow duplicate values*, and populate from the source system's primary key. The upsert flow also accepts an explicit find_by field pattern to match against a foreign system's identifier without disturbing the internal Zoho Record ID ²³.

When you upsert, Zoho checks the duplicate-check field set: if a match exists, the record updates; if none, it inserts. You can also pass Zoho's internal Record ID directly when re-importing your own export — the Record ID is the canonical primary key and bypasses duplicate-check matching entirely. Custom field types determine validation, storage and edition availability.

Relationships in Zoho Recruit model parent-child through Lookup fields and many-to-many through Multi-Select Lookup fields, which silently create a hidden linking Module visible in *Developer Space*. A Candidate has a Lookup to one Client (Staffing) and many Applications; a Job Opening has Lookups to one Client and many Applications.

There is no native cascade delete — deleting a parent does not delete children, which is a behaviour your Deluge or Workflow logic must reproduce if the source platform relied on it ⁹.

Custom Modules participate in Lookups the same way standard modules do, with the same duplicate-check semantics. They are gated to Enterprise, Zoho One and People Plus editions, and their schema, Layouts and unique-ID fields must exist on the destination before any record can be imported ⁴⁹. Subforms are limited to one per module and migrate as child records, not parent-row payloads.

The single best predictor of a clean Zoho Recruit migration is how much work happens on the source side before the first import button is pressed. Zoho's Data Migration documentation devotes most of its prep checklist to source-side hygiene — file format, date format, mandatory-field coverage, drop-down value alignment — because the wizard rejects rows quietly on any mismatch and surfaces the reasons in Import History after the fact ²².

Zoho Recruit's Data Migration wizard is fast when the source file is clean and unforgiving when it isn't — pre-processing is where the time savings come from.

Treat the source export as raw material that must be shaped to Zoho's expected formats — emails lowercased, picklist labels converted to the values on Zoho's destination drop-downs, dates rewritten in the org locale format, currency stripped of symbols, owners resolved to Zoho user emails, and resume files staged for attachment.

Source-side prep

• Audit and dedup the source database before export — Zoho's de-duplicate tool runs post-import and is slow on large candidate datasets. Catch case-only email duplicates and trailing-whitespace duplicates in the source export, not after they land.
• Convert picklist display labels to the values that exist on the Zoho destination for every drop-down field — Candidate Status, Application Status, Lead Source, Industry, every Custom Picklist. The Data Migration wizard rejects values not in the destination picklist and surfaces a per-row error in the result CSV ²².
• Save every CSV as UTF-8 before upload. Non-UTF-8 files produce garbled accented characters in candidate names or full row rejection on Russian or Czech character sets ²⁰. Excel saves as Windows-1252 by default on Western locales — explicitly choose *CSV UTF-8* on Save As.
• Stamp a stable external ID on every candidate, job and application in the source export — a UUID or the source platform's primary key — so re-runs and reconciliation are deterministic. This value populates the Recruit field you mark as the upsert find_by field ²³.
• Decide what is in scope for historical activities and resume files. Tasks, Calls and Events can be imported; resume files attach per record and count against tier-tied storage ³⁰. Backdated CV uploads are common; backdated Created Time is not ⁵¹.
• Ensure the Last Name column is populated on every Candidate, Contact and Client row. Last Name is a hard mandatory in Zoho Recruit and rows missing it are silently skipped — Zoho's own migration guide tells you to fill blanks with not provided or none ⁵⁵.

Destination-side prep

• Provision Users, Profiles and Roles before importing — owner assignment falls back to the importing user if a referenced user email does not exist in Recruit, and historical attribution is broken for every affected record ⁵².
• Add at least one extra user before migration. Zoho's own checklist warns that the Data Migration wizard requires more than a single user in the destination account before it will let you start ⁵⁵. Bulk-import the remaining users via CSV under *Setup → Users & Control → Users*.
• Pre-create every custom field on the right Module and Layout with the right type — Field Type cannot be changed after creation (you cannot turn a Text field into an Integer later) ¹⁶.
• Build the Hiring Pipeline, its Stages, and the Candidate Statuses mapped to each Stage before importing Applications. The Hiring Pipeline lives at *Setup → Hiring Pipeline* (or *Setup → Customization → Hiring Pipeline* on the older Applications module flow) and rejects rows whose status is not mapped to a stage ⁵¹.
• Define Custom Modules, their unique-ID fields, and their Lookups before importing. Custom Module schemas must exist before records of that type can be created, and Custom Modules are gated to Enterprise, Zoho One and People Plus editions ⁴⁹.

People prep

Cutover only works if humans cooperate. Lock down a source-system freeze window — typically 24 to 72 hours — and communicate it to every recruiter, hiring manager and client-facing user who touches the ATS. Train recruiters on Zoho's daily-workflow patterns, Application stage transitions and Blueprint enforcement before go-live, not after. A clean Freshteam-to-Recruit or Workable-to-Recruit migration of under 10,000 candidates lands inside one business day; a Bullhorn-to-Recruit with Custom Modules, Vendor portal and Submissions history runs two to four weeks.

Zoho Recruit exposes two load paths and the right one depends on dataset size, Module mix, and whether the load must be re-run idempotently. The native Import wizard handles most one-shot migrations under a few hundred thousand records. The Data Migration wizard adds source-ATS auto-mapping.

Native Import wizard

The per-Module Import wizard lives at the top right of any Module list view, or under *Setup → Data Administration → Import* ²². It accepts CSV (UTF-8), XLS, XLSX and VCF ⁴⁴. Each Module is imported as a separate file. The wizard maps columns to fields, lets you choose Skip / Overwrite / Clone behaviour for duplicates (Skip and Overwrite require paid editions), sets a Workflow Task, and runs a sample before committing the full file.

Specific to Recruit, the wizard exposes an *Assign all imported Candidates to this Candidate Source* dropdown — use it to stamp every row in a batch with its origin source (LinkedIn, Indeed, Employee Referral, Career Site) without populating the source column on every row ²². There is also an *Enable Manual Lead Approval* option that holds imported candidates in a pre-assigned state until an admin signs off ²².

Per-file limits are edition-tiered and run alongside Zoho's general CRM-family limits: CSV files up to a few MB on Free, larger files on paid editions, with the wizard splitting larger ranges across multiple batches. The right call: the Import wizard for one-shot loads under 100,000 records on standard Modules, or whenever you want a visual mapping review before commit.

Data Migration wizard

The Data Migration wizard, under *Setup → Data Administration → Data Migration*, is the larger-scope tool. It supports two source paths: Zoho Recruit (account-to-account transfer between two Recruit orgs) and Other ATS (CSV/zip upload with auto-Module-creation) ⁵⁵. The wizard inspects the uploaded files, proposes destination Modules, and creates any Module that does not exist on the target — driven by a button literally labelled *+Create New Module* on the field-mapping screen ⁵⁶.

Zoho's own marketing page lists Bullhorn, CATS, JobDiva and Workable as previously completed migration sources; the engine itself is source-agnostic as long as you can produce CSV ⁵⁶. The wizard is the right pick when the source is a one-shot CSV-shaped load and the team wants minimum manual mapping. It is the wrong pick when the migration requires repeated dry-runs over weeks or reconciliation against a parallel source-of-truth.

Third-party staging tools

Tools like Fivetran, Airbyte, Zoho DataPrep, Workato and Make sit between source and destination. They are used in two ways: (a) reverse-ETL where the source loads into a warehouse, gets transformed in SQL, then syncs into Recruit; and (b) staging-and-validate, where the tool handles type coercion, candidate-name normalisation and dedup before the result feeds the importer ⁴⁰.

Mapping is where every ATS migration earns its scars. Schema decisions in your mapping spreadsheet determine whether reports work on day two, whether Blueprint fires on day five, whether interview scorecards roll up on day fifteen, and whether recruiters trust the candidate database on day thirty.

Work Module by Module in import order: Users first, then Clients (Staffing) and Contacts so Job Openings can associate, then Job Openings, then Candidates, then Applications/Submissions, then Interviews, then Offers, then Activities and Notes, then Custom Modules. The Data Migration wizard enforces this implicitly with its module-detection step ⁵⁵; through the Import wizard, you enforce it by file order.

Candidates — the core ATS record

Candidates is the heart of every ATS migration. Zoho Recruit ships a built-in Resume Extractor that parses uploaded resume files into Candidate fields (Name, Email, Phone, Experience, Skills, Education) automatically ⁵⁸, but this only fires on resumes uploaded *after* the candidate record exists. The reliable pattern is to import a clean Candidates CSV first, then attach resume files in a second pass ³³.

Resume files and historical attachments

Resume files do not import in the CSV flow. The supported path is per-record attachment — one binary at a time, associated to the candidate by Record ID ³³. The per-record attachment cap is 20 MB total across all files on a Candidate record ²⁹, with email-template attachments capped at 3 MB ²⁹.

The File Upload field type is hard-capped at 5 fields per form ²¹, so for onboarding flows that need 10+ documents (right-to-work, NDA, references, certifications, EEOC self-id), use general Attachments rather than File Upload fields.

Storage is edition-tiered: Free 256 MB, Standard 1 GB default plus 256 MB per new user, Professional 2 GB plus 512 MB per user, Enterprise 3 GB plus 1 GB per user ³⁰. Resume files at an average of 500 KB each consume storage fast — 5,000 resumes is roughly 2.5 GB before any attachments.

For large historical estates, the pattern most teams adopt is: keep originals in S3 or Zoho WorkDrive, store a deep link in a custom URL field on the Candidate record, and only inline-upload the current active subset.

Job Openings and the Hiring Pipeline

Recreate the Hiring Pipeline, its Stages, and every Candidate Status mapped to each Stage in Zoho before importing any Application or Submission. The Hiring Pipeline lives at *Setup → Hiring Pipeline* on accounts with the Applications module enabled, or *Setup → Customization → Hiring Pipeline* on the older version ⁵¹. Default stages are Screening, Interview, Hired, Rejected and Archived; each stage owns a set of statuses (for example, *Submitted to Client* and *Rejected by Client* live under *Client Review*).

The mapping rule is one-way: a Candidate Status must be mapped to a Stage for that status to appear in the pipeline view ⁵¹. Unmapped statuses are imported successfully into the Candidates module but disappear from pipeline reporting until mapped. Also note: *Mapping or unmapping a status changes the Modified Time field's value for every record with that status* ⁵¹ — do all your pipeline-status remapping before the production import, not after.

Applications / Submissions — stage transition history

Applications (the join record between a Candidate and a Job Opening) carry their own stage history through the Application Status field. Stage transition history does not migrate natively — Zoho only records the current Status and the Modified Time. To preserve historical stage-entry timestamps, create one Date-Time custom field per stage on the Applications module (*Screening Entered*, *Phone Screen Entered*, *Onsite Entered*, *Offer Sent*, *Hired*) and back-fill from the source export's stage transition log.

For Staffing Agency edition, Submissions to clients are tracked through the same Applications module with status values like *Submitted to Client*, *Approved by Client*, *Rejected by Client* — all of which the Hiring Pipeline groups under *Client Review* ⁵¹. Preserve the source's submission-sent-to-client date in a custom *Submission Date* field; the current Application Status on import will not carry that timestamp.

Interviews and scorecards

Interviews live in their own Module with required fields *Interview Name*, *From Time*, *To Time* and a Lookup to the parent Candidate (and optionally Job Opening). Build a multi-file load: parent records first, then a separate Interviews file carrying the Candidate Record ID or External ID in the lookup column, with From Time and To Time in the org locale date-time format ¹⁶.

Interviewer Assessments — Zoho's scorecard feature — supports three rating types: Star (1–5), Thumb (up/down), and Numerical ⁵⁷. These do not migrate as data; the scorecard *template* (sections, criteria, rating type) is configured in *Setup → Customization → Assessments* before the first interview record imports. Historical interviewer ratings from the source typically land as text in a custom Notes field per interview record, then go forward into Zoho's native rating system from the cutover date.

Candidate sources, EEOC and self-identification fields

Candidate Source is a picklist on the Candidate record (Indeed, LinkedIn, Employee Referral, Career Site, Vendor, Direct). For source taxonomy that needs more depth than a single picklist — campaign source plus medium plus referrer — add a Custom Picklist *Source Detail* alongside the standard *Source* field, and use field dependency mapping to gate the child values.

EEOC self-identification fields (Gender, Race/Ethnicity, Veteran Status, Disability Status) are not standard on Zoho Recruit — they are added as custom picklists on the Candidates module with the picklist values matching the US EEO-1 categories. Mark these fields as field-level-restricted to admin and EEOC-compliance roles via Profile permissions so they do not appear on recruiter views or careers-site form payloads. For HIPAA-adjacent health information, Zoho Recruit supports a *health* module flag that restricts export of fields tagged as health-relevant ⁵⁰.

Vendor portal and Career Site post-import

Staffing Agency edition exposes a Vendor portal where external recruiting agencies log in and submit candidates directly into the Vendors-owned section of the Candidates module ⁵⁸. Migrate Vendors first (Vendor Name, contact details, agreed split percentage), then send portal invitations after go-live — do not enable Vendor portal during the import window, or you will get duplicate candidate submissions racing against the historical load.

The Career Site is a white-label careers page that publishes Job Openings flagged *Published* with a unique URL; the Forms Builder captures applicants directly into the Candidates module. Both are configured post-migration; the application-from-career-site path will use a default Candidate Source value you set during configuration.

Audit trail, ownership and original timestamps

Zoho Recruit's standard Created Time and Modified Time fields are system-managed on most Modules and cannot be overwritten on import — they stamp to the moment the row was processed ⁵¹. To preserve the original audit trail, create custom Date-Time fields *Legacy Created Date* and *Legacy Modified Date* on every Module and populate from the source export, then rewrite historical reports to filter on the legacy fields.

Record ownership during import works through a Field Mapping column on Owner — Zoho resolves the value against existing user email or user ID; rows whose owner cannot be resolved silently fall back to the importing user ⁵². Pre-provisioning all users (including the deactivated ones from the source if you need their historical attribution) and adding their emails to the source export's Owner column is the only reliable defence.

Account-level Audit Log under *Setup → Data Administration → Audit Log* captures Add, Update, Delete, Import, Export, Lead Conversion, Rollback, Restore, and Find-and-Merge actions across Candidates, Clients, Contacts, Job Openings and Interviews, plus configuration changes to Workflows, Profiles and Layouts ⁴². Files imported within the last 60 days appear in Import History; detailed added/updated/skipped lists are retained for 7 days post-import, after which only the aggregate counts remain ⁴¹.

ATS-specific: Workflow, Blueprint, Zia AI, and Resume Extractor

Workflow Rules, Blueprint state machines, Assignment Rules, Scoring Rules and Macros do not import. Recreate the source's process gates as Blueprint transitions in *Setup → Process Management → Blueprint*, mapping the source's stage-permission rules to Blueprint *Transition Settings*. Rebuild Assignment Rules under *Setup → Automation → Assignment Rules*. Validation Rules under *Setup → Customization → Validation Rules* enforce data quality at save time — recreate from documentation ¹⁵.

Zia AI is Zoho's machine-learning layer for candidate matching, sentiment analysis and fit scoring. It learns from production data on the destination, so it does not import — give it 30 to 60 days of post-migration activity before relying on Zia scores in recruiter workflows. Deluge custom functions are the in-platform scripting layer and the right place to write post-migration glue logic (de-dup loops, batch-tagging, legacy-ID lookups, vendor-portal pre-checks).

Email integration with Zoho Mail, Gmail, Outlook or any IMAP inbox happens through *RecruiterInbox* configured per user post-migration ³². Do not enable email sync during the import window, or you will get a flood of duplicate emails as the connector backfills against the same candidates you are loading.

Validation is the bridge between the import finishing and recruiters being allowed in. The pattern that works on Zoho Recruit is three stages: a dry-run on 5–10 percent of records with stakeholder spot-checks; a production load with real-time monitoring of Import History per Module; and a 30-day post-migration data-quality audit. Recruiters verifying their own assigned candidates is the most reliable signal — they know what *right* looks like.

Build a reconciliation queries spreadsheet that compares source and destination on each count. Anything outside a 0.5 percent variance gets investigated before users get login access.

• Total records per Module imported vs source — Import History under *Setup → Data Administration → Import History* lists added, updated and skipped counts per file for 60 days post-import ⁴¹.
• Total Candidates per Status vs source, and total Applications per Hiring Pipeline Stage — a non-trivial variance signals a status-not-mapped-to-stage problem ⁵¹ or a picklist-value-not-on-destination skip.
• Total Job Openings per Job Opening Status vs source — confirm Filled, In-progress, On-Hold and Cancelled counts match before recruiters start working open requisitions.
• Total Interviews and Activities per Module (Tasks, Calls, Events) imported vs source — and a date-bucketed comparison to confirm From Time, To Time and Activity Date round-tripped through the locale date format ¹⁶.
• Lookup integrity per Module pair — count Candidates with a populated Application Lookup, Applications with a populated Job Opening Lookup, Job Openings with a populated Client Lookup (Staffing). Any null lookups indicate a parent-import order issue.
• Owner distribution — group by Candidate Owner and confirm no Module landed with the import-running user owning the majority of records (the silent fallback signature) ⁵².
• Duplicate-check field integrity — count distinct Email on Candidates and Contacts, distinct Client Name on Clients; any duplicates indicate the dedup transform missed cases that Zoho's import then merged.
• Resume file attachment count vs candidate count — confirm every Candidate that should have a resume actually has one attached, since the resume-upload pass runs after the Candidate import and can fail silently on storage-tier overflow ³⁰.

On top of reconciliation, run a manual spot-check protocol: pick 30 random candidates across Statuses and verify each field plus the attached resume against the source UI. Trace the full Lookup graph on five high-value Job Openings — Client, hiring-manager Contact, all Applications and their Candidates, scheduled Interviews. If a discrepancy shows up in three or more of the 30, halt the load, fix the root cause, and re-import by Record ID or External ID.

Zoho Recruit ships an Undo Import option directly inside Import History — entries from the last 60 days expose an Undo action that reverses the import for that file ⁴¹. The catch is that detailed undo metadata (added / updated / skipped lists) is retained for only 7 days after the import, and after 30 days the import action is locked and confirmed automatically with no further undo ⁴¹. Any rollback decision needs to happen inside the 7-day window.

After the 7-day window, your fallback is the same as on any ATS: export everything before the import, stamp every imported row with an *Import Batch ID* custom field, and bulk-delete by that batch ID if catastrophe strikes. Recycle Bin and Restore sit alongside Undo Import: deleted records can be restored individually or in bulk for 60 days before permanent purge ⁴².

Audit Log under *Setup → Data Administration → Audit Log* tracks every Add, Update, Delete, Import, Export, Rollback and Restore action for the last 60 days, scoped by Administrator profile (full) or own-and-subordinate (other profiles) ⁴². Export to CSV for longer retention before the 60-day window closes.

Cutover sequencing: (1) source ATS goes read-only and recruiters are notified; (2) final delta export captures every candidate, application and interview that changed during the test-import window; (3) delta is imported via the same Data Migration flow; (4) reconciliation runs against the delta; (5) recruiters get login access and a 48-hour hyper-care window with the migration lead on call; (6) source decommission is scheduled for 30 to 90 days out, never the same day.

The Zoho Partner Program credentials Authorized, Advanced and Premium Partners through certifications, customer count and revenue tiers, and exposes them through the Find a Zoho Partner directory at zoho.com/partners ³⁸. For Zoho Recruit specifically, partners with explicit Bullhorn-to-Recruit, JobDiva-to-Recruit, Workable-to-Recruit or Freshteam-to-Recruit practices tend to ship cleaner than generalist Zoho implementation shops.

Zoho also runs an in-house Recruit migration team reachable through the migration-request form at zoho.com/recruit/migration-request, which handles complex Bullhorn, CATS, JobDiva and Workable migrations directly, often at no incremental fee on Enterprise or Zoho One contracts ⁵⁶. The trade-off is throughput — the in-house team is best for clean source schemas and lighter customisation; deeper Custom Module work, Blueprint rebuilds, Vendor portal configuration and historical Application stage history tend to land with the certified-partner channel.

On the ETL and iPaaS side, Fivetran, Airbyte, Stitch, Workato, Make, Zoho Flow and Zoho DataPrep all sit alongside Zoho Recruit migrations ⁴⁰. Their role in a migration is rarely the migration itself — it is the staging layer that lands source data into a warehouse, the transformation layer that converts picklist values and resolves owner emails, and the ongoing-sync layer that takes over once the one-time migration is complete.

Make and Workato are common picks where the migration is bundled with workflow rebuilds; Fivetran and Airbyte are more common where the warehouse is the long-term source of truth. Zoho DataPrep sits closest to the import boundary and is the right tool when the team wants AI-assisted dedup and standardisation directly inside the Zoho stack ⁴⁰.

Managed-migration cost ranges vary widely. A clean Freshteam-to-Recruit or Workable-to-Recruit move of under 10,000 candidates with no historical Submissions and standard Modules only often lands in the $2,500–$8,000 range with a setup fee plus per-Module pricing. A Bullhorn-to-Recruit project with Custom Modules, Vendor portal setup, Blueprint rebuilds, historical Applications and resume-file migration typically runs $15,000–$80,000 — driven by candidate count, custom-field complexity, historical depth, vendor multi-tenancy, and integration rebuild count.

For teams that want to outsource the migration end-to-end, FlitStack specialises in Zoho Recruit migrations and handles the Hiring-Pipeline-to-Status mapping, picklist alignment, duplicate-check upsert wiring, Created-Time-to-Legacy-Date custom-field pattern, resume-file attachment pipeline, owner-resolution pre-checks, and the reconciliation work in Sections 5 and 7 of this guide. Pricing is fixed-fee based on candidate count and source ATS, with separate line items for Custom Modules, Vendor portal, historical Applications and Blueprint rebuilds.

This is one of several legitimate paths — the right choice depends on whether the team wants a Premium Partner, Zoho's in-house migration team, an iPaaS-first approach, or a specialist vendor. Explore FlitStack →