How Long Does a CRM Migration Actually Take?
Based on our project archive of 1,300+ Bitrix24 projects, total migration timelines range from roughly 2 weeks for a straightforward tool-assisted switch (e.g., a small AMO CRM account with standard data) up to 39 working days for a full-cycle migration that includes custom script development, business-process rebuild, UAT, and go-live monitoring.
That range sounds wide, but it reflects a real and predictable set of variables. The key insight: the data transfer step itself is rarely the bottleneck. What extends timelines is the work that surrounds it — auditing what you actually have, rebuilding the target structure correctly, re-connecting integrations, and getting users to sign off.
Below we break down where the time goes, phase by phase, with benchmark ranges drawn from our internal project records.
The Six Phases of a Bitrix24 Migration — and Their Time Ranges
A properly structured Bitrix24 migration always passes through six distinct phases; based on project documentation, their combined working-day totals consistently fall between 29 and 45 working days for mid-complexity engagements.
The table below shows the phase-by-phase breakdown observed across our project archive. "Working days" means billable consultant days, not calendar weeks with idle time factored in.
| Phase | What Happens | Typical Duration |
|---|---|---|
| 1. Data Audit & Inventory | Map users, CRM entities (contacts, companies, deals, smart processes), infoblock structures, and event timeline data | 4–6 working days |
| 2. Target Environment Setup | Create org structure, custom fields, CRM funnels, infoblock skeletons, base permissions | 4–6 working days |
| 3. Migration Script Development | Design CLI script architecture; write and debug scripts for users → structure → infoblocks → CRM → timeline; test on a DB copy | 8–14 working days |
| 4. Data Transfer (Live Run) | Set old portal to read-only; run scripts sequentially; verify record counts and referential integrity; produce transfer report | 4–6 working days |
| 5. Business Process & Automation Rebuild | Rebuild CRM robots, triggers, notifications, approvals; scenario testing | 6–10 working days |
| 6. Testing, UAT & Go-Live | Full system test, user acceptance testing, DNS switch, post-release monitoring, project handover | 5–7 working days |
| Total | 31–49 working days |
Methodology note: Ranges above are derived from actual work plans in our project archive. Projects using a tool-assisted migrator (e.g., the standard AMO→Bitrix24 migration app) may complete in 2–3 weeks by compressing phases 3 and 4. Projects requiring custom API mini-applications for non-standard data imports fall at the upper end or beyond.
Migration Benchmarks by Scenario Type
The single biggest driver of timeline variance is the migration type: tool-assisted switches between cloud CRMs take 2–4 weeks, whereas Bitrix24-to-Bitrix24 portal migrations with custom scripting regularly run 6–8 weeks end-to-end.
The diagram below shows how data flows through the migration pipeline — from audit through to user go-live.
The diagram illustrates the six-phase migration pipeline: the source system feeds into an audit and inventory stage, which informs both target environment setup and script development; scripts then run the live data transfer into the new Bitrix24 portal, after which business processes are rebuilt and the system undergoes testing before users cut over.
flowchart TD
SRC[Source CRM / Old Portal] --> A[Phase 1: Audit & Inventory]
A --> B[Phase 2: Target Setup]
A --> C[Phase 3: Script Development]
B --> D[Phase 4: Live Data Transfer]
C --> D
D --> E[Phase 5: Automation Rebuild]
E --> F[Phase 6: Testing, UAT & Go-Live]
F --> USR[Users Working in New Portal]
Scenario A — AMO CRM → Bitrix24 (Tool-Assisted)
Using the standard migrator application, the bulk of the data — deals, contacts, companies, field settings, funnel stages, and access rights — transfers in batches. The migrator runs multiple passes (initial transfer + delta for changes). Typical task-level time estimates from project records:
- Adding employees and access rights: 2 hours
- Deals migration: 4 hours
- Contacts migration: 2 hours
- Companies migration: 2 hours
- Integration reconnection (telephony, messengers, web forms, email accounts): 6–10 hours
Total technical work: ~16–20 hours billed. Overall calendar timeline including client prep and sign-off: 2 weeks.
⚠️ The tool-assisted route carries documented risks: field IDs change on transfer, so document templates must be remapped; the right-hand card panel (activities, calls, emails, meetings) is not exported by most source CRMs and cannot be migrated.
Scenario B — Bitrix24 Cloud → Bitrix24 Self-Hosted (Standard Migrator)
Very similar task structure to Scenario A, but with added complexity for server provisioning. Key additional scope:
- Employee structure and org chart: 2–5 hours
- Leads: 2–4 hours
- Deals: 2–6 hours
- Contacts: 2–4 hours
- Document templates (require remapping after field ID changes): 2–6 hours
Total calendar timeline: 2–4 weeks, depending on the volume of CRM entities and how many integrations need to be reconnected from scratch (server change means all integrations require full reconfiguration, not just token refresh).
For a detailed walkthrough of this path, see Migrating from Bitrix24 Cloud to Self-Hosted: Step-by-Step Plan.
Scenario C — Full Custom-Script Migration (Complex Portal Transfer)
This is the most demanding scenario, used when the source system contains heavy customisation: custom tables, non-standard API usage, large infoblock structures, or a business-process layer that must be fully rebuilt. From our project archive, the documented plan for one such engagement ran to exactly 39 working days across six phases, with 30 working days as an optimistic target when client feedback cycles are fast.
For context on migrating from other platforms into Bitrix24, see How to Migrate from HubSpot to Bitrix24: Step-by-Step Plan and Pipedrive to Bitrix24 Migration: What Changes and How to Move Your Data.
What Extends Timelines: The Real Risk Factors
In our experience, scope creep during migration almost always originates from one of eight specific discovery-time surprises — none of which appear on the original project brief.
These factors consistently push projects past their initial estimates:
- Undocumented custom code in the source system that uses deprecated or undocumented API calls — requires rewriting, not porting.
- Hidden or forgotten data entities discovered during audit that were not listed in the initial scoping questionnaire.
- Expanded automation requirements — the client realises they want to rebuild processes better, not just the same.
- Integration complexity — each third-party service (telephony, WhatsApp gateway, marketplace connectors, accounting systems) requires full reconfiguration when the server or portal URL changes.
- Non-standard imports requiring custom API mini-applications (e.g., importing large reference databases — ports, cities, airports — into smart processes via API, which cannot be done with standard Bitrix24 tools).
- Data volume growth between audit and live transfer — the actual dataset is larger than the audit sample suggested.
- Compatibility failures between existing custom modules and the new Bitrix24 version.
- Extended UAT cycles — key users are unavailable or raise requirements changes during acceptance testing.
All eight of these are real patterns from our project records, not theoretical risks. Any realistic project plan should budget contingency time for at least two of them.
Per-Component Time Benchmarks
Individual data-type migrations have their own reliable time ranges; deals and CRM entities consistently take the longest at 2–15 hours depending on volume and field complexity, while user/structure setup and contact migration are faster at 2–5 hours each.
| Data Component | Tool-Assisted Range | Custom Script Range |
|---|---|---|
| Users + org structure | 2–5 hours | 2–3 days (incl. custom fields) |
| Contacts | 2–4 hours | 1–2 days |
| Companies | 2–4 hours | 1–2 days |
| Deals / pipelines | 2–15 hours | 2–4 days |
| Smart processes | Varies | 1–3 days |
| Document templates | 2–6 hours | 2–6 hours (remapping required) |
| Infoblocks + files | Not applicable | 2–3 days |
| Event timeline / activity history | Not portable via tool | 1–2 days (API dependent) |
| Integrations reconnection | 6–10 hours per batch | 1–2 days per batch |
| Business processes / robots | 1–2 days | 6–10 days |
Note on activity history: The right-hand panel of CRM cards (calls, emails, meetings, comments) is not exportable from most source CRMs. This is a structural platform limitation, not a migration methodology issue. Plan for this data to be archived externally rather than transferred live.
The Audit Phase: Why It Determines Everything Downstream
Skipping or under-investing in the audit phase is the single most common cause of blown timelines — a thorough 4–6 day audit at the start prevents 3–4 weeks of rework later.
A proper pre-migration audit covers four areas, each with a defined output:
| Audit Area | What Gets Documented | Time |
|---|---|---|
| User structure | Custom fields (UF), department assignments, roles, access rights | ~1 day |
| CRM entities | Contacts, companies, deals, smart processes: record counts, field lists, funnel stages, entity relationships | ~1 day |
| Infoblock structures | Which infoblocks are actively used; property types, section trees, inter-element relationships | ~1 day |
| Event timeline / activity log | What is stored in the event log tables; which event types need to be preserved | ~1 day |
The audit output is a complete data registry — the single source of truth for all subsequent phases. Without it, script developers work from assumptions, and target environment setup risks being wrong the first time.
Before starting, it's worth going through a structured Bitrix24 onboarding questionnaire to surface requirements that clients often overlook — and to catch the hidden data that causes timeline overruns.
Guarantees, Handover, and Post-Go-Live Support
Standard practice across our project archive is a 30-day warranty support period after project sign-off, during which the implementation team corrects any defects that fall within the agreed scope — this is not optional, it is built into the project contract.
What the warranty period covers: - Defects in migrated data (incorrect field mapping, broken relationships) - Automation logic that doesn't fire as specified - Integration issues traced to the migration itself
What it does not cover: - New requirements raised after go-live - Changes to business processes beyond the agreed scope - Performance tuning unrelated to the migration
The handover package typically includes: full documentation, access credentials, migration scripts (for re-runs if needed), and a transfer report showing record counts and any data that could not be migrated.
For projects migrating from Salesforce, where the complexity and data model differences are more significant, see Salesforce to Bitrix24: A Lower-TCO Alternative for Growing Companies.
Planning Your Migration: A Realistic Timeline Template
For planning purposes, add 20–30% buffer to any quoted estimate; based on our project archive, the majority of engagements that ran over schedule did so because of client-side delays (data provision, UAT participation, integration access), not consultant-side execution.
Use this framework as a starting point:
- Week 1–2: Audit, scoping sign-off, target environment setup
- Week 3–4: Script development (or tool-assisted migration passes)
- Week 4–5: Live data transfer, integrity checks, automation rebuild
- Week 5–6: UAT, iteration, DNS cutover, go-live monitoring
- Weeks 7–10: Warranty support period
For a broader view of how migration fits into the overall implementation investment, see Bitrix24 Implementation Cost & Timeline: Real Data from 1,300+ Projects.