Migrate from Bitrix24 to HighLevel

Discovery and scoping

We audit the source Bitrix24 account: plan tier (free, Basic, Standard, Professional, Enterprise), user count, pipeline count, Smart Process list, and custom field schemas for Contacts, Companies, Deals, and Leads. On the GoHighLevel side we confirm the destination plan (Starter, Unlimited, or SaaS Pro), the number of existing Sub-accounts, and whether the customer needs a new Sub-account created for the migrated data. The output is a written migration scope document that includes the record count estimate, Smart Process inventory, and a GoHighLevel Sub-account plan.

API credential setup and rate-limit calibration

We provision OAuth 2.0 access tokens for the Bitrix24 REST API and the GoHighLevel API 2.0. Bitrix24 Standard plan enforces a 50-request burst limit per application, which we handle with request throttling and exponential backoff using the leaky-bucket response code QUERY_LIMIT_EXCEEDED. GoHighLevel's API 2.0 burst limit is 100 requests per 10 seconds per app per Location, with a 200,000 daily cap. We calibrate batch sizes and retry logic against both envelopes before any data moves.

Smart Process schema documentation and GoHighLevel rebuild plan

We read every Bitrix24 Smart Process via crm.item.{entity_code}.list to document the entity name, field list, field types, and any lookup dependencies. Since GoHighLevel has no custom object API, we deliver a written schema specification for each Smart Process and recommend a Custom Value and Tag implementation approach in GoHighLevel. The customer's admin reviews and approves the rebuild plan before migration begins; we do not attempt to force Smart Processes into GoHighLevel's Contact or Opportunity objects as a schema approximation.

Pipeline and stage mapping design

We read the existing Bitrix24 pipeline schema via crm.pipeline.list and crm.stage.list, then design the GoHighLevel Pipeline and Stage structure. Stage probabilities are rounded to integers. If multiple Sub-accounts exist in GoHighLevel, we apply the pipeline schema to the relevant Location. Pipeline assignments per Deal are resolved by matching the pipeline name and stage label to the destination configuration before the Deal import begins.

Sandbox migration and reconciliation

We run a full migration into a GoHighLevel test Sub-account using production data volume. The customer reconciles record counts (Contacts in, Deals in, Products in), spot-checks 20-30 records against the Bitrix24 source, and confirms the pipeline mapping before production migration begins. Smart Process rebuild scope is reviewed against the written documentation. Any corrections to field mapping, stage names, or Sub-account assignments happen here.

Production migration in dependency order

We run production migration in record-dependency order: GoHighLevel Users (validated against Bitrix24 owners by email), Products (required for Opportunity line items), Contacts (from Bitrix24 Companies and Contacts merged and deduplicated), Opportunities (with Pipeline, Stage, Amount, and OwnerId resolved), Leads (imported as Contacts with source tag), Custom Values (from Bitrix24 custom fields), and then any accessible activity or note history as Notes or Custom Activities. Each phase emits a row-count reconciliation report before the next phase begins.

Cutover, validation, and automation rebuild handoff

We freeze Bitrix24 writes during cutover, run a final delta migration of any records created or modified during the migration window, then enable GoHighLevel as the system of record. We deliver the Smart Process rebuild inventory, the Bitrix24 automation workflow list (for manual rebuild in GoHighLevel Workflows), and the funnel and form rebuild scope document. We do not rebuild Bitrix24 workflows, automations, or funnels inside the migration scope; that work is a separate engagement.