How CRM migrations expose customer data, and how to prevent it
The six moments in a migration when customer data is most exposed, and the control that closes each one.
The short answer: Customer data is most exposed during a CRM migration at six points: the first spreadsheet export, vendor access, shared credentials, test environments full of real data, staging copies nobody deletes, and over-broad access in the new system. Each has a control: API-only transfer, named and time-limited access, a password manager, masking, certified destruction and tested permissions.
When executives picture a data breach, they picture an attacker. In a CRM migration, exposure usually comes from somewhere more ordinary: the project itself. A migration takes every customer record you have out of the system that has been protecting it and moves it somewhere new, often with outside help and a deadline.
There are six moments when customer data is most exposed. Each one has a straightforward control.
1. The first export “to see what we’ve got”
Almost every migration starts with someone exporting contacts, companies and deals to a spreadsheet. That file is your complete customer list, and it gets saved to a laptop, uploaded to a shared drive and emailed to the vendor.
The control: profile the data where it lives. Record counts, field usage and duplicates can be measured through the CRM’s API without producing a file anyone can forward. See why you shouldn’t move your CRM through spreadsheets.
2. Granting access to the vendor
A migration partner needs admin-level access to your old CRM and to HubSpot. It’s often granted in a hurry, with no end date. Months later, someone who has left the vendor can still log in.
The control: named accounts only, minimum permissions and an end date set when access is granted. Keep a written list of who has access to what.
3. Credentials in the wrong places
Migrations run on API keys, private app tokens and integration users. Anyone holding one can read or export your data. On busy projects they end up in email, chat threads and scripts in shared folders.
The control: share secrets only through a password manager, scope each token to what it needs, and revoke every one at closeout.
4. Test environments full of real data
Rehearsals need somewhere to run. Often that’s a test portal loaded with a full copy of your customers, with looser access than production because “it’s only test.”
The control: mask sensitive fields unless a test needs real values, restrict access to the project team, and delete the test data at closeout.
5. Staging copies nobody deletes
Migration tools and scripts often write data to an intermediate location: a staging database, a storage bucket, a folder of transformed files. When the project ends, attention moves to go-live and the staging copy stays where it is.
The control: keep an inventory of everywhere data is written during the project, and require written confirmation that each copy has been destroyed.
6. Over-sharing in HubSpot
During a migration it’s tempting to give everyone broad access so nothing gets blocked. Suddenly every user can see and export every record.
The control: set HubSpot user permissions and team visibility as part of the build, restrict who can export, and test permissions during user acceptance testing. HubSpot also lets admins require approval for large or sensitive exports.
What good looks like
Before the project starts, you know who will have access, how data will move, where copies will exist and how all of it will be closed down. At the end, you have proof. The CRM migration security checklist turns this into questions you can put to any vendor. Our own approach is on the security page.
Sources and further reading
- Require approvals for exports, HubSpot Knowledge Base
- GDPR Article 28: Processor, GDPR text
Platform features and policies change. Check the vendor’s current documentation before acting on any detail in this article. This article is general information, not legal advice.