This applies whether your listings workflow runs through Synup, Yext, Uberall, Rio SEO, or another multi-location platform. Routine changes to addresses, phone numbers, URLs, permanent hours, categories, and location status should usually stop, while urgent customer-facing updates should continue through a controlled exception process with documented approval and post-cutover reconciliation.
The freeze does not need to block urgent customer-facing corrections. Emergency closures, safety-related updates, or materially incorrect hours can continue through a separate approval workflow. Everything else should wait until the new source of truth is stable.
Key Takeaways
- Start the hard listings freeze before the final CRM delta migration or before integrations are redirected to the new CRM.
- Pause routine changes to addresses, phones, categories, URLs, permanent hours, location status, and other fields connected to CRM records.
- Keep emergency changes available through a controlled exception process with named approvers.
- Maintain an approved location-data snapshot and exception ledger during cutover rather than allowing two systems to become competing sources of truth.
- Do not resume normal listings editing simply because the new CRM has gone live. Validate records, integrations, queued jobs, field mappings, and publisher-facing data first.
- For large multi-location organizations, reopen editing in phases rather than releasing every location and integration simultaneously.
Quick CRM Cutover Listings Management Guide
| Cutover stage | Listings policy | Typical activity |
|---|---|---|
| 5-7 days before cutover | Soft freeze | Avoid structural location-data changes and clean outstanding requests |
| 24-48 hours before final migration | Hard freeze | Stop normal listing and CRM location-data edits |
| During cutover | Exceptions only | Process closures, safety issues, critical hours, or severe data errors |
| Immediately after CRM go-live | Freeze remains | Reconcile migrated data and verify integration health |
| Validation period | Controlled reopening | Test canary locations and selected change types |
| After sign-off | Normal editing resumes | Restore standard workflows and process queued requests |
The exact number of hours depends on your migration design. The better rule is to tie the freeze to migration milestones rather than a generic clock.
Microsoft's current Dynamics 365 guidance describes cutover as the controlled switch between old and new systems and calls for defined roles, verification steps, go/no-go criteria, and a rollback plan. It also notes that traditional cutover windows are often short and highly coordinated. Microsoft's cutover planning guidance
What Is a Listings Change Freeze?
A listings change freeze is a temporary restriction on ordinary changes to business-location data while an organization moves, remaps, validates, or reconnects the systems responsible for that data.
It does not necessarily mean switching off your listings software.
The goal is to stop uncontrolled writes.
A location record may exist in several systems at once:
- CRM
- master data management system
- ERP
- store operations database
- franchise management system
- local listings platform
- middleware or integration platform
- Google Business Profile
- Apple Business
- Bing and other publishers
- local landing-page CMS
During normal operations, that architecture may work because the team knows which system owns each field and integrations run in a predictable direction.
CRM migration temporarily changes those assumptions.
A field that previously flowed from CRM A to middleware and then into the listings platform might begin flowing from CRM B instead. Old scheduled jobs may still exist. Record IDs can change. Field names may be remapped. Imports can replay outdated values. Manual edits can occur while the migration is still moving data.
A listings freeze limits the number of variables the cutover team needs to control.
For broader operational and data-management coverage, teams can also reference Miidasu's business operations resources when documenting their migration procedures.
Why Listings Are Vulnerable During a CRM Cutover
Listings data looks simple until several systems are allowed to edit it.
Consider a 600-location retailer migrating to a new CRM.
At 6:00 p.m., the migration team extracts the current phone number for Store 214.
At 6:20 p.m., a regional operations manager updates that phone number in the old CRM.
At 7:00 p.m., the new CRM is loaded with the 6:00 p.m. value.
At 8:30 p.m., an integration from the new CRM pushes that older number to the listings platform.
The manager's valid 6:20 p.m. change disappears.
You can also get the reverse problem. An old integration that nobody disabled may send data back after the new integration becomes active.
These are classic migration conflicts:
Stale overwrites: An older value is written over a newer one.
Duplicate records: Migration creates a second location because the target system cannot match the existing record.
Identity drift: Store codes, CRM IDs, listing IDs, or publisher IDs no longer point to the same physical location.
Queue replay: Messages waiting in an integration queue execute after the new system becomes live.
Bidirectional conflict: Two applications both believe they own a field.
Manual-versus-automated conflict: A manager corrects information manually, then an integration replaces it.
Salesforce's current migration guidance recommends preserving legacy identifiers, using external IDs where appropriate, validating imported records, reviewing errors, and comparing migrated data with the source. Those practices are especially relevant to multi-location data because a stable location identifier is often what prevents one branch from becoming two records during migration. Salesforce data migration best practices
When Should Operations Introduce the Freeze?
Operations should begin restricting listings changes before the final production migration starts, not after errors begin appearing.
A useful approach is to use two levels of control.
Soft Freeze: About 5-7 Days Before Cutover
A soft freeze does not stop all work.
It reduces avoidable change.
During this period, postpone changes such as:
- optional category refinements
- description rewrites
- new tracking URLs
- nonessential phone-number changes
- ordinary photos
- long-term attribute cleanup
- naming-format changes
- routine landing-page URL adjustments
The purpose is to reduce the backlog of moving data entering the final cutover.
Teams should also resolve as many pending corrections as possible before this stage.
Hard Freeze: Before the Final Delta Extract
The hard freeze should begin before the last approved production snapshot, final delta migration, or integration switchover.
From that point forward, routine location edits should stop in:
- the legacy CRM
- the new CRM
- listings software
- spreadsheets feeding either system
- internal administrative tools
- franchise portals
- automation workflows
- integration middleware
This is the point where "please don't edit Salesforce" is insufficient.
The restriction must cover every system capable of changing the same downstream location data.
Keep the Freeze After CRM Go-Live
One of the most common mistakes is ending the freeze when users can log into the new CRM.
A successful login proves very little about listings synchronization.
Microsoft's go-live checklist calls for data migration validation, integration testing, verification steps, dependency checks, operational support readiness, and stakeholder sign-off. Microsoft's go-live readiness checklist
For listings operations, the freeze should remain until the team verifies the complete route:
New CRM → integration layer → listings platform → major publishers
Which Listings Edits Should Be Paused?
Not every listings field carries the same operational risk.
| Change type | During hard freeze | Reason |
|---|---|---|
| Permanent address | Pause | High identity and verification impact |
| Business name | Pause | Can affect matching and verification |
| Primary phone | Usually pause | Common CRM-controlled field |
| Permanent hours | Pause unless urgent | May be overwritten during migration |
| Store code/location ID | Always pause | Critical record identity field |
| Open/closed status | Exception only | High customer impact |
| Primary category | Pause | Usually non-emergency |
| Website URL | Pause | Common integration-controlled field |
| Tracking parameters | Pause | Low urgency |
| Photos | Pause | Rarely cutover-critical |
| Descriptions | Pause | Low operational urgency |
| Attributes | Usually pause | Can wait unless legally or operationally required |
| Emergency closure | Allow through exception | Immediate customer impact |
| Emergency opening-hours change | Allow through exception | Immediate customer impact |
| Critical wrong address | Allow through exception | Could send customers to wrong place |
The important rule is ownership.
If a field will be migrated, mapped, synchronized, or reconciled as part of the CRM cutover, ordinary users should not be changing it independently during the hard freeze.
Which Changes Should Be Treated as Exceptions?
A listings freeze cannot ignore the physical business.
Stores still close unexpectedly. Weather events occur. Phones fail. Buildings lose power. A healthcare office may close temporarily. A restaurant may have to shut because of a safety problem.
Exception handling should therefore stay available for changes that materially affect a customer's ability to visit or contact the business.
Good exception candidates include:
- unexpected closure
- emergency hours
- disaster or weather closure
- serious address error
- disconnected customer-facing phone number
- temporary service interruption
- legally required correction
- opening-status error affecting a live location
Google allows verified businesses to update customer-facing information such as address, phone, hours, service area, and closure status. Its Business Profile API also supports field-specific updates through update masks, meaning technical teams can restrict an emergency integration to the exact field requiring correction rather than reopening the entire record. Google Business Profile location-data documentation
That field-level approach is useful during migration.
If Store 412 has to close because of flooding, you want to change its hours or closure state without giving somebody permission to simultaneously update its address, category, URL, phone, and CRM identifiers.
Who Should Approve Emergency Changes?
Do not route emergency exceptions through an informal Slack message and assume somebody will remember to reconcile them later.
Use a defined approval chain.
A practical structure is:
| Situation | Requested by | Approval |
|---|---|---|
| Safety-related closure | Store/Ops manager | Incident lead + listings owner |
| Same-day emergency hours | Regional operations | Listings owner or cutover lead |
| Incorrect address sending customers elsewhere | Listings/Ops | Data owner + cutover lead |
| Broken customer phone | Operations | Data owner |
| Routine SEO change | Marketing | Deferred until freeze ends |
| New category or description | Marketing/local SEO | Deferred |
For high-risk fields such as address, business name, store identity, and location status, use two-person approval during the cutover.
The cutover lead should also know about every exception because each one creates a difference between the original migration snapshot and current reality.
Build a Temporary Source of Truth
During the hard freeze, designate one temporary authoritative dataset.
Do not tell teams that both CRMs are temporarily authoritative.
They cannot both be authoritative when their values differ.
The temporary source can be:
- an approved database snapshot
- an MDM table
- a controlled cutover workbook
- the target CRM after migration reaches a defined stage
- a dedicated location-data repository
The format matters less than the governance.
At minimum, maintain these fields:
| Field | Purpose |
|---|---|
| Stable location ID | Identifies the physical location |
| Legacy CRM ID | Reconciliation |
| New CRM ID | Reconciliation |
| Store/location code | Cross-system matching |
| Business name | Validation |
| Address | Validation |
| Phone | Validation |
| Regular hours | Validation |
| Open/closed status | Critical status |
| Last approved timestamp | Determines freshness |
| Source system | Identifies authority |
| Migration status | Tracks progression |
| Exception status | Shows changes after snapshot |
This also gives operations a clean baseline for comparison after migration.
Maintain an Exception Ledger During Cutover
Every approved change after the snapshot should enter a cutover exception ledger.
Include:
- location ID
- field changed
- previous value
- new value
- reason
- requester
- approver
- timestamp
- system where change was made
- publishers affected
- reconciliation status
For example:
| Location | Field | Previous | New | Reason | Status |
|---|---|---|---|---|---|
| US-0184 | Special hours | 9-7 | Closed | Power outage | Reconciled |
| US-0422 | Phone | 312-555-0181 | 312-555-0197 | Main line failure | Pending CRM update |
| US-0710 | Status | Open | Temporarily closed | Storm | Reconciled |
This log becomes essential when the cutover team needs to answer:
"Which production values changed after we extracted the migration data?"
Without that answer, post-cutover reconciliation becomes guesswork.
How Listings Platforms Fit Into the Cutover
Listings software can help centralize distribution, but it does not decide your data governance model for you.
Whether you use Synup, Yext, Uberall, Rio SEO, or another provider, you still need to establish which application owns each field and whether automated writes should continue during migration.
The following products were checked against current first-party materials on October 1, 2026.
Synup
Synup supports listings management across Google Business Profile, Apple, Bing, Facebook, and a network the company currently describes as 100+ publishers. Its listings tools support multi-location management, bulk updates, APIs, automation, duplicate management, and agency or multi-client workflows. Synup's current product materials also describe approval controls for sensitive actions involving core business information. During a CRM cutover, those capabilities can support a controlled model in which scheduled automations and ordinary bulk edits are paused while approved customer-facing changes continue separately. Teams using Synup should identify whether the CRM, Synup, or another repository currently supplies each location field before cutting integrations over. They should also inspect queued automations and API jobs so an old job does not republish pre-migration data after the target CRM becomes authoritative.
Yext
Yext provides listings synchronization along with APIs and webhooks that can connect its content and listings data to other enterprise systems. Its Management API supports moving information between Yext and external systems, which makes integration ownership especially important during migration. A company using CRM-driven location records should determine whether the CRM pushes into Yext, Yext feeds another repository, or synchronization works through middleware before applying its freeze. During cutover, the team may need to suspend selected inbound jobs, outbound jobs, or both rather than disabling listings entirely. Yext's publisher documentation also exposes listing synchronization and monitoring capabilities across supported publishers. Post-cutover testing should confirm entity IDs, field mappings, publisher connection health, and the direction in which each integrated field now moves before normal editors regain access.
Uberall
Uberall's current listings materials describe centralized location information management, real-time API synchronization, bidirectional integrations with key platforms, and duplicate suppression. Its developer documentation provides APIs for location and listing data, which means CRM cutover teams should pay close attention to API credentials, scheduled requests, integration ownership, and whether connections are capable of writing in both directions. A hard freeze may therefore require more than disabling a user interface. Teams should inventory middleware jobs and API clients capable of modifying a location. During validation, they should compare the new CRM values against Uberall's location records and inspect selected downstream listings before normal bulk activity restarts. If emergency changes must be made directly in the listings environment during migration, they should be recorded in the same exception ledger used for the CRM so those changes can be brought back into the new system of record.
Rio SEO
Rio SEO focuses heavily on enterprise and multi-location listings management, including data distribution, duplicate resolution, location-data updates, and direct connections with major discovery platforms such as Google and Apple. Its current Local Listings materials also describe managed listing support, which can introduce another operational participant into the migration process. Companies using Rio SEO should therefore include both internal teams and relevant service contacts in the cutover communication plan where applicable. Before the hard freeze, document how Rio receives location data and which fields can be changed through Local Manager, feeds, APIs, or managed-service requests. During cutover, ordinary changes should enter the shared queue rather than being submitted through an alternate route. When reopening edits, validate that the new authoritative dataset has reached Rio correctly and that several representative locations display the expected information downstream.
CRM Cutover Checklist for Local Listings Teams
Seven Days Before Cutover
Confirm:
- which application currently owns every listings-related field
- the future source of truth
- location IDs and cross-system identifiers
- all CRM-to-listings integrations
- all listings-to-CRM integrations
- scheduled jobs
- middleware flows
- local-manager editing permissions
- API clients
- bulk-upload processes
- franchise or field-level portals
Clear ordinary change requests where possible.
Two or Three Days Before Cutover
Create the approved location-data baseline.
Export key fields such as:
- location ID
- store code
- name
- address
- phone
- URL
- normal hours
- special hours
- categories
- status
Confirm the emergency approval process and circulate it to regional operations, franchisees, marketing, customer service, IT, and local SEO teams.
Before Final Migration
Activate the hard freeze.
Stop routine editing and confirm that automated jobs that could interfere with migration are paused or controlled.
Capture the final snapshot timestamp.
Any change after that timestamp goes into the exception ledger.
During Migration
Monitor:
- migrated record counts
- rejected records
- duplicate records
- missing locations
- key-field transformations
- location ID mapping
- integration errors
- API authentication failures
Salesforce specifically recommends validating migrated information with record comparisons, spot checks, error reports, and migration testing rather than treating a successful import as proof that the data is correct.
What Should Ops Validate Before Lifting the Freeze?
Do not ask only, "Did all CRM records migrate?"
Ask whether the entire location-data chain works.
1. Record Counts Match Expectations
Compare:
- legacy CRM location count
- migration input count
- successful target records
- rejected records
- intentional exclusions
Every difference should have an explanation.
2. Stable IDs Still Match
Confirm that each physical location has the expected:
- legacy ID
- target CRM ID
- store code
- listings-platform ID
Do not depend on business names alone for matching.
3. Critical Fields Reconcile
Compare the source snapshot against the target CRM for:
- address
- phone
- website
- normal hours
- status
- categories
- location name
Investigate unexpected differences.
4. Cutover Exceptions Are Reconciled
Every emergency change made after the final snapshot must now exist in the target source of truth.
An emergency closure made directly in Google but missing from the new CRM is unfinished work.
5. Integration Direction Is Correct
Verify that the new CRM is pushing or receiving information exactly as intended.
Check for retired jobs that may still be running.
6. Queues Are Clear
Inspect:
- message queues
- failed API calls
- retry queues
- ETL logs
- scheduled imports
- webhook failures
A queue containing old values can recreate errors hours after an apparently successful migration.
7. Test a Canary Location
Pick a low-risk location and make one approved test edit.
For example, change a noncritical field with an easily reversible value.
Confirm that it passes through:
CRM → middleware → listings system → intended endpoint
Do not immediately test all 2,000 locations.
8. Check Major Consumer Surfaces
Sample locations on the platforms that matter most to the business.
At minimum, many US multi-location organizations will want to inspect Google and Apple alongside whichever other channels are materially important to their customers.
Apple's current business-location documentation supports normal, service, and temporary hours, including temporary closures and special schedules. That makes hours another field that should be explicitly reconciled if emergency changes occurred during migration. Apple Business location-hours guidance
Resume Listings Editing in Phases
Once validation passes, resist the temptation to reopen everything at once.
Use staged release.
Phase 1: Cutover Team
Restore editing rights only to the central listings and migration team.
Process several queued requests manually.
Watch integrations.
Phase 2: Limited Business Users
Restore access to a small set of regional or operational users.
Monitor:
- API errors
- unexpected overwrites
- duplicate records
- mapping problems
- field ownership conflicts
Phase 3: Full Operations
After the environment remains stable, restore ordinary permissions and bulk editing.
Then work through the backlog created during the freeze.
This phased approach gives you a chance to detect a bad integration rule before hundreds of managers begin changing data.
How Long Should a Listings Change Freeze Last?
There is no universal 24-hour or 48-hour rule.
Define the freeze around these events:
Start: before the final production snapshot, delta extract, or controlled integration shutdown.
End: after migration validation, exception reconciliation, integration testing, publisher sampling, and cutover sign-off.
A straightforward migration with limited integrations may complete this process within a short cutover window.
A franchise network with thousands of locations, multiple CRMs, middleware, local permissions, automated publishers, and location-page systems may need a longer controlled period.
The useful question is not:
"Has the freeze lasted long enough?"
It is:
"Have the exit criteria been satisfied?"
Common CRM Cutover Listings Mistakes
Freezing Only the CRM
Listings platforms, spreadsheets, local portals, APIs, and middleware may still write data.
Freeze the workflow, not merely one application.
Allowing Managers to "Fix It Directly on Google"
That may solve the immediate display problem while leaving the new CRM wrong.
If a direct publisher edit is necessary, log it and reconcile it.
Lifting the Freeze at CRM Go-Live
The CRM can be operational while downstream integration remains broken.
Validate the complete data path first.
Migrating Without Stable Location IDs
Names and addresses change.
Persistent identifiers give systems a stronger way to determine that two records represent the same location.
Forgetting Scheduled Automations
A holiday-hours job or nightly data feed created months earlier can overwrite newly migrated values.
Inventory scheduled work before cutover.
Treating Every Change as an Emergency
Marketing copy, image refreshes, category experiments, UTM adjustments, and ordinary optimization work can usually wait.
Keep your emergency route narrow.
A Practical Cutover Policy Ops Can Use
A workable internal policy could read:
Routine updates to business-location information will enter a hard change freeze before the final CRM production migration. During the freeze, no ordinary updates may be submitted through the legacy CRM, target CRM, listings platform, bulk files, local portals, or automated integrations unless specifically included in the cutover plan.
Customer-critical changes involving closures, emergency hours, safety, materially incorrect contact information, or similar operational issues may be processed through the cutover exception workflow. Every exception must include a stable location identifier, requested change, business reason, approver, timestamp, and reconciliation status.
Normal editing will resume only after target CRM validation, exception reconciliation, integration testing, representative downstream checks, and cutover-owner approval.
Teams formalizing similar processes can maintain the policy alongside their broader Miidasu operational playbooks, rather than treating local listings as a separate marketing-only concern.
Frequently Asked Questions
When should a company pause listings edits during a CRM cutover?
Pause routine listings changes before the final production migration, final delta extract, or integration switchover begins. Continue the freeze until migrated data, exceptions, integrations, and downstream outputs pass agreed validation criteria.
Should local listings updates be completely frozen during CRM migration?
Usually no. Routine changes should stop, but organizations should retain an exception path for customer-critical issues such as unexpected closures, emergency hours, major contact errors, and safety-related changes.
How long should a listings freeze last?
Use milestone-based entry and exit criteria rather than an arbitrary duration. Start before final migration and end only after the new source of truth and downstream integrations have been validated.
What happens to Google Business Profile updates during the freeze?
Ordinary updates should normally follow the same freeze policy as other listings changes. Emergency updates can still be made through the approved exception process and then reconciled back into the new source of truth.
Who should approve emergency listings changes?
Assign the responsibility before cutover. A central listings owner, data owner, cutover lead, or incident lead should approve changes depending on severity. High-risk identity changes should generally require more than one responsible person.
How do multi-location businesses prevent conflicting location data during CRM migration?
Use stable location identifiers, define one temporary source of truth, pause uncontrolled writes, inventory integrations, log all post-snapshot exceptions, and reconcile those exceptions before ending the freeze.
When is it safe to resume listings edits?
Resume after record counts reconcile, IDs map correctly, critical location fields are accurate, exceptions are incorporated, integration queues are clean, test changes flow correctly, and representative publisher listings show the expected information.
Final Recommendation
The safest CRM cutover listings management model is a controlled freeze with a narrow emergency exception path.
Start restricting ordinary location-data changes before the final migration snapshot. During the hard freeze, prevent users, integrations, spreadsheets, automations, and listings tools from independently changing CRM-governed fields. Maintain one temporary authoritative dataset and record every emergency change made after the snapshot.
After go-live, keep the freeze in place until the new CRM has been reconciled and the complete downstream path has been tested. Then reopen access gradually.
The objective is not to stop necessary business changes. It is to make sure every approved change has one clear owner, one traceable path, and one authoritative final value after the CRM cutover is complete.
