Salesforce Hyperforce: what the migration actually changes, and the integrations it quietly breaks

For most of Salesforce’s history, “where does my org live” had a boring answer: a Salesforce-owned data center, on an instance with a name like NA104 or EU45, and you never thought about it again. Hyperforce changed the answer, and as of July 1 2026 it stopped being optional — Salesforce’s own guidance is that it is no longer possible to delay the upgrade. Your org is getting moved onto public-cloud infrastructure on a date Salesforce picks, inside your maintenance window, and the only variable left under your control is whether you prepared for it.

The upside is real: better performance headroom, faster regional expansion, and genuine data-residency choice. But the migration is not a no-op you can sleep through. The things that break are the small, decade-old shortcuts nobody remembers making — a hardcoded na104.salesforce.com in a callout, an IP allowlist on a partner’s firewall, a certificate someone pinned in 2019. This is what Hyperforce actually is, what the migration does to your org, and the readiness pass that keeps cutover uneventful.

What Hyperforce actually is

Hyperforce is Salesforce’s re-architecture of the entire platform to run on public-cloud infrastructure — AWS, and increasingly Microsoft Azure and Google Cloud — instead of the first-party physical data centers the platform ran on for two decades. That sounds like a plumbing detail, and from your users’ seat it mostly is: the same org, the same metadata, the same URLs-if-you-did-it-right. What changes is everything underneath.

The design principles are worth knowing because they explain the migration behavior:

• Infrastructure as code. The environment is defined in code and stood up programmatically, which is how Salesforce can open a new country region in months instead of the years a physical data center took.
• Immutable infrastructure. Servers are never patched in place — a new version is deployed and the old resource is replaced wholesale. Nothing long-lived accumulates drift.
• Multi-availability-zone by default. The platform spans multiple isolated zones within a region for resilience.
• Zero trust. Every connection is authenticated and encrypted; the network perimeter isn’t treated as a trust boundary.

The practical consequence of immutable, code-defined infrastructure is the one that bites: the machines your org runs on are ephemeral. They come and go, and so do their IP addresses. Anything you built that assumed a fixed server or a fixed address is now on borrowed time. Hold that thought — it’s the source of most migration pain.

One thing Hyperforce is not: a line item. There is no additional charge for it. The migration, and the regions it unlocks, come at no extra infrastructure cost. Shield and Bring Your Own Key remain separate paid add-ons, but Hyperforce itself is just the ground the platform now stands on.

Data residency: the reason most buyers care

The headline benefit for regulated and international customers is data residency — the ability to keep your Salesforce data physically stored in a specific country. Because Hyperforce regions are just public-cloud regions, Salesforce can offer a lot of them, and the list keeps growing; by mid-2026 it spans roughly eighteen countries, with Cape Town, South Africa reaching general availability in July 2026 and regions live across Australia, Canada, France, Germany, India, Japan, Singapore, South Korea, Sweden, the UK, the US, and more.

For Europe specifically, Salesforce layers on stronger commitments than raw region choice. The Hyperforce EU Operating Zone keeps data within Europe with EU-based availability zones and support staffed by EU-based personnel, and there are dedicated arrangements like a Swiss Operating Zone and a UAE local-residency offering for jurisdictions with hard sovereignty rules.

Here’s the honest caveat, because it’s where these conversations go sideways: residency is not sovereignty. Storing EU data in Frankfurt genuinely reduces cross-border-transfer exposure under GDPR, and it’s a real answer to “where does our data sit.” It does not, by itself, place the data beyond the reach of a US parent company’s legal obligations — analysts have been pointed about the gap between a Frankfurt region and true legal sovereignty. If your requirement is “the data never leaves the country,” residency choice plus Shield encryption with customer-held keys is the architecture to reach for, and the contract language matters as much as the region toggle. This is the same governed-data-lifecycle thinking behind honoring a right-to-be-forgotten request in Data 360: where data lives and who can reach it are design decisions, not defaults.

The migration: what actually happens to your org

Salesforce schedules the migration; you don’t request it. The mechanics, per Salesforce’s guidance:

• You get notice. Expect a notification roughly 30 days out and a reminder around 15 days before the migration, delivered through Product & Service notifications, naming your Org ID, the migration date, and the new target instance.
• It runs in your Preferred Maintenance Window. Set that window deliberately if you haven’t — it’s when the cutover happens.
• There’s a brief read-only period, then a cutover. Your org goes read-only for a short window during the move and typically completes within hours, not days. Users see a maintenance state, not a multi-day outage.
• The instance name changes. This is the crux. Your underlying instance identifier changes, which is precisely why any reference to the old instance name is a landmine.
• Only production migrates on that date. Sandboxes don’t ride along automatically — after production is on Hyperforce, you refresh or recreate your sandboxes into Hyperforce, and the old sandbox in the legacy data center is retired. Teams that assumed “everything moves together” get surprised here.

Salesforce ships a Hyperforce Assistant to help — it lives in Setup (Quick Find → “Hyperforce Assistant”) and walks an admin through the readiness checks. Use it, but don’t treat it as the whole plan; it flags what it can detect, and the riskiest references live in systems Salesforce can’t see.

The migration doesn’t change your data or your metadata. It changes your org’s address. Every failure on cutover day traces back to something that hardcoded the old address instead of resolving it.

What breaks — and the four things to fix before cutover

This is the section that decides your migration. Four categories cause nearly all the incidents.

1. Hardcoded instance URLs. Somewhere in your estate is a URL like https://na104.salesforce.com/services/... — in a callout, a middleware connection, a partner integration, a bookmarked report, an old SSO config. When the instance name changes, every one of those fails. The durable fix is to route everything through your My Domain URL in the form mycompany.my.salesforce.com, which stays stable across the migration and every future one. Hyperforce doesn’t permit hardcoded instance references, so this isn’t optional hygiene — it’s the single highest-value prep task. Hunt these down across integrations, named credentials, callouts, and any external system that calls into Salesforce, and treat it with the same rigor you’d give any production integration pattern.

2. IP allowlists. If a partner firewall, a legacy integration, or your own network security allowlists Salesforce by IP address, that approach is now fighting the architecture. Hyperforce IPs are ephemeral and change frequently — sometimes outside Salesforce’s control — so a static allowlist will silently drop connections when the addresses rotate. Salesforce actively discourages IP allowlisting and recommends mTLS (mutual TLS) as the modern alternative for authenticating traffic. If you have an insurmountable compliance reason to keep allowlisting, Salesforce publishes the current ranges as machine-readable JSON at ip-ranges.salesforce.com/ip-ranges.json and you must consume it programmatically and keep it synced — never transcribe a range by hand, and never assume it’s stable. Note too that this list is for the core platform: Marketing Cloud, Commerce Cloud, Slack, MuleSoft, and Tableau have their own networking and migrate on their own schedules, so a core-platform allowlist won’t cover them.

3. Pinned certificates. Hyperforce rotates its TLS certificates regularly. Any integration that pins a specific certificate — a brittle practice even before Hyperforce — will break the next time a certificate rotates. Switch to validating against the certificate authority chain, not a specific leaf certificate.

4. Email deliverability. Post-migration, outbound email can start getting filtered or blocked if your SPF and DKIM records don’t authorize the sending infrastructure and you haven’t opted into Salesforce’s email guidance. Review your SPF/DKIM alignment before cutover; a deliverability regression is easy to miss until a week of case notifications quietly land in spam.

Concretely, the fix pattern for the two that cause the most incidents looks like this:

# Brittle: hardcodes the instance — breaks the moment Hyperforce renames it
https://na104.salesforce.com/services/data/v61.0/query?q=SELECT+Id+FROM+Account

# Durable: resolves through My Domain, stable across this migration and every future one
https://mycompany.my.salesforce.com/services/data/v61.0/query?q=SELECT+Id+FROM+Account

# If you have an unavoidable need to allowlist, consume the official ranges as data —
# never transcribe an IP by hand, and re-sync on a schedule because they rotate
curl -s https://ip-ranges.salesforce.com/ip-ranges.json | jq '.'

The way to de-risk all four is the same: test in a sandbox that’s already on Hyperforce. Because sandboxes migrate separately, you can get one onto Hyperforce ahead of production, then run your integrations, SSO flows, callouts, and email against it to surface breakage while it’s cheap. If you don’t already have a deliberate sandbox strategy, the migration is the forcing function to build one.

Security and compliance on Hyperforce

For the security review that inevitably follows “we’re moving to public cloud,” the baseline is strong. Hyperforce encrypts data at rest with AES-256 and in transit with TLS 1.2 or higher, with network-layer DDoS mitigation and intrusion detection. It carries the audit posture enterprises expect — SOC 1/2/3, the ISO 27001/27017/27018 family, and readiness for regimes like PCI DSS, HIPAA, and FedRAMP — though you should always confirm the exact certification scope for your region and clouds against Salesforce’s current compliance documentation rather than assume blanket coverage.

That platform-level encryption is automatic and distinct from Shield Platform Encryption, which remains a paid add-on for field- and file-level encryption with customer-managed keys. If your driver is sovereignty rather than baseline protection, the combination that matters is a residency-appropriate region plus Shield with Bring Your Own Key, so that even Salesforce-side access is bounded by keys you control and rotate. Fold this into the same quarterly discipline as the rest of your security review — Hyperforce raises the infrastructure floor, but who-can-see-what inside your org is still your job, exactly as the Trust Layer draws the line for AI features.

What to actually do

If your org hasn’t migrated yet, the plan is not complicated, just unforgiving about sequence:

1. Set your Preferred Maintenance Window deliberately, so the cutover lands when you can watch it.
2. Open the Hyperforce Assistant in Setup and work its checklist, but treat it as a floor.
3. Eliminate hardcoded instance URLs everywhere, replacing them with My Domain URLs — this is the big one.
4. Move off IP allowlisting toward mTLS or domain-based trust; if you truly can’t, automate consumption of the official IP-ranges JSON.
5. Un-pin certificates and fix SPF/DKIM for email.
6. Get a Hyperforce sandbox and test every integration, SSO flow, and callout against it before production day.
7. Plan to refresh sandboxes into Hyperforce after production migrates.

Do that, and migration day is a non-event — a short read-only blip and a new instance name nobody outside the ops channel notices. Skip it, and you’ll spend cutover afternoon grepping middleware for an instance name that no longer exists while integrations fail one by one. The platform did the hard part by re-architecting itself onto the public cloud for free; the only work left is making sure nothing you built quietly assumed the old world would never move.

Understanding the basics

Is the Hyperforce migration mandatory, and can I still delay it?

Yes, it’s mandatory, and no, you can’t delay it anymore. Salesforce’s guidance is that as of July 1 2026 it is no longer possible to postpone the upgrade to Hyperforce. Salesforce schedules the migration into your org’s Preferred Maintenance Window and notifies you ahead of time — typically about 30 days out with a reminder around 15 days prior, naming your Org ID, the date, and the new target instance. Your remaining control is preparation, not timing: set your maintenance window deliberately and complete the readiness checks before the scheduled date.

What actually breaks when my org moves to Hyperforce?

Four things cause almost all migration incidents. Hardcoded instance URLs (like na104.salesforce.com) break because your instance name changes — fix them by using your My Domain URL (mycompany.my.salesforce.com). IP allowlists break because Hyperforce IPs are ephemeral and rotate — Salesforce recommends mTLS instead, or consuming the official ip-ranges.salesforce.com/ip-ranges.json list programmatically. Pinned certificates break because Hyperforce rotates TLS certificates regularly — validate against the CA chain, not a specific certificate. And email can start getting filtered if SPF/DKIM aren’t aligned. Test all of it in a Hyperforce sandbox before production migrates.

Does Hyperforce cost extra, and does it make my data sovereign?

Hyperforce itself costs nothing extra — it’s the underlying infrastructure, and the migration and regional options come at no additional infrastructure charge. On sovereignty, be precise: Hyperforce gives you genuine data residency (choosing the country where your data is stored, across roughly eighteen countries as of mid-2026), and for Europe there are stronger commitments like the EU Operating Zone. But residency isn’t the same as legal sovereignty — keeping data in-region reduces transfer risk without placing it beyond a US parent’s legal reach. For hard sovereignty requirements, pair a residency-appropriate region with Shield Platform Encryption and Bring Your Own Key, and get the specifics into the contract.

---

Facing a Hyperforce migration and not sure what in your integration estate is about to break? Talk to us — finding the hardcoded URLs, moving off IP allowlists, and testing the cutover in a Hyperforce sandbox before it’s your production org is exactly the work we do.