Español

User Access During CRM Migration: The Least-Privilege Approach

A mid-market company ran a CRM migration over a holiday weekend. To keep things moving, IT gave all 40 sales reps admin access to the new system during the cutover window — figuring it would help them explore and self-serve any issues.

By Sunday evening, 40 reps had logged deals, updated stages, and added contacts. Some had been entering data into both the old system and the new one simultaneously, not sure which was official. When a data integrity failure was discovered Monday morning and IT needed to roll back, they couldn't. The new system had 72 hours of rep activity in it. The old system had 72 hours of parallel rep activity in it. Neither was a clean source of truth.

The rollback option was gone. The migration took three more weeks to reconcile manually.

The access model wasn't a detail — it was the foundation. This guide covers the three-phase access model that keeps migrations clean and rollbacks possible. It works in close coordination with rollback planning: hope you don't need it — the Phase 2 access controls here are exactly what determine whether a rollback is clean or chaotic.

The Three Phases That Need Different Access Models

CRM migrations don't happen in a single moment. They have three distinct phases, each with different access requirements. The NIST Cybersecurity Framework uses a similar phase-based model for system transitions, where access controls and privilege scoping during change windows are core to maintaining data integrity and audit readiness.

Phase 1: Pre-migration — The period before cutover, when the migration team is testing, mapping, and running shadow imports in a sandbox or staging environment. The source system is still the system of record.

Phase 2: Cutover window — The active migration period, from the moment the source system is locked (or read-only) to the moment the destination system is validated and opened to the team. This is the highest-risk window.

Phase 3: Post-migration — After the destination system is validated and the team starts working in it. The source system still exists but is no longer the system of record.

Each phase requires different answers to: who has access to what, in which system, with what permissions?

Phase 1: Pre-Migration Access

During the pre-migration period, the source system is still live and the destination system exists for testing only.

Source system (still the system of record):

  • All reps retain normal working access
  • No changes to source system permissions
  • Admins should document the current permission structure before any migration work begins — this is your rollback reference

Destination system (testing only):

  • Migration team: admin access for configuration, import testing, and field mapping
  • Power users: read-only access for UI feedback ("does the layout make sense?")
  • All other reps: no access yet

Why no rep access to the destination during testing? Two reasons. First, reps who see the system early form opinions and ask questions before it's configured correctly — this creates noise and misplaced feedback. Second, any data they touch in a test environment creates cleanup work before go-live. Testing with a shadow import happens during this phase — it's the migration team's work, done in the destination before reps ever see it.

Keep the source system as the system of record. This sounds obvious, but migrations sometimes fail because the team starts treating the destination as authoritative before validation is complete. During Phase 1, all active deal management, note-taking, and contact updates happen in the source system. Nothing changes.

Phase 2: Cutover Window Access Controls

The cutover window is the period from "source system locked" to "destination system validated." It's the highest-risk period of the migration, and access control during this window is what makes rollback possible or impossible.

Option A: Full freeze (recommended for most teams)

Source system: read-only for all users. No new records, no updates, no deals logged. Destination system: migration team only during import. Reps get access after validation is complete.

This is the cleanest approach. No data enters either system during the window. If rollback is needed, the source system is in the exact state it was at freeze time. There's nothing to reconcile.

The tradeoff: reps can't log deals or update records for the duration of the window. For most teams this is 4-12 hours. Communicate the freeze window well in advance and choose a low-activity period (weekend, end of quarter after close).

Option B: Read-only source, limited destination access

Source system: read-only for all users. Destination system: migration team has admin access; power users get limited access for testing.

This works for migrations that take longer than a day and where power users need to verify their own data during the process. The risk: any changes power users make in the destination need to be tracked separately in case of rollback.

Option C: Source still active, destination locked to migration team

Source system: full access continues for reps. Destination system: migration team only.

This is the right approach when the migration window needs to be extended or when the business can't tolerate any CRM downtime. The risk: the source system continues to accumulate changes during the migration, which creates a data reconciliation step before the destination goes live. Budget time for it.

For most migrations, Option A is the right default. A 6-8 hour freeze window over a weekend is manageable. The alternatives add reconciliation complexity that frequently causes problems.

Phase 3: Post-Migration Phased Rollout

After the destination system is validated and ready, don't open it to everyone simultaneously. Roll out access by team or region.

Phased rollout approach:

  1. Power users first (Day 1) — The 2-3 reps who got preview access during Phase 1. They know the system, they can answer peer questions, and they'll surface any residual issues before the broader team encounters them.

  2. Team leads and managers (Day 2-3) — They need to verify their team's pipeline data before their reps start working in it. A manager who spots a data issue on day two can flag it before 10 reps build activity on top of it.

  3. Full team (Day 3-5) — All remaining reps get access once managers have confirmed their pipeline data looks correct.

Handling stragglers on the old system:

There will be reps who continue logging calls and deals in the source system after the destination is live. They either didn't get the memo, forgot, or are resisting the change. Identify these reps within the first 48 hours using login activity reports (if available) or by checking whether deals are being logged in the source system. Communicating the migration to the sales team covers how to handle these reps — the communication plan addresses the "zombie signal" before it becomes a data reconciliation problem.

Don't shame them. Call it out factually: "We noticed you're still logging in [old CRM]. Your active deals have already been migrated to [new CRM] — here's a 10-minute walkthrough." Have the communication ready before go-live.

The Migration Team's Access Model

The migration team itself needs a defined access structure. Ad-hoc admin access during a migration creates audit trail problems.

What the migration team needs:

  • System admin role on the destination CRM for configuration changes
  • Import/export permissions on both systems
  • Access to error logs and import history
  • Ability to create and delete records during testing

Two-admin rule: Have two people with separate credentials who can take independent admin actions. If one person is unavailable during a cutover issue, the other can continue. A single shared admin login creates a single point of failure and muddies the audit trail (you can't tell who made which change). The Wikipedia principle of least privilege is the foundational security concept behind this approach — granting only the minimum permissions necessary for each role during a defined operational window.

Audit log configuration: Enable audit logging before the migration begins. Every record creation, update, and deletion during the cutover window should be logged with a timestamp and user ID. This is your evidence if something goes wrong and you need to understand the sequence of events.

Revoking migration-window permissions: After the destination system is validated and the phased rollout completes, revoke the expanded migration-team permissions. The admins who needed elevated access during migration don't need it in steady-state. Document the permission changes made and undo them explicitly — don't rely on memory.

Handling Exceptions in Real Time

During a cutover window, someone will need urgent access. A deal will be due. A contract will need a phone number. Plan for exceptions before they happen.

The exception handling path:

  1. Rep contacts the designated migration team contact (not IT helpdesk — a specific named person)
  2. Migration team contact assesses urgency: is this a genuine business-critical need or a workaround request?
  3. If critical: provide read-only access to the source system for the specific lookup needed, or retrieve the information manually and relay it
  4. All exceptions are logged with: timestamp, rep name, what was accessed, business reason

What to tell reps about the exception path before the cutover window:

"During the migration window, the CRM will be read-only [or unavailable]. If you have an urgent need — active deal about to close, contract to sign, customer waiting — contact [name] at [contact method]. We'll help you get what you need without disrupting the migration."

This message needs to go out before the cutover window begins. If reps don't know the exception path exists, they'll find their own workarounds — which usually means logging data somewhere unofficial.

The Three-Phase Access Matrix

Phase Source system Destination system Who has admin
Pre-migration All users: normal access Migration team: admin; Power users: read-only; Others: no access Migration team only
Cutover window (Option A) All users: read-only Migration team: admin only Migration team only
Post-migration (Day 1-3) All users: read-only Power users + managers: full access Migration team (still resolving issues)
Post-migration (Day 3+) Decommissioning All users: full access Normal admin model

Common Pitfalls

Giving all reps admin access "temporarily." Temporary admin access rarely stays temporary. Reps who discover they can change record ownership, delete records, or bypass validation rules will sometimes use those capabilities — not maliciously, but because they're trying to solve a problem in front of them. Deloitte's IT controls research consistently identifies uncontrolled access expansion during system transitions as among the top causes of post-migration audit findings and data integrity failures. Define the minimum permission level each role actually needs during migration and apply it.

Not revoking migration-window permissions after cutover. The migration team's elevated permissions during cutover should be explicitly revoked after the phased rollout completes. Create a post-migration task to audit and reset permissions.

Forgetting to update SSO/SCIM provisioning for the new system. If your company uses SAML SSO or SCIM for user provisioning, the new CRM needs to be added to the identity provider before go-live. Missing this means reps get a login error when they try to access the new system on day one — regardless of what access you've granted them in the CRM itself. Roles and permissions setup for CRM admins covers the steady-state permission model you'll configure after the migration-window permissions are revoked.

No written access plan. Verbal agreements about who gets access when don't survive the chaos of a cutover window. Write the access matrix down. Share it with the migration team, IT, and the sales manager before the migration begins.

What to Do Next

Draft the access matrix before scheduling the cutover date. The access plan needs to be reviewed and approved by IT and the sales manager — not decided on the day of migration.

The access model connects directly to communicating the migration to the sales team — reps need to understand the cutover window, the read-only period, and the exception handling path before the migration happens.

And if you're building the rollback plan, rollback planning: hope you don't need it shows how the Phase 2 access model determines whether rollback is even possible — the connection between read-only source and clean rollback execution is direct.

For the cutover day itself, cutover day: the checklist that prevents disasters incorporates the access model into the go/no-go checklist that runs before the import begins.

Learn More