Data Migration from Salesforce to Bitrix24

The Challenge and Why Direct Migration Isn't Feasible

Salesforce stores data in its object model: Account, Contact, Lead, Opportunity, Task, Event. Each can have hundreds of custom fields. There is no direct import between Salesforce and Bitrix24. A successful Salesforce and Bitrix24 integration requires careful mapping and an intermediate layer: export through Salesforce API or Data Export, data transformation, and upload via Bitrix24 REST API. We have accumulated experience from dozens of successful migrations and guarantee data integrity. Typical migration costs for small businesses start at $1,500, while medium-sized projects range from $4,000 to $8,000. Our contact transfer from Salesforce ensures all records are correctly linked. Order a turnkey migration — we will evaluate your project in 1 day.

Salesforce uses its own object model with unique identifiers. Bitrix24 operates with its own structure of information blocks and CRM entities. Differences in field types (lookup, picklist, formula), phone number formats, and addresses require mandatory transformation. Additionally, Salesforce accumulates garbage: deleted records, duplicates, empty fields. Without a preliminary audit, a direct transfer will lead to errors.

Data Structure Analysis and Object Mapping

Step 1: Audit of actually used data. A typical Salesforce account accumulates years of garbage: deleted records in the trash, duplicate contacts, outdated fields with zero fill. Before migration, we:

• Export the object schema via describeSObjects() API and create a mapping to Bitrix24 entities. This Salesforce object mapping is crucial for custom fields.
• Check volumes: Salesforce Data Export provides CSV files split by object. Relationships between records (lookup fields) are stored as Salesforce IDs — they need to be resolved into new Bitrix24 IDs.
• Evaluate custom objects: they may not have a direct equivalent in Bitrix24. For these, we create custom fields or separate CRM sections.

Mapping of base objects:

Migration Process: Export, Transform, Upload

1. Export from Salesforce using Data Export or Bulk API.
2. Transform the data: map objects, convert field formats, resolve owner IDs.
3. Upload to Bitrix24 in correct order: companies, contacts, then deals.
4. Verify the migrated data and fix any issues.

Export from Salesforce

We use two methods:

• Data Export (Setup → Data Export) — full dump in ZIP with CSV. Convenient for one-time migration, but the export takes up to 48 hours. For large volumes, files are split by object.
• Salesforce API (REST/Bulk API 2.0) — preferred for large volumes (from 50,000 records). Bulk API 2.0 works asynchronously: create a job, upload data, wait for execution, download the result. We recommend Salesforce API export for any migration over 10,000 records.

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

Data Transformation

This is the most time-consuming stage. Common issues:

• Phone numbers: Salesforce stores them in arbitrary formats; Bitrix24 accepts them via crm.contact.update in the PHONE field as an array with type WORK/MOBILE/HOME.
• Addresses: Salesforce uses a flat structure (BillingStreet, BillingCity); in Bitrix24, company address is stored via crm.address.add with ENTITY_TYPE_ID=4.
• Users: The record owner (OwnerId) must be mapped to Bitrix24 users via user.get by email or name.
• Multi-select picklists: Converted to separate custom fields in Bitrix24.

Upload to 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 at once). Bitrix24 REST API migration is efficient with batch processing.
• Order is critical: companies first, then contacts (to set COMPANY_ID), then deals.
• Save the mapping of Salesforce ID → Bitrix24 ID in an intermediate table — needed for linking tasks, events, and files.

Which Data to Migrate First

Primary: companies and contacts — they form the basis for all other entities. Then deals and leads. Activity history and attachments come last, as data volume can be significant. Emails, calls, meetings from Salesforce Activity History are migrated to Bitrix24 as CRM activities (crm.activity.add). Attached files — via crm.timeline.comment.add with base64 encoding or pre-upload via disk.folder.uploadfile. The volume of attachments is often a surprise: 5–10 years of work in Salesforce can easily yield 50–100 GB of files. This requires a separate strategy: either selective migration (only last N years) or archive access to Salesforce remains during the adaptation period.

Post-Migration Support and Services

After the transfer, a verification phase is mandatory: spot-check records, verify linkages, test notifications and automations in Bitrix24. Parallel operation in both systems during the transition period is standard practice. Contact us for a consultation and accurate estimate of your project. Bulk API 2.0 is 5 times faster than standard REST API for volumes over 50,000 records. Our engineers' experience is backed by certifications and dozens of successful projects.

Migration Timeline

What's Included in Our Migration Service

• Data schema analysis report with field mappings
• Secure extraction and transformation of all selected data
• Full upload with batch processing and error handling
• Validation report comparing record counts and linkages
• Two weeks of post-migration support and issue resolution

Why Choose Our Team

With over 10 years of experience in CRM migrations and 50+ successful projects, we ensure a smooth transition. Our process is transparent, and we provide a detailed timeline upfront. We handle all aspects, including Salesforce deal migration and Salesforce task migration, ensuring no data is lost.

Wikipedia: Salesforce — Salesforce API documentation

Note: Prices vary by data volume and complexity. Contact us for a custom quote.

Why URL Structure Matters in Bitrix Migration?

Skipping URL mapping during a website migration to Bitrix crashes organic traffic by 50–80% in two weeks. WordPress uses /product/item-name/, OpenCart uses /index.php?route=product/product&product_id=123, Bitrix defaults to /catalog/section/element/. Without a 301 redirect map, search engines index mass 404s. We start every migration with Screaming Frog scanning the old site, then compile a complete redirect map before writing a single line of code. Proper migration requires full URL mapping — every indexed page gets a correspondent.

Over seven years we have completed 50+ projects: landing pages, catalogs with 300,000 products, e‑commerce stores. Typical duration 2–8 weeks. Contact us for a free project estimate within one day.

How Migration Preserves SEO Positions

Losing organic traffic is the biggest fear, and it's justified. Here is how we avoid it.

• URL mapping 1:1 — where possible, via CUrlRewriter and infoblock SEF settings we keep the exact structure. When impossible — 301 redirect. Auto‑generation of redirect map: parse Screaming Frog export, match with new element slugs, generate nginx config. Each redirect verified with curl -I after switching.
• Transfer of meta tags — title, description, h1 moved into properties ELEMENT_META_TITLE and ELEMENT_META_DESCRIPTION. Canonical via Bitrix SEO component. Duplicates cut: www/non‑www, http/https, sorting parameters. Sitemap: new sitemap.xml generated by Bitrix seo module, submitted to Search Console immediately after DNS switch.
• Speed comparison — Bitrix processes a catalog of 100,000 products 3x faster than OpenCart due to tagged caching and query optimization for b_catalog_product.

What Data Gets Transferred?

Content — pages, articles, news → information infoblocks. Catalog: categories → sections, products → elements linked to b_catalog_product, properties → infoblock properties or highload directories. Images, reviews, FAQ.

E‑commerce — products with trade offers (SKUs), prices in b_catalog_price (multi‑currency via b_catalog_currency), stock balances b_catalog_store_product, discounts (b_sale_discount), order history (b_sale_order + b_sale_basket).

Users — client base b_user plus custom UF fields. Passwords are hashed differently: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. We write a custom CUser::LoginByHash with fallback to old algorithm — client enters password once, system rehashes to Bitrix bcrypt.

SEO data — meta tags, alt attributes, URL structure. Main task: preserve every indexed URL or set 301.

Media — images, documents, videos — transferred preserving paths and optimized via CFile::MakeFileArray().

How to Plan a Successful Migration: 5 Key Steps

1. Audit — scan with Screaming Frog: all URLs, status codes, meta tags. Analyze DB structure, custom modifications, integrations. Create migration map.
2. Architecture design — map content types → infoblocks, fields → properties, directories → highload blocks. Architecture must be convenient for Bitrix administration.
3. Migration scripts — PHP scripts read from old DB (or API), transform and write via Bitrix API (CIBlockElement::Add, \Bitrix\Sale\Order::create). Re‑run during testing.
4. Staging — full migration to test server. Verify integrity: product count, properties, URLs, filters.
5. Final migration & switching — delta import, DNS switch, monitoring.

Typical Migration Mistakes and How to Avoid Them

Each of these errors has caused loss of positions and clients.

• Loss of URLs without redirects — the most destructive mistake. /product/123 instead of /catalog/item-name.html — without 301 this means mass 404s and traffic collapse. We auto‑generate the map and verify every redirect after switching.
• Content duplication — one product accessible with and without www, via HTTP and HTTPS, with GET filter parameters → five URLs instead of one. SEO weight dilutes. Set up canonical, 301 for variants, robots.txt with Disallow for parameters.
• Broken images — absolute URLs in content (src="https://old-site.ru/img/photo.jpg"), quality loss during compression. Replace with relative paths, transfer preserving structure, check HTTP 200 for each file.
• Loss of meta tags and microdata — title, description, Schema.org may not transfer. Do full mapping and verify on staging.
• Broken forms and integrations — changed IDs, API keys, webhooks. Compile integration register before start and test each after.
• Mobile version — old m.site.ru → responsive Bitrix. Without mobile URL redirect → 404 for mobile users. Include in redirect map.

Timelines and Cost Savings

Businesses typically save $3,000–$8,000 annually after migration — no old CMS license fees, reduced plugin and hosting costs. Annual hosting savings alone can reach $1,200. Add the affordable licensing cost of 1C‑Bitrix — it pays off quickly.

Contact us for a free migration estimate. We also provide a preliminary calculation within one day — request a consultation with our Bitrix specialists.