There is a moment in almost every data migration where the whole programme quietly
stops moving. It is rarely technical. It looks like this: someone asks the teams which records can be left behind, and the teams say — with complete sincerity — none of them.
I have watched this deadlock consume months. And the reason it is so hard to break is that both sides are right.
The technical team is right that a system carrying two decades of accumulated records will be slow, expensive and difficult to maintain. Migration effort scales with volume. Poor data quality compounds. Anyone who has done this knows that a clean, fast system is what makes the difference between a CRM people use and a CRM people work around.
The teams are also right. Every one of those records is somebody’s relationship. No fundraiser is going to volunteer to lose a donor who gave generously for eleven years and then went quiet — because that person might come back, and if they do, the history is the whole basis of the conversation. No service manager will agree to lose case history that might be needed. These are not irrational positions. They are people protecting the thing they are accountable for.
Why the usual approaches fail
The three standard moves all make it worse.
Escalate it. A director makes a call, the teams comply, and you get compliance
without consent. Six months after go-live you discover the shadow spreadsheets — because people who were told to lose data they needed simply kept their own copy. Now you have two versions of the truth and no idea which is current.
Compromise on a number. “Let’s take the last seven years.” Arbitrary, and it
satisfies nobody. The technical team still has more than it wants; the teams have lost things they needed. Everyone leaves the meeting slightly aggrieved.
Migrate everything. The path of least resistance and the most expensive.
Migration costs rise, testing takes longer, the system is slower on day one, and every data quality problem you had before is now a data quality problem in an expensive new system. This is the most common outcome, and it is how organisations end up saying “the new CRM is no better than the old one.”
Stop having the argument
The reframe is simple, and I have never seen it fail to move a stuck migration.
Migrate only actively-engaged records into the CRM. Move everything else to an archive: cold, still held, still retrievable, still reportable. Nobody loses their data, so nobody fights you.
Call the two tiers hot and cold.
Hot data goes into the CRM. It is the records people work with daily — active
supporters, current members, open cases, live relationships. This is the data that needs to be fast, clean, searchable and integrated.
Cold data goes to a data lake, a warehouse, or in smaller organisations simply
a well-structured archive. It is retained, it is queryable for reporting and analysis, and any individual record can be retrieved when needed. What it is not is loaded into the operational system that people use every hour of every day.
The argument dissolves because the premise dissolved. Nobody was ever asked to delete anything.
Why this works on the human level, not just the technical one
The technical benefit is obvious — a smaller, cleaner operational dataset. But that was never the blocker. The blocker was that you were asking people to accept loss, and they were right to refuse.
What makes hot/cold work is that it removes the loss from the equation entirely, which means the conversation changes from a negotiation into a definition exercise. And a definition exercise is something teams are genuinely good at.
Let the teams own the definition
This is the part that determines whether it lands. Do not arrive with a definition of “actively engaged”. Ask each team to write their own, and hold them to signing it off by name.
A fundraising team might say: any interaction in the last thirty-six months. A membership team might say: current members, plus anyone lapsed within twenty-four months. A services team will be constrained by their retention policy and by statutory requirements, which is a different and harder conversation — but at least it is the right conversation, about lawful retention rather than about system performance.
Three things happen when teams own the definition. They set it more tightly than you would have dared to propose. They defend it afterwards, because it is theirs. And the exercise surfaces disagreements about who owns which data — which you needed to know anyway.
A worked example
| Record type | Hot if… | Owner sign-off |
| Individual supporters | Any interaction in last 36 months | Director of Fundraising |
| Members | Current, or lapsed within 24 months | Director of Membership |
| Service users | Open case, or closed within retention period | Director of Services |
| Volunteers | Active or available | Head of Volunteering |
| Corporate contacts | Live relationship or active pipeline | Director of Partnerships |
Notice that every row has a named person. That is not administrative tidiness — it is the mechanism. A rule nobody signed is a rule nobody will defend when someone complains in month four.
Two things to get right
Cold must genuinely be retrievable. If “archived” turns out to mean a CSV on a
server nobody can query, you have not solved the problem — you have deferred it and damaged trust in the process. Demonstrate retrieval before you migrate. Show a team getting a real record back out. That demonstration is worth more than any amount of reassurance.
Cold is not a way of dodging retention obligations. Moving records to an
archive does not change your lawful basis for holding them. If you have no lawful basis, the answer is deletion, not relocation. Get the retention policy settled first — this reframe solves a performance and adoption problem, not a compliance one.
Where else it applies
I have described this in CRM terms because that is where I use it most. But the pattern
generalises to any migration where volume is the blocker and stakeholders are attached to history: finance systems, case management, document stores, even email archives.
The underlying insight is that most migration deadlocks are not disagreements about data. They are disagreements about loss. Remove the loss and the deadlock usually goes with it.
Free guide · the full methodImplementing a new CRM — without the usual regretsThis reframe is one of twelve lessons in our full CRM guide, alongside seven phases and four templates you can fill in and export. Free to read on the page.
Read it free