Migrating data from Salesforce to Bitrix24

Data Migration from Salesforce to Bitrix24

Salesforce stores data in its own object model: Account, Contact, Lead, Opportunity, Task, Event — and each object can have hundreds of custom fields tailored to a specific business. There is no direct import path between Salesforce and Bitrix24. The task is solved through an intermediate layer: export via Salesforce API or Data Export, data transformation, then loading via the Bitrix24 REST API.

Analyzing the Salesforce Data Structure

The first step is auditing what is actually in use. A typical Salesforce account accumulates years of garbage: deleted records in the recycle bin, duplicate contacts, obsolete fields with zero fill rate. Before migrating:

• Export the object schema via describeSObjects() API and build a mapping to Bitrix24 entities
• Check volumes: Salesforce Data Export produces CSV files split by object, but relationships between records (lookup fields) are stored as Salesforce IDs — these must be resolved to new Bitrix24 IDs
• Assess custom objects (Custom Objects): they may have no direct equivalent in Bitrix24 and will require creating custom fields or separate CRM sections

Base object mapping:

Technical Migration Process

Export from Salesforce can be done in two ways:

1. Data Export (Setup → Data Export) — a full dump as a ZIP containing CSVs. Convenient for a one-time migration, but the export takes up to 48 hours to generate and large datasets are split into per-object files.
2. Salesforce API (REST/Bulk API 2.0) — preferred for large volumes (50,000+ records). Bulk API 2.0 works asynchronously: create a job, upload data, wait for completion, download the result.

POST /services/data/v58.0/jobs/ingest
{
  "operation": "query",
  "query": "SELECT Id, Name, Phone, BillingCity FROM Account WHERE IsDeleted = false"
}

Data transformation — the most labor-intensive phase. Issues that almost always arise:

• Phones in Salesforce are stored in arbitrary formats; Bitrix24 accepts them via crm.contact.update in the PHONE field as an array with type WORK/MOBILE/HOME
• Addresses in Salesforce are flat (BillingStreet, BillingCity); in Bitrix24 a company address is stored via crm.address.add linked to ENTITY_TYPE_ID=4 (company)
• Users: the record owner in Salesforce (OwnerId) must be matched to Bitrix24 users via user.get by email or name

Loading into Bitrix24 via REST API:

• crm.contact.add / crm.company.add — add one record at a time; for large volumes use the batch method (up to 50 requests per call)
• Load order is critical: companies first, then contacts (so COMPANY_ID can be set), then deals
• Save the Salesforce ID → Bitrix24 ID mapping in an intermediate table — it is needed to attach tasks, events, and files

Interaction History and Attachments

Emails, calls, and meetings from Salesforce Activity History are migrated to Bitrix24 as CRM activities (crm.activity.add). Attached files are transferred via crm.timeline.comment.add with base64 encoding, or by pre-uploading via disk.folder.uploadfile.

Attachment volume is often a surprise: 5–10 years of Salesforce usage can easily produce 50–100 GB of files. This requires a separate strategy: either selective migration (last N years only), or keeping Salesforce accessible in read-only mode during the adaptation period.

Typical Timelines

After migration is complete, a verification phase is mandatory: spot-check records, validate relationships, test notifications and automations in Bitrix24. Running both systems in parallel during the transition period is standard practice.