How do you handle Salesforce instance / data center moves?

Salesforce occasionally moves orgs between data centers (instance migrations) for capacity, region, or platform reasons.

Common scenarios:

• Hyperforce migration — Salesforce's modern infrastructure. Many orgs being migrated to Hyperforce.
• Region change — moving an org's data center for latency / regulatory.
• Sandbox refresh from a different instance — rare.

Implications:

1. URL changes.

• My Domain URL changes post-migration (e.g., na123.salesforce.com -> acme.my.salesforce.com already mitigates).
• Connected Apps callbacks may need update.
• External integrations referencing instance URL need update.
• Bookmarks and shortcuts by users break.

2. IP address changes.

• Allowlisted IPs in external systems' firewalls need update.
• Salesforce's outbound IPs for callouts change.

3. Performance characteristics.

• Latency to / from external systems may change.
• Data center proximity — different region means different ping.

4. Feature parity.

• Hyperforce vs traditional — feature parity is high but not 100%. Some specific features may differ.

5. Sandbox refreshes.

• After migration, sandbox refresh patterns may change.

Preparation:

1. Salesforce communicates migration window in advance (often 60+ days notice).

2. Inventory:

• All integrations referencing org URL.
• All external systems with IP allowlists.
• All Connected Apps with callback URLs.
• All third-party services with whitelist entries.

3. Update plan:

• Schedule changes coordinated with migration window.
• Test in sandbox post-migration before users notice issues.

4. Communication:

• Users alerted to URL changes.
• Bookmarks need updating.
• Documentation updates.

5. Testing:

• Salesforce provides sandbox migration first.
• Test all critical paths.
• Confirm integrations work.
• Confirm performance acceptable.

6. Cutover:

• Salesforce performs the migration in a maintenance window.
• Typically minimal downtime (minutes to hours).
• Users see brief unavailability.

7. Post-migration validation:

• Confirm all integrations operational.
• Confirm users can log in.
• Monitor for issues.

Architectural strategies that reduce migration pain:

• My Domain instead of generic instance URLs — already migration-resilient.
• Use FQDNs not IPs in integrations.
• Configurable URLs via Custom Metadata, not hardcoded.
• Hostname-based allowlisting instead of IP-based.

Common pitfalls:

• Hardcoded URLs in code — breaks post-migration.
• No inventory — discover broken integrations after migration.
• No test sandbox migration — first hit is production.
• Insufficient user communication — confusion at the new URL.

Senior architect insight: Salesforce-platform changes are the architect's responsibility to plan for. Migrations happen; design with awareness.

Hyperforce is the strategic future. Most orgs will migrate within the next few years; design new builds with Hyperforce in mind.

The senior framing: the platform isn't a static thing. It evolves; architects evolve with it. Build orgs that can absorb platform changes gracefully.