Hyperforce migrations are scheduled by Salesforce, but customer preparation makes the difference between a smooth migration and a disrupted one. The workflow below covers the standard customer-side preparation for an upcoming Hyperforce move.
- Read the migration notification carefully
Salesforce notifies customers of an upcoming Hyperforce migration with the target window, the destination region, and any preparation requirements. Read the notification end to end. The IP allowlist changes and any integration-specific guidance are buried in the details, and skimming the notification can miss the steps that matter for your org. Forward the notification to integration owners, security, and compliance teams, and schedule a brief review meeting to align on responsibilities.
- Update IP allowlists on internal systems
Identify any internal firewall, proxy, or network gateway that has Salesforce IP ranges allowlisted. Add the Hyperforce IP ranges for your target region to those allowlists before the migration window. Salesforce publishes the IP ranges in the Trust documentation. Failing to update allowlists results in Apex callouts, integrations, and outbound API calls failing immediately after migration with no obvious error message at the Salesforce level.
- Audit and update hardcoded Salesforce URLs
Search the org's external integrations for any hardcoded references to legacy Salesforce domain patterns. While most URLs use the My Domain pattern that survives migration unchanged, some legacy integrations might reference instance-specific URLs (na123.salesforce.com) that will change. Update these to use My Domain or login.salesforce.com instead. Document every integration that was checked so the audit is repeatable if the migration is rescheduled or if questions come up afterwards.
- Test in sandbox before, validate in production after
If your sandbox has already been migrated to Hyperforce (Salesforce typically migrates sandboxes first), run a full integration regression test in that sandbox. Use the results to identify any production-side issues to address. After the production migration, run the same regression in production to confirm everything works. Communicate the green status to stakeholders. Stay available for the 24 to 48 hours after migration in case any unexpected issue surfaces with low-volume integrations that the regression did not exercise.
- Hardcoded IP allowlists on internal firewalls are the most common failure mode. The Salesforce side migrates fine; the internal side blocks the new IPs and integrations break silently.
- Some advanced features run only in specific Hyperforce regions. Data Cloud, Agentforce, and certain Industry Clouds may force data movement out of your primary region.
- Sandbox migration timing differs from production. Plan on testing in a migrated sandbox before production migration if you want a real preview of Hyperforce behavior.
- DKIM, SPF, and DMARC records may need updates if outbound email uses Salesforce IP ranges directly rather than the standard mail relay paths.
- Salesforce Trust site publishes Hyperforce-specific status pages. Bookmark the right page for your region rather than the legacy general status page.