Contacts and companies
Contact details, addresses, custom fields and the contact–company relationships, preserved.
Services
Moving off your old system without losing anything
Data migration is a cleaning job, not a copying job. Move the mess across as it is and the new system starts out just as messy.
At a glance
- Contacts and companies
- Leads and deals
- Past activities
- Products and price lists
- Documents and attachments
What goes wrong in migrations?
A badly done migration destroys trust in the new system within the first week. What we see most:
- The same customer arrives as three separate records and nobody knows which is right
- Contacts are moved detached from their companies and the history is lost
- Ownership is not assigned and records end up with no owner
- Date and currency formats break
- Past activities are not moved and the conversation history resets
- The migration is tried on the live system with no rollback plan
What we move
Whatever exists in the source system, we build its equivalent in Bitrix24.
Leads and deals
Stage equivalents mapped; open records land on the right stage, closed ones in history.
Past activities
Calls, emails, notes and meeting records, attached to the right record.
Products and price lists
Catalogue, units of measure, price tiers and stock where available.
Documents and attachments
Quotes, contracts and other files linked to the relevant record.
User and ownership mapping
Matching users in the old system to Bitrix24 users.
Before moving: field mapping
The first step is working out where each field in the source system lands in Bitrix24. That sounds simple but takes the most effort: if the old system has a "status" field, you have to decide whether it becomes a stage, a custom field or a tag in Bitrix24.
The output is a line-by-line mapping table. We approve it with you, so there are no surprises after the move.
- An inventory of the source fields
- Deciding the Bitrix24 equivalents
- Deliberately marking what will not be moved
- Mapping stage and status equivalents
Deduplication: the same customer only once
Duplicate records are the problem we meet most often in old systems. The same customer has been created several times by different people with different spellings.
Before migrating we set a deduplication rule: is phone, email or tax number the deciding field? When records clash, whose data wins? We do not start the transfer until those rules are settled.
- Choosing the deduplication key
- A merge rule for clashing records
- A manual review list for uncertain matches
- Weeding out dead and test records
Test first, then production
We never load straight into the live portal. Data goes into a test portal first and we check sample records one by one: are the relationships right, have the dates shifted, did ownership land correctly?
Verification ends with your approval. Only then does the live transfer happen, and the old system is still open while it does.
- A trial load into a test portal
- Checking sample records together
- Fixing and re-running
- Live transfer after approval
- A rollback plan kept ready
Phased migration and delta transfer
Moving a large dataset in one go is risky. In those cases we go in phases: the main records move first, the team starts working in the new system and the old one becomes read-only.
For records created in the old system during the transition we run a delta transfer, so the team never has to wait.
- Main records moved first
- The old system made read-only
- Transferring the delta from the transition period
- Agreeing a firm cut-off date
How would this work in your process?
In a free 30-minute call we listen to your workflow and map out how this would run in your company.
How migration runs
Every step has an approval point; nobody is left in the dark.
- 01
Source review
What exists in which system, and in what format can it be exported?
- 02
Mapping plan
Field mapping and deduplication rules approved in writing.
- 03
Test load
Loaded into a test portal; sample records checked together.
- 04
Live transfer
Released after approval, with the old system open in parallel.
- 05
Delta and cut-off
Records from the transition period are moved and the old system is closed.
What you end up with
- An approved field mapping and deduplication plan
- A transfer verified on a test portal
- Live data with relationships and ownership preserved
- A report of what was and was not moved
- A list of the duplicates that were merged
- A rollback plan and a transition timetable
Features
Related features
The modules we most often roll out alongside this one; they reinforce each other in the same setup.
Data Migration
Changing CRM is not a file upload. You have to preserve context, relationships and history. Bitrix24's migration tooling turns that into a planned, verifiable process.
Lead Management
Collecting leads is the easy part. Responding quickly, assigning correctly and following up consistently is where deals are won. We build Bitrix24 around those three things.
Access Management
Access management is more than a password policy: permissions, audit trails and retention are designed together. We map Bitrix24's role-based model onto how your company actually works.
REST API
Bitrix24 is not a closed box. The REST API gives programmatic, scope-controlled access to your CRM entities over standard HTTP; and we design, build and monitor the integration for you.
Other services
Bitrix24 Setup
Opening a Bitrix24 account takes five minutes. The real work is getting your sales process correctly placed inside that account; that is what we mean by setup.
Bitrix24 Training
We design training as the team doing their own work on their own screen, not as a generic product tour. No slide deck, everyone opens their own record.
Technical Support
Things keep changing after setup: new products, new people, new processes. A support plan lets you make those changes without opening a project each time.
Frequently Asked Questions
Which systems can you migrate from?
Any system that can export to Excel or CSV. For most common CRMs direct transfer over the API is also possible. From your own software, a database dump or API access is enough.
Are past conversations moved too?
If they exist in the source system, yes. Calls, emails, notes and meeting records are attached to the relevant customer record, so the team can see the history in the new system too.
Can we keep working during the migration?
Yes. Because the migration is prepared on a test portal you carry on with your current system. The live transfer usually runs outside working hours, and records created during the transition are picked up by a delta transfer.
What happens to duplicate records?
They are merged according to the deduplication rule agreed beforehand. We do not auto-merge uncertain matches; those come to you as a review list so the decision stays with you.
How long does migration take?
A few thousand records from a clean Excel file takes a few days. Moving from an old CRM with relationships and past activities can take one to three weeks depending on data quality. We give the timeline after the source review.
Let's configure this around your business
Book a free intro call and we'll walk through your process and show which settings fit you.