CRM migration: who holds your data while it moves?

None of the ten refuses to hold your data. That isn't the problem. The problem is that holding it and being obliged to hand it back are two different promises, and only half of these contracts make the second one.

A CRM migration is the transfer of an organisation's customer records, pipeline history and supporting configuration from one CRM into another, including the field mapping, the relationships between records, and the automations that act on them. It differs from a CRM implementation in that the system already holds live data and a working sales motion depends on it.

This is the sister problem to what happens to records once they are sitting in the system. A migration is the one moment you get to decide what not to carry across, and almost nobody uses it.

What "you own your data" actually means in a CRM contract

Owning your data and being able to retrieve it are two different rights, and CRM contracts grant them separately. Pipedrive's terms say you retain all rights, title and interest in your data. The same document disclaims liability for "deletion of, corruption of, or failure to store any Client Data" and sets a deletion deadline rather than a retrieval guarantee. Both clauses survive termination. Ownership is not custody.

Here is that question asked of ten contracts, ranked, with each mark linking to the document the clause came from.

Five of the ten promise you nothing. One of them, monday.com, gets the whole problem into a single clause: it offers a read-only mode, removes any obligation to maintain it, reserves the right to end it at any time with or without notice, and disclaims liability, all in one sentence. Its own data processing agreement carries the delete-or-return duty with no timeline attached, and it is seventeen months older than the terms that hollow out the return half.

That clause is not unique to the CRM either. The same page carries a second, near-identical sentence applying the same no-access rule to the other Hub subscription services. The 30 day window is the exception, and it covers two Marketing Hub tiers.

None of this is a scandal and none of it is hidden. It is published, current, and written plainly. It is simply that nobody reads it until the week they need it, which is the week it stops being negotiable.

The practical consequence is a sequencing one. If your retrieval window opens at termination, then cancelling the old contract before the new system is verified turns a recoverable problem into a permanent one. That is the single most expensive mistake available here, and it costs nothing to avoid.

Who is the controller and who is the processor during a CRM migration

You are the controller. The CRM vendor is a processor. A migration partner who touches the data is also a processor, and the regulation is specific about what that means: a processor acts only on documented instructions from the controller, cannot bring in a subcontractor without your written authorisation, and has to let you audit them.

Then there is the sentence that actually answers the custody question, and it is worth reading slowly, because a migration is full of decisions that look technical and are not.

Which of two conflicting records survives a merge. Which fields get dropped as legacy. How long the working copy lives on the partner's infrastructure after go-live. Those are purposes and means. If your partner is making them alone, the paperwork saying they are a processor has stopped describing what is happening.

The fix is not complicated and it is not legal theatre. Write the decisions down before the work starts, as instructions, and keep the record. The regulation also requires that at the end of the job the processor deletes or returns everything, at your choice, and deletes remaining copies. The European Data Protection Board's guidance goes further: you decide at the beginning, you put it in the contract, the contract says how you can change your mind, and the processor confirms back to you that deletion actually happened.

One honest note on backups, because this is where the tidy version falls apart. The UK regulator has published the sensible position: it may not be possible to delete data in backups immediately, and provided the data is put beyond use and deleted on the next destruction cycle, that can be acceptable. HubSpot's own agreement describes exactly that arrangement from the processor's side, and attaches no timeline to it beyond "in accordance with our deletion practices". Ask what the cycle is. It is a fair question with a real answer.

What the EU Data Act changed on 12 September 2025

If you are an EU or EEA customer, you now have a statutory switching right that does not depend on what your vendor felt like offering. Regulation (EU) 2023/2854 has applied since 12 September 2025, and it puts hard numbers on the exit.

Notice to start switching is capped at two months. The transition period is a maximum of 30 calendar days, and during it the provider has to maintain business continuity and tell you about known risks to it. After the transition ends you get a minimum of 30 calendar days to retrieve your data. After that the provider must guarantee full erasure. If the 30 day transition is technically unfeasible, they have 14 working days to tell you so, justify it, and offer an alternative that cannot exceed seven months. And from 12 January 2027 they cannot charge you for switching at all.

Three of the ten name it in a document you can read without logging in. Microsoft Dynamics 365 carries a dedicated EU Data Act section in its data protection addendum, with Switching defined as a contract term. Salesforce sets out the two month notification, the 30 day transition and the 14 working day unfeasibility notice in its Main Services Agreement. Pipedrive's terms state that an EU Data Act Addendum applies automatically to clients in scope, from the application date.

A narrow, checkable observation about the third: HubSpot's Customer Terms of Service, Product Specific Terms and Data Processing Agreement, all fetched on 7 September 2026 and all last modified 14 April 2026, contain no occurrence of "Data Act", "2023/2854" or "switching". That is a statement about four documents on one date. It is not a compliance conclusion, and whether any given service falls inside the regulation's definition is a question for your own counsel and your own contract.

What it does mean practically: if you are in the EU, ask. The right exists whether or not the vendor's marketing mentions it.

Three questions to settle before any data moves

The rollback plan below settles the trigger and the revert window, and the controller question is settled above. These three are what is left. Each has a factual answer, each takes under an hour, and none of them stays answerable once the migration is running.

Can you produce a complete export today, on an account you hold? Not "can we request one from the vendor" and not "the agency handles that". Go and run it, on the login your own team controls, and read what actually comes out. This is the question people skip, because they assume they know the answer.

How many days after termination does your contract give you, and is the account live during them? Count them off the clause itself, not off the marketing page. Under 30 days is a problem: a migration at this size does not finish inside a fortnight, and if the account closes at termination the window is decorative. Five of the ten contracts above name no period at all, so your honest answer may be zero.

Who deletes the partner's copy when the project closes, and who confirms it back to you in writing? If the answer is "they would tell us", there is no answer. A deletion nobody confirms is a copy that still exists somewhere you cannot account for, and it stays your problem, not theirs.

None of the three needs the vendor or a partner to answer, and that is the point: a system you cannot export on a login you hold is not one you control, whatever the contract says about ownership.

The rollback plan the guides promise and never write

Every migration guide names rollback. Almost none defines it. Across the pages currently ranking for this topic there is exactly one number, a 48 hour revert window that applies to spreadsheet imports inside one product, and not a single defined trigger. The word appears, the plan does not.

The regulation is more useful here than the guides are. Security measures have to include the ability to restore availability and access to personal data in a timely manner after an incident, and there has to be a process for regularly testing whether those measures actually work. A restore you have never tested is not a restore capability, it is an assumption.

Three things turn that into something you can operate.

1. 1.
   Write the trigger before you start

   A trigger is a measurable condition, not a feeling. "More than 2% of deals arrive without an owner", "any closed-won record loses its close date", "the first delta sync produces more than 50 conflicts". Name the number and name the person who is allowed to call it. A trigger nobody is authorised to pull is decoration.

2. 2.
   Define the window, and check the old system is alive inside it

   Decide how many days you can revert within, then verify the old instance stays readable for that entire period. This is where the termination clause and the rollback plan meet: if your window is 14 days and your retrieval right expires at termination, do not cancel until day 15. Keep the old subscription running in parallel and treat it as the cost of the insurance.

3. 3.
   Restore the backup once, before you need it

   Take the backup, then restore it somewhere and open it. Count the records. Check that a deal still points at its company and its owner. Almost everyone takes the backup. Very few prove it comes back, and an unopened backup is where migrations go to fail quietly.

A clean record count is not a successful CRM migration

In 2018 TSB moved its customer and corporate services onto a new platform. The regulator's own account of what happened is worth quoting exactly, because it describes the failure mode nobody plans for: "While the data itself migrated successfully, the platform immediately experienced technical failures."

All of TSB's branches and a significant proportion of its customers were affected, and it took until December to return to business as usual.

The regulators did not find a technology failure. They found a planning one.

That is a retail bank core banking platform, not a CRM, and the scale is nothing like a typical CRM migration. Use it for the mechanism, not as a proxy for your risk. The mechanism transfers exactly: every record arrived, and the thing still did not work.

So verification cannot stop at counting rows. Count them, then check that the relationships survived, that a deal still resolves to its company and its owner, that automations fire on a test record, and that the three reports leadership actually opens still return the same numbers they did last week. Row counts match long before a system works.

Routing is the one to test hardest, because it fails silently. Nobody files a complaint about a lead that was assigned to a person who left, so the queue looks healthy right up until someone counts it.

About the failure rates you are going to be quoted

You will meet one number constantly on this topic: 83% of data migration projects fail or exceed their budgets, according to Gartner. We followed it to the end.

Two further breaks. "Bloor Group" and "Bloor Research" are different firms. And Bloor Research's own 2007 white paper, which we opened, says "more than 60%", not more than 80%. Somebody added twenty points somewhere along the way.

There is also no citable figure for how much data a CRM migration typically loses. We looked. What exists is first-name anecdotes on vendor blogs. That absence is the argument for measuring your own: count the records in both systems before and after, and the number you get is true about your business, which no industry average ever is.

Both belong at the front of the order you run the project in, because everything after them depends on the answers. An hour spent on the export and the termination clause is the cheapest insurance in this whole project, and you can spend it this afternoon without asking anyone.