Data migration between systems with relations and history intact
A one-off move from the old system into the new one: contacts, companies, deals, notes, attachments and custom fields, together with the relations between them. First an inventory and a field map, then a trial run on a copy that you look at before deciding anything, and at the end a switchover window with a rollback plan and a verification report.
- 3 to 5 daysthat is how long a simple migration runs: one system, under 10,000 records, simple relations. A complex data merge takes 4 to 8 weeks
- 2 runsthe data moves twice: first as a trial on a copy whose result you check, then in production inside an agreed window
- 5 stepsfrom the inventory to the verification report and the archive of the old system, each step ending in something you can judge
The problem
Why does a CSV export end with a broken database?
A company changes CRM. The old system holds five years of work: 3,000 contacts, 800 companies, 2,400 deals with notes, emails and attachments, plus 150 custom fields that someone added over the years and that nobody can now explain. Someone says we will export it to CSV and load it in. Two weeks later the contacts are in the new system, detached from their companies. The deals are there, with no history. Thirty percent of the records are duplicates, because the old database held three versions of the same buyer at the same company and nobody knew which one was current.
The root of it is that the two systems hold different data models. The old one keeps the company as a single text field, the new one expects a separate company record and a relation id. The old one has a status called in progress, the new one has no such status at all. An export to a file flattens every relation into columns, and nobody notices until a sales rep opens a client record and finds an empty page where three years of conversations used to be.
There is also a legal duty that rarely comes up while a migration is being planned. The GDPR, in Article 5(1)(d) and (e), requires personal data to be accurate and kept no longer than is necessary. Carrying duplicates and records from 2014 across just in case runs straight against both. The pull in the other direction comes from accounting and tax rules, which set their own retention periods for invoices and books, so part of the old system cannot be deleted on switchover day. A migration is the moment when those two lines get drawn on paper.
- A sales rep opens a client record and cannot see the last three years
- The team works in two systems at once, because nobody dares switch the old one off
- Duplicates from the export reach email campaigns and board reports
- Nobody knows whether everything came across, because nobody counted the records first
Why now
What changed, so that a migration is no longer a jump in the dark?
The biggest change is a dull one: almost every business system now has an API for reading and for writing, not just an export button. Data can move record by record together with its relation ids, so a contact lands on the right company and a note on the right deal. Where there is no API, the export file is all there is, and then we rebuild the relations from keys agreed in the workshop.
The second change is the cost of a trial run. A sandbox in HubSpot, Pipedrive or Salesforce is set up in a few hours, and a copy of the database sits in BigQuery or SQL for weeks at a trivial price. So the whole set can be moved onto a copy, looked at and counted before anyone touches production. A few years ago the same test needed a separate server and a week of work.
The third change is about what is left behind. The old system can usually be switched off, but its data cannot always be deleted. A dump into BigQuery or into files with a description of the structure costs very little and closes the archive question without paying a licence for a system nobody opens.
What changes
What do you get instead of a CSV file and hope?
You know what you hold before you move it
The inventory shows how many records there are of each type, which fields are actually filled in and how many of them are duplicates. Fields used in five percent of records usually do not travel, and that is a decision rather than an accident.
Record counts, field counts and the share of duplicates written down before the first move
Relations travel with the records
The contact stays on its company, the deal on its contact, the note on its deal, the file on its document. We carry relation ids, not names sitting in a column.
Contact to company and deal to contact pairs counted after the move, not just the record totals
Duplicates die before the migration, not after it
Merging runs on email, domain, phone number, fuzzy company name and registration identifier: VAT number, EU VAT ID, company register number. You approve the merge rules, because only your side knows which record is the current one.
The merge rule written down and counted on a copy before anything enters the new system
A trial run you can actually look at
The whole set, or a sample of it, goes into a copy of the target system first. Your people open their own records and say what is wrong while the fix is still free.
Mapping fixes happen on the copy, where a mistake costs nothing beyond another run
A switchover window and a way back
We agree the hour after which nobody types into the old system, and the moment the new one becomes the source of truth. If verification fails, we go back to the state before the migration, because the old system is still standing untouched.
A rollback plan written before the start, naming the person who decides to go back
A report that closes the subject
After the migration you get the numbers: how many records of each type came across, how the checksums compare, what the manual sample showed and which fields were dropped on purpose. There is finally an answer to did everything come across.
Post-migration counts compared against the inventory, record by record inside the sample
And in your company
What if our data is a complete mess?
Four sentences we hear most often before a migration, and what we answer.
If you are after a narrower piece, there are separate pages: CRM implementation when the new system still has to be chosen and configured, CRM and ERP sync when both systems are meant to keep running side by side, and API integration when the move has to go through an interface nobody has connected before.
Our data is too dirty, we have to clean it up first.
The other way round. A migration is the one moment when cleaning pays off, because every record passes through the mapping anyway. The cleaning happens on a copy, so the old system stays exactly as it is until you accept the result.
All we have is an Excel export, the vendor will not give us an API.
That is normal with older systems and there is a way out. We rebuild the relations from keys agreed with you: customer number, VAT number, document number. We also say plainly what cannot be recovered from a file, so you know it before the migration rather than after it.
We cannot stop selling for a weekend.
The switchover window usually runs a few hours, not a weekend, because the heavy work happened earlier on the copy. For companies that cannot stop at all, we move the historical data in advance and the window carries only the delta from the last few days.
Why you, when the new vendor already promised an import?
If you have one system, simple relations and under 10,000 records, the vendor import is usually enough and we will say so. Our work starts at custom fields, activity history, several sources at once and data that must not be deleted.
- CRM systems
- HubSpot, Pipedrive, Salesforce, LiveSpace
- ERP and accounting
- Comarch Optima, Xero, sevDesk, Fakturownia, iFirma
- Online sales
- BaseLinker, Shopify, WooCommerce, PrestaShop, Allegro
- File sources
- Excel, Google Sheets, CSV exports, SQL database dumps
- Targets and archive
- BigQuery, SQL databases, Google Sheets, Google Workspace, Microsoft 365
- The moving layer
- n8n, Make, custom scripts over the API
What we move, what breaks on the way and how you know it landed
Seven kinds of data that cause the most trouble in a migration. The third column is not a promise, it is the number we compare against the inventory once the move is done.
| Kind of data | What breaks in a file export | How we check it came across |
|---|---|---|
| Contacts and companies | the contact loses its company, because the file keeps only a name | count of contacts, count of companies and count of contact to company pairs |
| Deals | the deal arrives with no stage, no owner and no creation date | total deal value in each stage, before and after |
| Notes, emails, activities | the history stays in the old system, because the export does not cover it | activity counts on 20 random records, opened by hand |
| Attachments | the file comes across but detaches from its record | file count and total size in bytes, before and after |
| Custom fields | 150 fields from five years land in the wrong place or vanish | list of fields moved, remapped and deliberately dropped |
| Accounting documents | deleted along with the old system, although retention rules require keeping them | an archive with a dump date and instructions for reading it without the old system |
| Statuses and picklists | the status called in progress does not exist in the new system | a status mapping table, agreed and signed off before the migration |
The rows are a starting point. Moving from spreadsheets into a database adds two more questions: what type each column gets, and what to do with the cells where somebody typed text into an amount field.
How we do it
Five steps from the old system to a verification report
Each step ends with something you can judge before you decide on the next one. Production is never touched until you have seen the result on a copy.
Inventory
We count records of each type, check which fields are actually filled in and write out the relations between objects. A separate list covers what must not be deleted: accounting documents, contracts, marketing consents with their date and legal basis. This is the same moment when we agree what does not travel into the new system at all.
Mapping and cleaning
Field by field we agree where it lands in the new system and what transformation it needs on the way: phone format, address split, status mapping. In parallel we merge duplicates on email, domain, phone, fuzzy name and VAT number. You approve the merge rules before the first run.
Trial run on a copy
We move the data into a sandbox or onto a copy of the database and invite your people to open their own records. The sales rep opens their five largest clients, finance opens their invoices. Mapping fixes happen here and the run repeats until the result is good enough.
Switchover window
We agree the freeze hour for the old system, the order in which objects move and the moment the new system becomes the source of truth. The rollback plan is written before the start: who decides to go back, what tells us to, and how long we have. The old system stays untouched, so going back is real rather than theoretical.
Verification and archive
We compare record counts and checksums against the inventory, open a random sample by hand and close it with a report. The old system goes into the archive: a data dump, a description of the structure and instructions for reading it without a licence. Only then can you stop paying for it.
Before and after
How the first week in the new system changes
Before
- The rep looks for client history in the old system, because the new one has none
- The team types data into two places so that nothing gets lost
- The board report matches nothing, because half the deals arrived with no stage
- Nobody can answer did everything come across with a number
After
- The client record carries history, notes and attachments where they were
- The old system is switched off and its data sits in a described archive
- Report totals match the totals from the day before the switchover
- The verification report says plainly what came across and what we dropped on purpose
The trial run shows up in the first week of work. The verification report closes the project on switchover day, and the small remaining discrepancies get caught within 30 days of the team working in the new system.
For the person signing this off
What the person who signs off the system change gets out of it
A migration is a project where it is easy to become the person who lost the company data. So we work in a way that leaves a route back and a piece of paper at every stage. The trial run on a copy gives you the right to say not yet without consequences, and the rollback plan means the switchover decision stays reversible until the window closes.
The second part pays off later, in the room with the board or with an auditor. A verification report with record counts, checksums and a list of deliberately dropped fields is the document that closes the subject once. Without it the question of whether we are sure nothing was lost keeps coming back for another six months.
- The old system untouched until the switchover window closes, so going back is real
- The production decision only after your people have seen the result on a copy
- A report with numbers instead of assurances, ready for the board and for an auditor
- A list of data that must not be deleted, with its legal basis and retention period
What it costs
The workshop has a published price, the migration is quoted after it
The process workshop costs EUR 3,500 net per week. On a migration one week is usually enough: that is how long the data inventory and the field map take, and that is exactly the part that makes the rest quotable. Without it any migration quote is guesswork, because nobody yet knows how many custom fields and how many duplicates there are.
The migration itself is quoted after the workshop, once we know the number of records, the number of systems and the state of the data. A simple migration is 3 to 5 days of work, a medium one 2 to 4 weeks, a complex data merge 4 to 8 weeks. Tool costs along the way, a sandbox or storage for the archive in BigQuery for example, you pay directly to the vendor with no commission from us. Where the AI agent is in scope, model queries cost the vendor EUR 0.005 to 0.07 each.
Process workshop
EUR 3,500 net
per week, on a migration usually 1 week
A self-contained piece of work. It ends with a data inventory and a field map you can execute yourself or hand to the vendor of the new system.
- Inventory: record counts, field fill rates, share of duplicates
- Field map with the transformations and the fields that have no target
- List of data that must not be deleted, with basis and retention period
- Switchover and rollback plan plus the numbers used for verification
- Most popular
Workshop and migration
Quoted after the workshop
scope follows from the number of records and systems
The option most companies choose. A simple migration in 3 to 5 days, a medium one in 2 to 4 weeks, a complex data merge in 4 to 8 weeks from the workshop.
- Everything in the workshop
- Cleaning and duplicate merging under the approved rules
- Trial run on a copy and mapping fixes until you accept the result
- Switchover window with a rollback plan and cover on our side
- Verification report and an archive of the old system with its structure described
Migration and an AI agent on the new data
Quoted after the workshop
for companies that want to start asking questions about their data
Everything in the migration plus BOND, the company AI agent that answers questions about data in the new system in a plain sentence.
- Everything in the migration
- AI agent wired into the new system, answers in 5 to 10 seconds
- Control questions after the move: how many records with no company, how many with no owner
- Access for the team in English and Polish, rollout around 2 months
The workshop ends with an inventory and a field map that stand without us: you can take them to the vendor of the new system or run the import with your own hands. And if it turns out you have one system, simple relations and a standard import that will do the job, we say so plainly and the work ends at the workshop.
Frequently asked questions
How is data migration different from syncing two systems?
A migration is a one-off: the data moves from the old system into the new one, the old one gets switched off and the new one becomes the source of truth. A sync runs forever and keeps two systems in agreement, because both are meant to stay in use. If the second one is what you need, we describe it on the CRM and ERP sync page.
How long does a data migration take?
A simple migration, meaning one system, under 10,000 records and simple relations, takes 3 to 5 days. A medium one, with several systems and 10,000 to 100,000 records, takes 2 to 4 weeks. A complex one, merging data from several companies with hundreds of thousands of records and custom fields, needs 4 to 8 weeks. We size it on the free consultation.
What happens if the data turns out to be incomplete after the switchover?
We go back to the state before the migration, because the old system stands untouched until the switchover window closes. The rollback plan is written before the start and holds three things: what tells us to go back, who takes that decision and how long we have to take it. In practice most discrepancies surface during the trial run on the copy.
How do you check that everything came across?
Three ways at once. We compare record counts of each type against the inventory. We compute checksums, for example the total deal value in each stage or the total size of attachments. Finally we open a random sample by hand, usually 20 records, together with the people who work on that data every day.
What do you do with data that must not be deleted?
We list it separately during the inventory, with its legal basis and retention period: accounting and tax records carry statutory periods, employee files have their own, marketing consents have to be reproducible with a date. That data goes into an archive, a dump into BigQuery or into files, with the structure described and a way to read it without the old system.
Can we clear duplicates out of the database during the migration?
Yes, and it is the best moment, because every record passes through the mapping anyway. Merging runs on email, company domain, phone number, fuzzy name and registration identifier, meaning VAT number, EU VAT ID or company register number. You approve the merge rules before the run, because only you know which of three records for the same person is current.
All we have is an Excel export, the old vendor gives us no API. Can anything be done?
It can, although part of the information simply does not come out of a file. We rebuild relations from keys agreed with you: customer number, VAT number, document number, email address. We say plainly what cannot be recovered, status change history for example, so you know it before the migration rather than after the switchover.
Who picks and configures the new system we are migrating into?
A migration assumes the new system is already chosen and configured, because the data needs somewhere to land. Choosing the CRM and setting up stages, fields and permissions is separate work and we describe it on the CRM implementation page. We often run the two in sequence: configuration first, migration second.
Let us count what you actually have to move
The free consultation takes 30 minutes. You tell us which system you are moving from and into, roughly how many records there are and whether the activity history matters to you. We show you where the risk sits in that migration and whether the standard vendor import would do. You do not have to give access to any system or data at this stage.
We run at most two implementations at a time, so that someone is actually sitting on each of them.
Book a free consultationPS. If what worries you is the day a sales rep opens a client record and cannot see three years of conversations, that is exactly this problem. It is solved by a trial run on a copy that you look at before deciding, and by a rollback plan that leaves a route back. That is where the workshop starts.