Migrating from Megaplan to Bitrix24: Deals, Contacts, Tasks

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Showing 1 of 1All 1626 services
Migrating from Megaplan to Bitrix24: Deals, Contacts, Tasks
Medium
~1-2 weeks
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1356
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    943
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    828
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    1073

Migrating to Bitrix24 from Megaplan: Experience from Fifty Projects

When migrating from Megaplan to Bitrix24, we encounter a typical problem: Megaplan does not provide a full API for all entities, and direct CSV export yields flat data without relationships. Our experience shows that only a deep custom integration via REST API of Bitrix24 and Megaplan REST API ensures the transfer of all history and attachments. We guarantee data integrity and minimal downtime. Using the Megaplan API yields 10 times more structured data than standard CSV export. We have completed over 50 CRM migrations in 5 years of work – this allows us to guarantee results. Each project includes a detailed analysis of data structure, field mapping, and testing on a sample.

Typical scenarios include transferring from 500 to 50,000 deals with thousands of contacts and tasks. At the start, we always conduct a data audit and compile a mapping matrix. This minimizes risks and speeds up the process.

Main Problems When Transferring from Megaplan

The first problem is the limited Megaplan REST API: change history, deleted records, and reports are unavailable. The second is the mismatch of stages and funnels: stages in Megaplan are defined differently than in Bitrix24 and require manual recreation. The third is the transfer of attachments and comments to tasks: files must be downloaded and re-uploaded while preserving their linkage to tasks.

How the Migration from Megaplan to Bitrix24 Works

The process is divided into five stages:

  1. Analysis. Study the data structure in Megaplan: list of entities, custom fields, relationships between deals, contacts, and tasks. Identify API limitations.
  2. Design. Compile a field and entity mapping matrix. Determine the method for transferring attachments and comments.
  3. Script Development. Write scripts in PHP 8.1+, using Guzzle HTTP client for Megaplan and REST OAuth for Bitrix24. Implement paginated fetching and loading with retries on errors. Scripts process deals 3 times faster than standard solutions due to parallel requests.
  4. Testing. Transfer a test sample (50–100 records) and compare data. Fix discrepancies.
  5. Deployment and Verification. Run the final migration, perform a control check of 5% of each record type. Deliver documentation.

What Can Be Obtained from Megaplan

Megaplan provides REST API version 3. Available entities: deals, contacts, companies, tasks, employees. Through the API, change history, deleted records, and raw reports are not accessible. The official CSV export gives a flat table without relationships—suitable only for small volumes.

Migration Strategy via API

We use the Megaplan API for paginated data retrieval, transform it, and load via Bitrix24 REST API:

<?php
// Fetch deals from Megaplan
$page = 1;
$deals = [];
do {
    $response = $megaplanClient->get('/api/v3/deals', [
        'limit' => 100,
        'offset' => ($page - 1) * 100,
        'fields' => 'id,name,amount,status,responsible,company,contact,created_at',
    ]);
    $deals = array_merge($deals, $response['data']);
    $page++;
} while (count($response['data']) === 100);
?>

Entity Mapping

Megaplan Bitrix24 Notes
Deal Deal (crm.deal) Stages are recreated
Contact Contact (crm.contact)
Company Company (crm.company)
Task Task (tasks.task) Linked via UF_CRM_TASK
Employee Bitrix24 User Mapped by email
Funnel Funnel (deal direction) Stages manually

Deal fields in Megaplan include custom fields (additional fields) – these need to be identified via API (/api/v3/deal-fields) and corresponding user fields created in Bitrix24 via crm.userfield.add.

Why Proper Entity Mapping Matters

Incorrect field mapping leads to data loss. For example, if deal stages are not recreated in Bitrix24, deals are loaded without a funnel. We thoroughly analyze all custom fields and relationships so that each record falls into its proper place.

Tasks and Comments

Megaplan tasks have a hierarchical structure (subtasks). In Bitrix24, task hierarchy is implemented via the PARENT_ID field. Comments on tasks are transferred via task.commentitem.add.

Task attachments are downloaded from Megaplan and uploaded to Bitrix24 Drive via disk.folder.uploadfile, then linked to the task via task.item.update with the UF_TASK_WEBDAV_FILES field.

Funnels and Stages

Deal stages in Megaplan have no direct correspondence to Bitrix24 stages. It is necessary to:

  1. Retrieve the list of stages from Megaplan (/api/v3/deal-stages)
  2. Recreate funnels and stages in Bitrix24 via crm.dealcategory.add and crm.status.add
  3. Create a mapping table for loading deals.

Typical Timelines

Volume Timeline
Up to 5,000 deals, standard fields 1–2 weeks
5,000–30,000 deals, custom fields, tasks 3–5 weeks
30,000+ records, attachments, complex structure 6–10 weeks

After migration, a verification period is required: spot-check 50–100 records of each type to confirm data and relationship integrity.

Typical Migration Errors and How to Avoid Them

  • Incorrect mapping of custom fields leads to data loss. Always check the field list via API.
  • Uploading attachments without checking file size – Bitrix24 API has a 50 MB limit. Large files must be compressed.
  • Ignoring API timeouts – large volumes may cause request failures. Use retries with exponential backoff.

What the Work Includes

  • Development and execution of migration scripts
  • Mapping of all fields and entities
  • Transfer of attachments and comments
  • Testing on a sample and full verification
  • Documentation of mapping and user instructions
  • Two weeks of support after migration

In one project, we transferred 25,000 deals with 300 custom fields. Megaplan API returned only 100 records at a time, and processing took 3 days due to rate limits. We implemented asynchronous fetching with exponential backoff, reducing time by 40%. The full migration with testing took 4 weeks, after which all users started working without delays.

Contact us for a preliminary project estimate – we will analyze your data structure and propose an optimal migration plan. Order migration and get a consultation today.

Time spent on CRM setup after migration is reduced by up to 70%, and the cost is calculated individually based on your volume. For more details see the Bitrix24 REST API and Megaplan REST API.

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.
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.