Hyperforce Assistant
A Hyperforce Assistant is the in-Setup guided tool that helps Salesforce admins prepare an org for migration from legacy first-party infrastructure to Hyperforce.
Definition
A Hyperforce Assistant is the in-Setup guided tool that helps Salesforce admins prepare an org for migration from legacy first-party infrastructure to Hyperforce. Hyperforce is Salesforce's public-cloud infrastructure, built on Amazon Web Services and described by Salesforce as composed of code rather than hardware. The Assistant runs org-contextual readiness checks, points to the right help articles, and tracks the preparation work so the cutover goes smoothly.
You reach it in Setup by typing Hyperforce Assistant in the Quick Find box and selecting it. The tool became generally available in the Summer '23 release and runs in both production and sandbox orgs. It organizes the work into two phases, Learn and Prepare, and surfaces the specific tasks your org needs, such as removing hard-coded instance URLs and confirming connectivity to the target Hyperforce instance.
How the Hyperforce Assistant gets your org ready
What Hyperforce is and why orgs move to it
Hyperforce is Salesforce's next-generation infrastructure platform, and it runs on Amazon Web Services rather than the older Salesforce-operated data centers. Salesforce describes it as composed of code rather than hardware, which lets new environments stand up faster and lets customers pick where their data lives. Data residency by region is one of the headline reasons orgs care. A customer in the EU can keep data in an EU region, and the same holds for other supported geographies. Newer orgs are provisioned on Hyperforce from the start, so the Assistant exists for the population of older orgs that still sit on first-party instances. Salesforce migrates these orgs on a schedule, and the company has set firm dates that remove the ability to keep delaying. The June 2026 FAQ notes that after July 1, 2026 it is no longer possible to delay upgrades to Hyperforce. That deadline pressure is exactly why the Assistant matters. It turns a large infrastructure change into a checklist you can work through in advance, with each item linked to official guidance, rather than a support ticket you file blind and hope goes well.
Where it lives and the two phases
You open the Assistant from Setup. Type Hyperforce Assistant into the Quick Find box and select it, the same way you reach any other Setup node. It became generally available in Summer '23 and runs in both sandbox and production orgs, which matters because you usually want to rehearse in a sandbox first. The experience is split into two phases. The Learn phase explains what Hyperforce is and what changes for your org, so the people doing the work understand the why before they touch anything. The Prepare phase is the working checklist. It runs the org-contextual checks, lists the tasks your specific org needs, and links each one to the matching help article. Salesforce has refined the Prepare phase over releases, and the hard-coded references and connectivity checks in particular have been updated for a better experience. Because the checks read your actual metadata and configuration, the task list you see is tailored to your org. Two orgs on the same release can get different lists depending on what integrations, code, and customizations they run.
The readiness checks it runs
The core value of the Assistant is the set of automated, org-contextual checks in the Prepare phase. The two that get the most attention are hard-coded references and connectivity. The hard-coded reference check scans your org for instance-specific URLs, the na1.salesforce.com style hostnames that name a particular instance. Those URLs can break when the org moves, so the Assistant flags where they appear. The connectivity check confirms your org can reach the target Hyperforce instance, which catches network and firewall problems before they cause an outage on cutover day. Each finding is presented as a task with a link to the relevant help article, so an admin is not left guessing how to fix it. The checks are not a one-time gate. You can rerun them as you work through remediation and watch the list shrink. Treat the Assistant as a living dashboard during the preparation window rather than a report you read once. The goal is to reach the migration date with a clean checklist and no surprises waiting in the integrations or the code.
Hard-coded URLs and the My Domain fix
Instance-specific URLs are the most common cleanup task. A reference like na1.salesforce.com hard-codes an instance name, and Salesforce notes that an instance name can change during maintenance such as an instance refresh or an org migration. The durable fix is to use your My Domain login URL instead, in the form myDomainName.my.salesforce.com, because that stays stable across moves. For an API endpoint you would point at https://myDomainName.my.salesforce.com/services/Soap/c/65.0 rather than the instanced host. One useful detail: Hyperforce instance URLs look different, for example swe54.sfdc-cehfhs.salesforce.com, and you cannot use that style of URL to log in, so the old login use case simply does not apply there. Hard-coded references hide in many places. Salesforce lists API calls and integrations, custom Visualforce pages, images in Knowledge articles and email templates, Salesforce Chat, and generated WSDLs from Apex web services. To hunt them down across metadata and code, Salesforce recommends the Salesforce Extensions for Visual Studio Code. Fixing these references is usually the longest pole in the tent, so start it early.
Allowing Salesforce domains and keeping access
Connectivity is the other big theme. Many customers run Salesforce traffic through corporate firewalls and proxies that only permit a fixed allow-list of destinations. When an org moves to Hyperforce, the set of domains and addresses it needs to reach changes, so the allow-list has to change with it. Salesforce frames this as allowing all of the Salesforce required domains, and it publishes guidance on retaining uninterrupted access to Salesforce services on Hyperforce. If you miss this step, users and integrations can suddenly fail to connect after the cutover, even though nothing inside Salesforce is broken. This is why the Assistant pairs the connectivity check with the hard-coded reference check. One protects inbound and outbound code paths, the other protects the network path. The work usually spans teams. An admin can spot the issue in the Assistant, but the actual firewall change often sits with a network or security group, so finding the right approver early is part of the job. Build in lead time for change-management approvals, because they rarely move at the pace of a wizard.
Sandbox first, then production
Because the Assistant runs in both sandbox and production, you can and should rehearse. A sandbox is a copy of your org's configuration, so validating the migration there gives you a low-risk preview of the production cutover. You work the Prepare checklist in the sandbox, confirm integrations still connect, and run a regression pass before you do the same in production. A clean sandbox migration is the best signal you will get that the production move will go cleanly. Anything that surfaces in the sandbox is something you get to fix on your own schedule instead of during the live window. Plan the regression testing to cover every integration, not just the Salesforce-side features. Salesforce-managed tests catch internal regressions, but the firewall and hard-coded URL problems tend to show up only when a real external system tries to call in or out. The combination of the Assistant checks plus your own end-to-end tests is what closes the gap between looks ready and actually ready.
The migration window and what changes after
The migration itself happens during a maintenance window, and the FAQ describes roughly three hours of downtime for the move. During that window the org is unavailable while data and configuration are transferred to the Hyperforce instance. After the cutover, the practical change most teams notice is the new instance identity. Your stable My Domain URL keeps working, which is the whole point of cleaning up hard-coded references beforehand. Any code or integration that still pointed at the old instanced host is what tends to break, so the value of the prep work shows up here. Once you are on Hyperforce, you gain the regional data residency and the compliance posture that come with the platform, though specific certifications vary by region, so check the Salesforce Trust and certifications resources for your region. The Assistant does not run the migration for you, Salesforce schedules and performs that. Its job is to get you to the date with every readiness task closed, so the maintenance window is uneventful and your users come back to a working org.
Running the Hyperforce Assistant
The Hyperforce Assistant is not something you build, it is a Setup tool you run to prepare your org. Here is how to work through it.
- Open the Assistant in Setup
From Setup, type Hyperforce Assistant into the Quick Find box and select Hyperforce Assistant. Do this in a sandbox first if one is available, so you can rehearse before production.
- Work the Learn phase
Read the Learn phase with the team that owns the change. It explains what Hyperforce is and what shifts for your org, which sets context before anyone starts editing configuration or code.
- Run the Prepare checks
Move to the Prepare phase and let it run the org-contextual checks. Review the hard-coded reference and connectivity findings, each of which links to the matching help article with the fix.
- Remediate and rerun
Fix the flagged items, replacing instance URLs with My Domain URLs and updating firewall allow-lists, then rerun the checks. Repeat until the task list is clean before the scheduled migration date.
The guided overview of Hyperforce and what changes for your org. Start here so the people doing the work understand the why.
Scans for instance-specific URLs like na1.salesforce.com that should become My Domain URLs before the move.
Confirms the org can reach the target Hyperforce instance, catching firewall and allow-list gaps early.
Running the Assistant in a sandbox first to rehearse the preparation and predict a clean production cutover.
- The Assistant prepares your org but does not perform the migration. Salesforce schedules and runs the actual cutover.
- Hard-coded URL cleanup is usually the longest task. Start it weeks ahead, since references hide in integrations, Visualforce, WSDLs, email templates, and Chat.
- Firewall allow-list changes often sit with a network or security team, so identify the approver early to avoid a last-minute scramble.
- After July 1, 2026, per the Salesforce FAQ, it is no longer possible to delay upgrades to Hyperforce, so do not treat the date as flexible.
Prefer this walkthrough as its own page? How to Hyperforce Assistant in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Hyperforce Assistant.
- Hyperforce Upgrade PreparationSalesforce
- Updating Hard-Coded ReferencesSalesforce
Hands-on resources to go deeper on Hyperforce Assistant.
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. What does the Hyperforce Assistant in Setup do for an admin?
Q2. Which finding is the most common readiness blocker the Hyperforce Assistant surfaces?
Q3. How does Salesforce typically sequence the Hyperforce migration that the Assistant tracks?
Discussion
Loading discussion…