Salesforce Hyperforce is the infrastructure Salesforce now runs on: the platform rebuilt for the public cloud, so you can choose the country where your org's data is stored and processed.
Hyperforce settles where data lives. It doesn't control how changes reach each regional org, so that part is still yours to govern.
Below, we cover what actually changes with Salesforce Hyperforce, how data residency and compliance work, what tends to break in a migration and how to govern more than one region.
What is Salesforce Hyperforce?
Hyperforce is Salesforce's infrastructure architecture for the public cloud.
Before it, traditional Salesforce infrastructure ran in Salesforce-controlled data centers. Those were physical data centers where Salesforce ran the servers, storage and networking itself.
Salesforce's engineering teams have explained why. For years, the only practical way to deliver Salesforce's brand of software as a service was to run everything itself.
Hyperforce moves the Salesforce platform onto public cloud infrastructure from public cloud providers. The underlying infrastructure is now written as code instead of racked as hardware.
Salesforce says this cuts launch timelines for new regions, gives customers more say over residency and makes continuous updates easier. Moving your org onto it comes at no additional cost, according to Salesforce's public cloud infrastructure page.
Think of Hyperforce as the floor your Salesforce org stands on, not a feature you switch on in Setup. Your users see the same Salesforce applications after the move.
What changes is the cloud infrastructure underneath.
Which cloud does Hyperforce run on?
Hyperforce runs on Amazon Web Services (AWS) and, from late 2026, on Google Cloud Platform (GCP). You don't choose the provider; Salesforce places your org and you choose the country or region.
In its 2023 deal with AWS, Salesforce said it would expand its use of AWS "through Hyperforce".
What are Hyperforce's five architectural principles?
Salesforce's engineering team has written up the five principles behind Hyperforce. Each one shows how the Hyperforce architecture, a cloud native architecture built for the public cloud, changes the way your org behaves once it moves.
What are the key benefits of Hyperforce?
Salesforce sells the Hyperforce architecture on four benefits that apply to all Salesforce customers on it. Each one is covered below, with where the claim comes from.
Local data storage
You choose a region, and Salesforce stores your data there. Its localized data residency options let you pick where data is stored and processed.
If you work in a highly regulated industry, that control over data residency is the place to start your review.
Enhanced security by default
The Hyperforce architecture is built on zero trust. There's no implicit access to resources, and all data is encrypted at rest and over the wire.
Salesforce's own operators get just-in-time access to production. That access is removed automatically after a set period.
Salesforce also says Hyperforce integrates with cloud security posture management tools and uses identity and access management and role-based permissions. Your own access controls and sensitive data policies still sit on top.
Scale and business continuity
Hyperforce infrastructure runs across multiple availability zones, at least three in each region. A single hardware fault or power cut shouldn't take your org down.
It's a cloud native design on elastic cloud infrastructure. Salesforce says it can scale resources up or down, so infrastructure resources scale dynamically based on demand.
For disaster recovery, Salesforce lists continuous replication of your Salesforce instance in a separate geographic location. Factor that into your business continuity plan before you decide what to cover yourself.
Faster, safer deployment cycles
Salesforce manages its infrastructure as code, in metadata kept under source control. Infrastructure changes follow the same lifecycle as any other software change, which Salesforce says lowers the risk of human error.
Agentforce and Customer 360 run on containerized services in the public cloud.
Salesforce says that lets it deliver apps rapidly and reliably to locations worldwide, as its public cloud infrastructure page puts it, without the hardware build-out physical data centers needed.
How does Hyperforce handle data residency?
Hyperforce supports in-country storage: customer data is stored in the country where your org is located. Options include the U.S., U.K., Germany, India and Japan, and the region list is still growing.
There's a catch, and Salesforce says so itself: data residency depends on the services you use. Some products have parts that run in other countries, or connect to services that aren't on Hyperforce yet.
So check each product against your region. Picture a German insurer running its org in the Germany region.
Its core CRM data stays at rest in Germany. But if the team turns on a service that isn't available there yet, that service could process data somewhere else, and compliance has to catch it product by product.
An org's Salesforce data sits in one country, so a Salesforce organization with data in multiple regions plans residency org by org. For country detail, see our posts on Salesforce data residency and UK data residency.
What is the Hyperforce EU Operating Zone?
The EU Operating Zone is a paid Hyperforce offering for EU customers. Customer data is stored and processed inside the EU boundary.
Customer and engineering support comes from EU-based staff, around the clock.
At launch, the zone covered a first set of Sales, Service, Experience, Platform and Industries products, with more planned. Salesforce also documents how it keeps EU data storage and processing in the region.
Our post on EU data residency and GDPR in Salesforce covers how that fits with GDPR.
Is data residency the same as data sovereignty?
No. They sound alike, but they answer different questions, and a risk assessment needs both.
For the legal side, the U.S. Department of Justice explains the CLOUD Act and how it reaches data held by U.S. providers.
So an EU region tells you where your data sits. It doesn't necessarily tell you who can ask for it.
Which compliance certifications apply on Hyperforce?
Certifications belong to Salesforce services, not to the region you pick. Map your compliance requirements service by service, using the table below as a guide.
The SOC, ISO and HITRUST details come from Salesforce's Security, Privacy and Architecture documentation. It lists exclusions product by product, so read the ones for the services you actually run.
On the government side, Government Cloud Plus holds a FedRAMP provisional authorization at the high impact level. Salesforce now labels that FedRAMP Class D, and Salesforce Government Cloud is built on AWS GovCloud (US).
In healthcare, your own HIPAA backup obligations still apply on top of this. Federal teams can start with our Salesforce FedRAMP compliance guide.
What changes when you migrate to Hyperforce?
Salesforce says migrations are usually completed with little to no downtime. During the maintenance window, the org can be in read-only mode, so don't plan deployments for that day.
The real work in the Hyperforce migration process is elsewhere. It's in the infrastructure dependencies you've built up: everything your external systems, third-party integrations and security controls assume about where your org lives.
Hard-coded URLs and changing IP addresses
On Hyperforce, Salesforce says you can't rely on hard-coded instance references or IP allowlists.
Look for them in custom code, integrations and API clients before the move. If you only find them afterward, something may already have broken.
IP addresses change too. Salesforce recommends allowlisting domains instead of IP addresses, and publishes its IP ranges by Hyperforce region for cases that still need them.
Sandboxes and change sets
Ask your Salesforce account team when each of your sandboxes will move. Then check how your release process copes while some orgs have moved and others haven't.
If you still deploy with change sets, this is where it hurts most, because every change set is a manual step between two orgs.
A migration is a good excuse to move off them. Salesforce's own option is Lifecycle Center (formerly next-generation DevOps Center), or you can use a dedicated release tool with version control, automated testing and rollback.
Each region you add makes the problem bigger. Two regional orgs mean two chances to miss a step, and five mean five.
What governance do you need across Hyperforce regions?
Hyperforce takes care of where data lives. Keeping each regional org in step is a DevOps compliance job, and it comes down to four things.
Automated deployment pipelines
Automated pipelines need to know each region's URLs, IP ranges and environment variables. Otherwise, every regional deployment is a chance for drift or a broken integration.
Salesforce's guide to pipeline stages runs from development through integration, user acceptance testing and staging to production. Yours can differ, as long as it runs the same way in every region.
Version control and rollback
When a release goes to several regional orgs, you need one record of what changed, where and when.
Rollback has to work in each org on its own. That way one failed deployment doesn't become a long outage.
Audit trails
Auditors will want every change in every org tied to a person, a timestamp and an environment. Salesforce's Field Audit Trail covers field history, and your release tool has to cover the deployments.
Policy checks before production
Checking a deployment against your policies before production is much cheaper than explaining a gap after an audit. It's where a data governance program meets the release process.
Hyperforce migration checklist
Use this before, during and after the move. It won't cover every org, but it hits the usual surprises.
Before migration:
- Search code and integrations for hard-coded instance references, My Domain references and API endpoints.
- List the inbound and outbound integrations, middleware and partner connections in your Salesforce environment that assume a fixed instance or IP.
- Replace IP allowlists with domain allowlists where you can.
- Check that every Salesforce product you use is available in your target Hyperforce region.
During migration:
- Expect a read-only maintenance window, confirm the date with your Salesforce account team and give business operations notice.
- Freeze deployments until the move is finished.
After migration:
- Repoint URLs and integration endpoints, and update firewall rules.
- If you're still on change sets, move to a source-driven CI/CD pipeline.
- Check that audit trails, access controls and data residency settings work in every regional org and Salesforce environment. Then test key integrations end to end before normal releases restart.
How Flosum fits a multi-region setup
Flosum runs three ways: Salesforce-native as a managed package in your org, Flosum-hosted cloud, or customer-hosted in your own cloud account.
With the native option, version control and deployment data stay inside your Salesforce org, wherever that org is hosted.
Our comparison of Salesforce DevOps deployment models puts them side by side, so you can see which model fits your residency needs.
You can also see how native Salesforce DevOps compares with other Salesforce DevOps tools for release control across regions.
FAQs
Book a demo to see how Flosum keeps Salesforce releases consistent across your Hyperforce regions.
Thank you for subscribing
