--- title: "Hyperforce and data residency" url: "https://trailassembly.com/salesforce-hyperforce-data-residency/" topic: "Architecture" published: "2026-09-16T11:14:09+00:00" updated: "2026-10-06T13:56:40+00:00" --- # Hyperforce and data residency **In one sentence:** Hyperforce is Salesforce running on public cloud infrastructure instead of their own data centres, and the part that matters to you is that it lets your org live in a specific country. Most of the migration is invisible. The parts that are not invisible are IP ranges, URLs, and anything you hardcoded. ## What actually changes for an existing org For most orgs, very little. The platform behaves the same, the API is the same, your metadata is untouched. Salesforce schedules the migration, it happens over a weekend, and the majority of customers notice nothing. The exceptions are specific and worth checking before the date rather than after: - **IP ranges change.** Anything allow-listing Salesforce outbound IPs on a firewall needs the new ranges. This is the single most common cause of an integration breaking on migration weekend. - **Instance-based URLs stop working.** Anything referencing `na42.salesforce.com` rather than your My Domain URL. Salesforce has been pushing My Domain for years partly for this reason. - **Some IP-restricted integrations** that authenticate from a fixed address need re-checking at both ends. - **Performance characteristics shift slightly.** Usually favourably. Worth re-baselining anything you monitor closely. ## The residency question Data residency means your data at rest lives in a particular country or region. Hyperforce makes this available in more places than the old data centre model could, which is why it exists as a customer-facing concept at all rather than as an infrastructure detail. Two distinctions people conflate: **Residency is not sovereignty.** Data being stored in a country does not mean that country’s law is the only law that applies. The legal analysis depends on where the provider is incorporated and what treaties apply, and it is a question for your legal team, not your architect. **Residency is not processing location.** Data at rest in one region can still be processed elsewhere in specific circumstances, including some AI features. If the requirement is that nothing leaves a jurisdiction under any condition, that needs confirming feature by feature, and the answer is not uniformly yes. ## The AI question specifically This is where residency assumptions break most often. Generative AI features route prompts to a model, and where that model runs is a separate question from where your org lives. Salesforce documents the regions available for these features and they do not always match the full list of org regions. If you have a hard residency requirement and you are turning on AI features, verify the processing region for those features specifically. Do not infer it from the org’s region, and get the answer in writing if it matters for compliance. ## Preparing for a migration Salesforce gives notice. The useful work in that window: 1. **Find every hardcoded URL.** Search your metadata for `.salesforce.com` and `.force.com` outside My Domain references. Check Apex, flows, email templates, custom settings, and anything your integrations hold. 2. **Send the IP ranges to whoever owns the firewall.** Early, because that team has a change process. 3. **Inventory the integrations** and identify who to call for each when something fails. You want this list before the weekend, not during it. 4. **Test in a sandbox** if yours migrates first, which is common. That is a genuine rehearsal and it is free. ## What it does not solve Hyperforce is infrastructure. It does not change your [governor limits](https://trailassembly.com/governor-limits-reference/), your storage allowance, your API limits, or the multi-tenant model. An org that is slow because of a [non-selective](https://trailassembly.com/selective-queries-at-scale/) query is slow for the same reason afterwards. It also does not, by itself, satisfy a compliance requirement. It makes one achievable. The evidence your auditor wants is a documented configuration plus the provider’s own attestations, and the migration is one input to that rather than the answer. ## Frequently asked **Can I choose when to migrate?** Generally no for existing orgs. Salesforce schedules it. New orgs are provisioned on Hyperforce in supported regions. **Can I pick my region?** For a new org in a supported region, yes, and it is set at provisioning. Moving an existing org between regions is a separate and much larger conversation. **Does my sandbox move at the same time?** Not necessarily, and sandboxes often go first. That mismatch is useful for testing and confusing if you did not expect it. --- Source: https://trailassembly.com/salesforce-hyperforce-data-residency/ Trail Assembly — independent Salesforce write-ups.