Hyperforce
Hyperforce is Salesforce's reimagined infrastructure platform that runs the Salesforce stack on public cloud infrastructure providers including AWS, Azure, and Google Cloud.
Definition
Hyperforce is Salesforce's reimagined infrastructure platform that runs the Salesforce stack on public cloud infrastructure providers including AWS, Azure, and Google Cloud. It is the successor to the legacy first-party data centers Salesforce operated for two decades, designed to give customers the same Salesforce functionality with the added benefits of geographic data residency, faster regional expansion, and modern infrastructure operations.
The migration from legacy Salesforce data centers to Hyperforce has been ongoing since 2021 and is a multi-year effort that touches every Salesforce product. Each org gets migrated to a Hyperforce-hosted instance in a specific cloud region, chosen based on the org's data residency requirements (US, EU, India, Australia, and more being added). The customer-facing experience is unchanged: the same Lightning Experience, the same APIs, the same login URL. The change is under the hood, where Salesforce operates on cloud-native primitives (Kubernetes, microservices, object storage) instead of bespoke data center hardware.
The architectural shift Hyperforce represents
Why Salesforce moved to public cloud
Three factors drove the Hyperforce initiative. First, customer demand for data residency: large customers in regulated industries (financial services, healthcare, government) need their data to remain in specific geographies for compliance reasons, and operating bespoke data centers in every country is not feasible. Second, regional expansion velocity: standing up a new Salesforce region traditionally took years; on public cloud, it takes months. Third, modernization: cloud-native infrastructure provides better resilience, security, and operational agility than the legacy stack Salesforce built in the early 2000s. The result is a platform that can grow with customer needs and serve regulated industries that previously could not adopt Salesforce.
Data residency and regional choices
When an org is provisioned on Hyperforce, the customer or sales team selects a region during the order process. The region determines where the customer's primary data is stored: United States, European Union, India, Australia, Canada, Japan, and others. Once selected, the data does not leave that region except for specific cross-region replication for disaster recovery, which is configurable and visible to the customer. Some advanced features (Einstein AI processing, global SSO) may involve cross-region calls; Salesforce publishes detailed documentation about which features process data outside the chosen region and under what conditions. This transparency is core to the Hyperforce trust story.
Trust and security on Hyperforce
Hyperforce inherits Salesforce's core trust commitments: SOC 1/2, ISO 27001, HIPAA, PCI DSS, GDPR compliance, and more. The underlying public cloud provider's certifications stack on top of Salesforce's controls, giving customers double-layer assurance. Data encryption at rest and in transit is mandatory, with customer-managed encryption keys available via Shield Platform Encryption. The change-management discipline that runs Hyperforce is more rigorous than the legacy data centers because cloud infrastructure has more moving parts. Salesforce's status site publishes Hyperforce-specific availability metrics so customers can monitor their region's reliability separately from the legacy regions.
Migration timeline and customer impact
Salesforce has been migrating customers from legacy data centers to Hyperforce since 2021 in waves, organized by region. Each migration is scheduled, announced months in advance, and executed during a maintenance window with minimal downtime. The customer receives migration notifications with the target window and any preparation steps (typically minimal: updating allowlist entries for any hardcoded IP addresses, adjusting some integration endpoints). After migration, the org continues to function with the same URLs, the same API endpoints, and the same user experience. The login.salesforce.com URL automatically routes the user to the correct Hyperforce region, transparently. Customers who use My Domain (which is most enterprise orgs) see no URL change at all.
Features that depend on Hyperforce
Several Salesforce products only run on Hyperforce: Data Cloud, certain Industry Clouds, Agentforce, and many of the newer AI-powered features. Customers on legacy data centers can still adopt these products, but the data flows out to a Hyperforce-hosted instance of the specific product. For organizations with strict data residency requirements, this can be a constraint: a customer in a non-Hyperforce region who wants Data Cloud may need to accept data movement to a Hyperforce region, or wait for Hyperforce expansion to their preferred geography. The Salesforce account team is the right partner for these conversations, with detailed product-by-product documentation about which features are Hyperforce-only.
Cloud provider choice and multi-cloud
Salesforce operates Hyperforce on AWS, Azure, and GCP, with the specific provider determined by the region. Most current Hyperforce regions run on AWS, with growing Azure and GCP footprints. Customers do not typically choose the underlying provider; Salesforce chooses based on regional availability, cost, and regulatory requirements. From the customer's perspective, the provider is largely invisible: the same Salesforce APIs, the same management console, the same trust commitments. The customer is on Salesforce's services, not the cloud provider's services directly. Some advanced integrations (BYOK for encryption, certain compliance configurations) may surface the underlying provider, but the day-to-day experience is provider-agnostic.
Operational changes for admins and developers
For most admins and developers, Hyperforce is invisible. The Setup pages, APIs, and developer tools work the same way. The differences appear in a few specific places. Hardcoded IP allowlists may need updating to the Hyperforce IP ranges, which Salesforce publishes for each region. Custom Apex callouts to internal systems may need new outbound IP allowlist entries on the internal firewall side. Backup and export tools that interact with the underlying database may need authentication changes. The Salesforce trust site and the Hyperforce documentation publish IP ranges, configuration changes, and any timing-sensitive guidance for each migration wave.
The future direction Hyperforce enables
Beyond the migration story, Hyperforce is the platform that enables the next generation of Salesforce capabilities. The microservices-and-Kubernetes foundation allows Salesforce to ship new features faster than the legacy monolith could support, with the result that releases are smaller and more frequent. Customer-managed encryption keys via cloud provider key management services give regulated industries more control than was possible before. Cross-region replication for disaster recovery is built into the platform rather than being a custom engagement. Customers operating in regulated industries gain access to features (BYOK, real-time encryption rotation, fine-grained audit) that match what they expect from their other cloud services. The promise of Hyperforce is not just that Salesforce moved to public cloud; it is that the move opens up an architectural ceiling the legacy platform had reached. Whether each specific capability matters to a given customer depends on their regulatory and operational context, but the architectural shift is the enabler underneath every newer Salesforce feature.
Prepare for and validate a Hyperforce migration
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.
Trust & references
Straight from the source - Salesforce's reference material on Hyperforce.
- HyperforceSalesforce Help
- Hyperforce MigrationSalesforce Help
Hands-on resources to go deeper on Hyperforce.
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?
Q2. What architecture concept is Hyperforce an example of?
Q3. What does Hyperforce represent in the Salesforce Platform?
Discussion
Loading discussion…