Migrate from Bright to Zoho CRM

Zoho API credit consumption can throttle large-volume migrations if not paced correctly

Zoho's API credit system limits how many requests per day your organization can make, varying by plan tier (Enterprise caps at 10,000 API credits per day; Ultimate at 10,000 plus add-ons). Each migration operation — get, create, update, bulk — deducts a specific number of credits documented in the Zoho API limits table. A migration pulling 200,000 Bright contacts without pacing will exhaust API credits mid-run and return HTTP 429 errors. FlitStack AI monitors credit usage headers (X-API-CREDITS-REMAINING) on each response and implements exponential back-off when credits fall below 50% of the daily limit, resuming automatically when credits replenish. This pacing adds processing time but prevents partial migration failures that would require reconciliation runs.

Zoho does not track field-change history — original stage-transition timestamps require custom fields

Bright records deal stage-change events with timestamps, letting you report on how long a deal spent in each stage. Zoho CRM's standard Deal record does not maintain a field-history audit log for stage changes — the Stage pick-list value updates in place without preserving the prior state or the timestamp of the change. If deal-stage timing reports are part of your Bright reporting practice, you must request a Zoho developer to create a custom stage-history tracking solution (typically a related module or Zoho Analytics configuration) after migration. FlitStack surfaces this gap in the pre-migration audit so your team can budget for the post-migration analytics rebuild.

Bright multi-select pick-lists require pre-creation of every distinct value in Zoho before data loads

Bright allows freeform tagging on contacts, companies, and deals with no enforced pick-list — a contact might have tags that have accumulated over years of use. Zoho's multi-select pick-list fields require all possible values to be pre-defined as pick-list entries in Zoho's field metadata before records can be saved. If your Bright database contains 200 unique tags, all 200 must be created as Zoho pick-list values before the migration run. FlitStack extracts the full set of unique tag values during the pre-migration audit, generates the Zoho API calls to create them, and executes those calls before the first data load — but this phase adds 1–3 hours to the timeline and must be completed before any record containing those tags is processed.

Zoho enforces a 300-field limit per module — custom field consolidation required for dense Bright schemas

Zoho CRM limits each module (Leads, Contacts, Accounts, Deals, Tasks) to 300 fields total, including both standard and custom fields. Bright implementations with heavy custom-field usage — particularly in mid-market companies that have extended their schema over several years — can exceed this limit when migrated directly. FlitStack's pre-migration audit compares Bright's custom field count per module against Zoho's 300-field ceiling. If consolidation is required, we work with your team to identify redundant or deprecated fields that can be merged or dropped before migration. This decision requires business input and is not automated — we present the consolidation options and your team approves the field reduction plan before data migration begins.

Zoho Bulk API exports require pagination with 200 records per page — large Bright datasets need chunking

Zoho's Bulk Read API (used for exporting large datasets from Bright via its CSV export) processes records in pages of up to 200 records per request, with a maximum of 10 download requests per minute before rate-limit errors occur. Bright datasets with 100,000+ records across modules require a chunked export strategy — we paginate through Bright's export, accumulate records in staging, transform them, and batch-load to Zoho. A migration of 500,000 Bright records typically requires 2,500 API round-trips and 250 minutes of processing time at the maximum safe throughput rate, plus transformation overhead. This is factored into the timeline estimate during scoping, but it is a hard constraint that cannot be accelerated by adding concurrency.