Every time a company adopts a new CRM, a Business Intelligence platform or a management system, the same request comes up: “let’s bring all the history in”. It is an understandable instinct, that data is years of work, but it is also one of the fastest ways to start the project on the wrong foot. The right question isn’t “how much history do we import?”, but “which data will we actually need, and what state is it in?”.
The “bring everything in” trap
The first mistake is framing the choice as an either/or: either migrate the whole archive, or start from scratch. Neither is the answer. Most archives accumulated over the years are, in fact, largely dead weight: inactive contacts, duplicate records, companies written ten different ways, free-text fields filled in with no criteria. Pouring all of this into a new system means inheriting its flaws from day one.
The real risk isn’t technical: it’s trust
A CRM or BI project almost never fails because of the technology. It fails when people stop trusting the data. All it takes is for a salesperson to open the new tool, find three records for the same customer and a total that doesn’t add up: from that moment on they will keep their “real” data in a personal Excel sheet. The system, however modern, has already been abandoned.
This is not an abstract fear. According to Gartner, poor data quality costs organisations an average of 12.9 million dollars a year. And among the recurring causes of CRM project failure, data quality and lack of user adoption weigh more than the technology itself.
But “start from scratch” isn’t the shortcut it seems
At the opposite extreme are those who suggest sacrificing everything and restarting with clean data. This too calls for caution: throwing away history has real and often irreversible costs.
- You lose the history of the relationship with the customer: context, past contracts, communications. You can’t buy it back.
- Business Intelligence needs historical series. Without a historical base you can’t measure trends, seasonality or customer churn. BI without a past is blind BI.
- Some data must be kept by law (tax and contractual obligations): it isn’t a choice.
And there’s a point that is often forgotten: if you don’t fix the process that dirtied the data, the new system dirties itself again within months. Starting clean without introducing input-validation rules simply postpones the mess.
The right criterion: migrate what you’ll use, clean at the border
The sensible path isn’t at the extremes. You classify data by usage value and clean it at the moment of transfer, never afterwards:
- Operational, active data (live customers, open deals): migrate and cleanse it, deduplicate, normalise, validate.
- Historical and reference data (you need the history but don’t work on it daily): it doesn’t belong in the operational CRM, but in an archive or a queryable data warehouse. That way BI keeps its historical depth and the working system stays clean.
- Dead data: cold storage, or simply leave it behind.
Three questions for each set of data
Before deciding whether a piece of data enters the new system, three questions:
- Will anyone actually use it in the next twelve months?
- Is it legally mandatory to keep it?
- Is the cost of cleaning it justified by the value it brings?
You migrate only where the answers justify it, and you proceed in phases with checks, never in a single “big bang” transfer. Migration, after all, is the best opportunity to put things in order: wasting it by copying over the junk is the real waste.
How we approach it at BIT
When we guide a company onto a new CRM or a new data-analysis solution, we don’t just move tables. We assess the state of the existing data, define what to migrate and what to archive, cleanse what comes in and introduce validation rules so the system stays clean over time. The goal isn’t to start with “everything”, but to start with a reliable core to build on, without losing the history that truly matters.
