Hyperforce Assistant
Hyperforce Assistant is the Setup-guided migration tool that helps Salesforce admins evaluate and migrate their orgs from legacy first-party-pod infrastructure to Hyperforce, Salesforce''s public-cloud-based infrastructure platform.
Definition
Hyperforce Assistant is the Setup-guided migration tool that helps Salesforce admins evaluate and migrate their orgs from legacy first-party-pod infrastructure to Hyperforce, Salesforce''s public-cloud-based infrastructure platform. Hyperforce is the long-term replacement for the Salesforce-managed data centers; it runs on AWS (and selected hyperscalers) inside customer-aligned regions and brings benefits like data residency by region, faster provisioning, and tighter compliance certifications. The Assistant guides admins through readiness checks, migration scheduling, and post-migration verification.
The Assistant sits in Setup under Hyperforce Migration Assistant (the exact node name varies by release). It runs prerequisite checks: confirms the org is on a supported release, identifies legacy features incompatible with Hyperforce, surfaces integrations that may need IP allow-list updates, and shows expected downtime windows. It also coordinates the migration scheduling, which historically required filing a Salesforce Support case manually. The whole experience is designed to make a non-trivial infrastructure move feel like a guided wizard.
What the Assistant covers in a Hyperforce migration
What Hyperforce is
Hyperforce is the public-cloud-based infrastructure platform Salesforce launched in 2021. It runs Salesforce orgs on AWS (and selected other hyperscalers) in geographically aligned regions, replacing the legacy Salesforce-managed first-party pods. Hyperforce brings data residency by region (EU data stays in EU, US data stays in US, India data stays in India), faster provisioning of new orgs, and tighter compliance certifications like FedRAMP High. Every new Salesforce org provisioned since 2023 has been on Hyperforce; existing pre-2023 orgs are being migrated.
The migration scheduling
Hyperforce migrations are scheduled by Salesforce Customer Trust on a per-org basis, typically over a multi-hour window during a weekend. The Assistant shows the proposed window and lets admins flag conflicts (a critical month-end close, a regulated reporting deadline). Salesforce reschedules around these conflicts. The migration itself is a data-and-metadata copy from the legacy pod to the Hyperforce region, with a brief read-only window during the cutover.
Readiness checks
The Assistant runs a battery of readiness checks before the migration is scheduled. The checks cover: deprecated features the org still uses (Lightning experience, Locker Service, retired APIs), integrations with hard-coded IP addresses that need updating to the new Hyperforce IP ranges, and custom code that references pod-specific URLs (na1.salesforce.com style hostnames). Each failure produces a remediation task; the migration cannot proceed until all blockers are resolved.
IP allow-list updates
The most common readiness blocker is integration IP allow-lists. Customers running Salesforce-to-external integrations through firewalls have allow-listed the legacy pod IP ranges. Hyperforce uses different ranges (AWS regions), so the firewall must be updated before migration. Salesforce publishes the new ranges; the Assistant flags integrations likely to be affected based on org usage patterns.
URL changes and custom domain
Post-migration, the org gets a new My Domain URL (companyname.my.salesforce.com), and the legacy pod URL (na1.salesforce.com) becomes a redirect. Custom code that references the pod URL directly must update to the My Domain URL. The Assistant identifies pod-URL references in Apex, Lightning Web Components, and Flow formulas via the standard tool integration.
Sandbox and production migration sequencing
Salesforce migrates sandboxes ahead of production, giving customers a chance to validate the new environment without risk. The Assistant tracks the sequence and surfaces remediation tasks per sandbox before production migration is scheduled. Most customers spend a quarter validating sandboxes before going live in production.
Post-migration verification
After the migration, the Assistant runs post-cutover checks: confirms data integrity, verifies integrations are still callable, surfaces any URL or IP issues that slipped through. Customers also run their own regression suite. Salesforce extends a support window for the first few weeks to handle any issues that surface.
Run the Hyperforce Assistant on your org
The Assistant runs in Setup. Plan a multi-week project from first scan to post-migration validation; the actual cutover takes hours, but the readiness work takes longer.
- Open the Hyperforce Migration Assistant
Setup, Quick Find, type Hyperforce. The Assistant page opens with current status, expected migration window, and a list of readiness tasks.
- Run the readiness scan
Click Run Scan. The Assistant evaluates the org against the current Hyperforce compatibility requirements and produces a list of remediation tasks.
- Work through readiness tasks
Address each task: update IP allow-lists, replace deprecated APIs, fix pod-URL references in code. The Assistant tracks completion as each task is resolved.
- Coordinate the migration window
Once readiness is green, work with the Salesforce account team to schedule the migration. The Assistant proposes a window; review with stakeholders, confirm or reschedule.
- Test in sandbox first
Migrate a sandbox ahead of production. Run integration regression tests, validate every external IP allow-list, confirm Apex callouts still work.
- Execute production migration
On the scheduled window, the org goes read-only briefly. The Assistant shows live status; users see a maintenance notice. Once complete, run post-cutover verification.
- IP allow-list updates require coordination with the customer''s network team. The Salesforce-side admin alone cannot fix firewall config; planning multi-team work is part of the migration.
- Custom code referencing pod URLs (na1.salesforce.com, na12.salesforce.com) silently breaks if the URL is hardcoded. Find every reference before migration day.
- Sandbox migrations precede production. Skipping sandbox validation increases the risk that production migration surfaces issues at the worst time.
- Customer Trust schedules migrations; admins cannot self-serve a date. Negotiation is required for tight-window orgs with regulated reporting deadlines.
Trust & references
Cross-checked against the following references.
- Hyperforce OverviewSalesforce Help
- Migrate to HyperforceSalesforce Help
Straight from the source - Salesforce's reference material on Hyperforce Assistant.
- Hyperforce AssistantSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. How does Salesforce's multi-tenant model affect Hyperforce Assistant?
Q2. Who can benefit from understanding Hyperforce Assistant?
Q3. What architecture concept is Hyperforce Assistant an example of?
Discussion
Loading discussion…