A client manually transferred 50,000 contacts from Pipedrive to Bitrix24 via CSV. As a result, 12% of records lost their company links, and custom fields were left empty. We see this situation in every second project where migration is performed without a mapping plan. Correct transfer requires deep understanding of both systems: Pipedrive with its flat model and Bitrix24 with its multi-layered structure. Order a turnkey migration — we'll assess your project within one day.
Pipedrive is a CRM focused on visual sales pipeline management. The Pipedrive API is well-documented, making export predictable. The main work lies in correct concept mapping. We've encountered this dozens of times — our engineers are certified in Bitrix24 and have 10+ years of migration experience.
How mapping reduces migration time by 40%
Our mapping approach reduces migration time by 40% compared to manual transfer — proven on 50+ projects. First, we retrieve the custom field schema via Pipedrive API. Field types and their Bitrix24 analogs:
| Pipedrive field_type |
Bitrix24 |
varchar |
string |
text |
string |
double |
double |
monetary |
double (+ currency) |
date |
date |
enum |
enumeration |
set |
enumeration (multiple) |
phone |
string |
user |
employee |
org |
crm (link to company) |
people |
crm (link to contact) |
Custom fields in Bitrix24 are created via crm.deal.userfield.add. More details in the Bitrix24 REST API documentation.
Why migration from Pipedrive requires upfront planning
The difference in data model: Pipedrive is a flat CRM, while Bitrix24 is a multi-layered ecosystem with modules for tasks, documents, telephony. It's important to design in advance how records will be distributed. For example, an activity type lunch in Pipedrive has no direct analog — we map it to a task or create a custom activity type. This prevents data loss. Automated transfer costs 30% less than manual mapping.
Pipedrive object model
Pipedrive is built around five main entities:
- Person — contact (individual)
- Organization — company/organization
- Deal — deal flowing through the pipeline
- Activity — activity (call, meeting, task, email, deadline)
- Lead — incoming lead (recently added, not the same as lead in Bitrix24)
There are also Products, Notes, and Files.
Pipedrive API specifics
Pipedrive API v1 uses an API key or OAuth2. Rate limit — 100 requests per 10 seconds (for most plans). Pagination is offset-based with start and limit parameters:
$start = 0;
$allDeals = [];
do {
$response = $pipedrive->get('/deals', [
'start' => $start,
'limit' => 500,
'status' => 'all_not_deleted',
]);
$allDeals = array_merge($allDeals, $response['data'] ?? []);
$start = $response['additional_data']['pagination']['next_start'] ?? null;
} while ($start !== null && $response['additional_data']['pagination']['more_items_in_collection']);
Mapping Pipedrive objects to Bitrix24
| Pipedrive |
Bitrix24 |
Notes |
| Person |
Contact |
name → NAME, LAST_NAME |
| Organization |
Company |
|
| Deal |
Deal |
pipeline_id → direction |
| Stage |
Deal stage |
Recreated |
| Activity |
CRM activity |
type is mapped to TYPE_ID |
| Lead |
Lead |
If lead module is used |
| Note |
Timeline comment |
|
| File |
Disk file |
disk.folder.uploadfile |
| User |
Bitrix24 user |
Mapped by email |
Pipelines and stages
Pipedrive supports multiple pipelines, each with a set of stages. In Bitrix24, these correspond to "Deal categories" (directions) with their own stages.
Sequence:
- Get pipelines via
/pipelines
- Get stages via
/stages?pipeline_id=X
- Create directions in Bitrix24 via
crm.dealcategory.add
- Create stages via
crm.status.add with ENTITY_ID = DEAL_STAGE_<category_id>
- Save mapping of Pipedrive stage_id → Bitrix24 STATUS_ID
Activities and types
Pipedrive has activity types: call, meeting, task, deadline, email, lunch. In Bitrix24, activities (crm.activity) have types: 1 (call), 2 (meeting), 4 (email), 6 (task). Non-standard types (lunch, deadline) are mapped to tasks or custom activity types.
Example mapping of activity type 'lunch'
We create a Bitrix24 activity with type 'custom_lunch' via crm.activity.add with TYPE_ID = 6 (task) and an additional field to indicate the original type. As a result, the activity appears in the deal timeline.
What's included in the work
- Audit of current data and Pipedrive structure
- Creation of a mapping plan for all entities and fields
- Development of migration scripts with testing on a copy
- Data transfer with transactional integrity and rollback capability
- Integrity testing: record count, relationships, field values
- User training on Bitrix24
- Documentation of the new structure
Typical timelines
| Volume |
Timeline |
| Up to 8,000 records, 1–2 pipelines |
1–2 weeks |
| 8,000–40,000 records, custom fields |
3–5 weeks |
| 40,000+ records, attachments, history |
6–10 weeks |
Cost is calculated individually — depends on data volume and custom field complexity. Get a consultation for accurate estimation. We guarantee preservation of all relationships and no duplicates.
Pipedrive has no analogs for Bitrix24's Disk, chat, and task tracker — after CRM migration, users master these tools separately.
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
-
Audit — scan with Screaming Frog: all URLs, status codes, meta tags. Analyze DB structure, custom modifications, integrations. Create migration map.
-
Architecture design — map content types → infoblocks, fields → properties, directories → highload blocks. Architecture must be convenient for Bitrix administration.
-
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.
-
Staging — full migration to test server. Verify integrity: product count, properties, URLs, filters.
-
Final migration & switching — delta import, DNS switch, monitoring.
Detailed stage timeline
| Stage |
Duration |
Activities |
| Audit |
1–3 days |
Full site scan, integration register |
| Architecture |
2–5 days |
Infoblock design, field mapping |
| Scripts |
3–10 days |
PHP based migration engine |
| Staging |
1–2 days |
Full dry run, integrity checks |
| 301 redirects |
1–2 days |
Map in .htaccess or nginx.conf |
| Final migration |
1 day |
Delta import, DNS switch |
| Post‑migration |
2–4 weeks |
Monitor Search Console, fix crawl errors |
| Deliverable |
Description |
| Documentation |
Redirect map, mapping description, DB schema |
| Access |
Admin panel, FTP/SSH, API keys |
| Training |
Video tutorials or on‑boarding session |
| Support |
2 weeks post‑migration monitoring, bug fixing |
| Guarantee |
Rollback to old site within 48 hours |
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
| Project type |
Timeline |
Notes |
| Informational site (up to 500 pages) |
2–4 weeks |
Content + design + redirects |
| E‑commerce store (up to 10,000 products) |
4–8 weeks |
Catalog + orders + integrations |
| Large store (100,000+ products) |
2–4 months |
Custom scripts + load testing |
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.