As Salesforce has grown, so has the pressure on its infrastructure to keep up with more data, more users, and more complexity. That’s why Salesforce has begun rolling out Hyperforce — a major architectural shift to how Salesforce runs behind the scenes.
Instead of relying on Salesforce’s own first-party data centers, Hyperforce moves the platform onto public cloud infrastructure like Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. Migrating to public cloud providers unlocks new possibilities for data residency, scalability, and performance — all while keeping the familiar Salesforce experience intact.
But for DevOps teams, infrastructure changes are never just a technical detail. Whether you’re managing releases, handling metadata, or building pipelines, it’s worth understanding what Salesforce Hyperforce migration means in practice.
How Hyperforce works: Infrastructure
By moving to public cloud platforms like AWS, Hyperforce delivers not just better performance, but also greater flexibility and more control over where and how customer data is stored.
Salesforce Hyperforce infrastructure is built to utilize availability zones and regions. A region is a specific geographic area — Frankfurt or Tokyo — where a cloud provider has physical data centers. Each region contains multiple availability zones — isolated locations designed to keep services running even if one zone goes down.
When a Salesforce organization is deployed on Hyperforce, it’s hosted in a specific region based on the customer’s data residency needs. Within that region, Salesforce uses multiple availability zones to ensure high availability and fault tolerance — enabling horizontal scaling across distributed infrastructure, rather than relying on vertical scaling of individual servers.
The benefits of Hyperforce
Hyperforce gives teams a faster and more flexible way to run Salesforce — with benefits that improve how you build, scale, and secure your environments.
Increased scalability and performance
Hyperforce’s infrastructure takes advantage of the scalability and redundancy of cloud-native architecture. Resources can scale dynamically based on demand — whether that’s more processing power during peak business hours or faster throughput for large metadata deployments. For DevOps teams, that translates to quicker build times, faster test execution, and smoother CI/CD performance across orgs.
Enhanced security controls
By running on modern cloud infrastructure, Hyperforce strengthens Salesforce’s data security posture with the application of Zero Trust architecture. That means no implicit trust — every user, device, and connection must be continuously verified. Hyperforce also supports data encryption both at rest and in transit and organization-specific encryption keys. These Zero Trust principles build on Salesforce’s existing security model while aligning with the rigorous standards of cloud-native platforms — ensuring that access is always intentional, auditable, and secure.
Data residency and compliance
With Hyperforce, businesses can choose the geographic region where customer data is physically stored and processed. This is especially valuable for global-scale businesses in regulated industries, where control over data residency is essential for meeting compliance requirements like GDPR, HIPAA, or CCPA — and for maintaining the auditability and access controls required by standards like SOX. Or for businesses who need to comply with local regulations like Singapore’s Personal Data Protection Act (PDPA), where sensitive data like Personally Identifiable Information (PII) has to be kept within Singapore. Beyond simply meeting compliance checkboxes, Hyperforce data residency helps businesses expand business operations into new markets with confidence, knowing their data architecture can adapt for local data storage and regulations from day one.
Faster time to market
The Hyperforce platform’s flexible and scalable infrastructure helps accelerate release cycles. All Hyperforce sandboxes benefit from Quick Clone, a feature that lets teams create new sandbox orgs by cloning an existing one — with all its metadata and setup — in just a few minutes. Instead of waiting for a full refresh from a production org, developers get a consistent, ready-to-use environment almost instantly. That means less downtime between workstreams and faster testing, helping teams move through development and deployment cycles more quickly. Hyperforce automatically scales cloud resources to handle demand spikes — so even during high-traffic events like Black Friday, performance remains reliable. And by eliminating the need for on-premise hardware and physical resources, teams avoid lengthy procurement and maintenance cycles, moving faster with a streamlined, pay-as-you-go model.
Improved disaster recovery and higher availability
Hyperforce is built for resilience, using multiple availability zones within the same region to deliver high reliability. If one zone experiences an outage, traffic is automatically rerouted to another zone in-region — ensuring uninterrupted service. For more serious disruptions, Hyperforce also supports Out of Region Disaster Recovery by replicating a Salesforce instance from its primary region to a secondary geographic location. This safeguards Salesforce data and helps maintain business continuity even during large-scale regional failures, reinforcing Salesforce’s strong uptime commitments.
Unlocks Data Cloud and Agentforce
Some of Salesforce’s newest innovations, including Data Cloud and Agentforce, rely on the Hyperforce architecture for real-time data processing and streaming from sources like websites, apps, and service interactions. Data Cloud uses this to update unified customer profiles in real time and trigger personalized actions, while Agentforce surfaces live context and AI-powered recommendations. By integrating Data Cloud with Hyperforce, organizations can also take advantage of other big data tools without the burden of managing maintenance or underlying infrastructure. Migrating to Hyperforce not only unlocks these advanced capabilities but also positions teams for future innovation across the Salesforce ecosystem.
Public-cloud-powered innovation
Moving to the public cloud makes faster innovation possible across the entire Salesforce platform. By shifting to cloud service providers like AWS, GCP, and Azure, Salesforce no longer needs to manage the overhead of maintaining its own physical data centers. That means engineering teams can focus more on developing and delivering new features across Sales Cloud, Service Cloud, and beyond — and get those updates into customers’ hands faster.
Hyperforce security
When it comes to encryption on Hyperforce, you don’t have to choose between Hyperforce’s built-in protections and Salesforce Shield as the two work together to provide layered security.
Hyperforce applies volume-level encryption by default. This means that data at rest is encrypted with one encryption key, which Salesforce owns and manages. Salesforce Shield Platform Encryption adds another layer of security, which lets you encrypt data with keys you control and manage. Shield encryption also supports more granular use cases — like encrypting specific fields, controlling key rotation, or enforcing encryption policies.
This layered approach means that even if your organization doesn’t use Shield, your data is still encrypted by default in Hyperforce. But if you need more control over how sensitive data is secured, audited, or accessed, Shield can top up what Hyperforce already provides.
Beyond encryption, Hyperforce also changes how access to your data is handled. Salesforce uses a Just-in-Time access (JIT) model, which means internal Salesforce teams don’t have standing access to customer environments. Instead, access is granted temporarily, for specific support tasks, and with strict controls and logging to reduce the risk of unauthorized access to sensitive data.
How to manage a Hyperforce org
Moving to a Hyperforce instance changes the way some core infrastructure is handled — especially around URLs, domains, and network security settings.
URL and domain changes
Hyperforce’s new infrastructure model separates infrastructure from domain structure — this means that when you migrate your org’s URL will change. Instead of using the old shorthand instance-based format (like na123.salesforce.com), Hyperforce orgs will have a new domain, like yourInstance.my.salesforce-sites.com.
These changes can impact any tool, script, or integration that relies on a hardcoded domain — including bookmarked links, custom scripts, API clients, CI/CD pipelines, and webhooks. To prevent disruptions, it’s important to audit and update these references ahead of your migration.
To support this new model, My Domain is a requirement for all orgs migrating to Hyperforce. My Domain gives your org a unique, branded login URL (typically yourcompany.my.salesforce.com) and plays a key role in identity, access control, and authentication flows like SSO. Hyperforce depends on this consistent domain structure to route traffic securely and reliably across its public cloud infrastructure. If your org already uses My Domain, users will continue to access Salesforce through the same familiar custom domain — but the underlying domain and instance name will still change behind the scenes. If you’re not already using My Domain, you’ll need to enable and deploy it before your migration.
IP allowlisting and domain-based access
Salesforce previously relied heavily on a static list of IP ranges for allowlisting — formerly called whitelisting, this is a security control where specific network sources, like IP addresses or IP domains, are approved to access Salesforce applications.
Hyperforce’s public cloud infrastructure means the IP addresses powering your Salesforce org can change dynamically, making static IP allowlists difficult to maintain. Salesforce recommends allowlisting domains instead of IP addresses. This uses DNS patterns like *.force.com or *.my.salesforce.com to define what’s trusted.
How to migrate to Hyperforce
Salesforce Hyperforce migration is a strategic move — not just an infrastructure update. It unlocks better scalability, regional data residency, and faster innovation. Salesforce manages the migration process, but your team plays a crucial role in preparing your org and ensuring continuity. Here are some steps for a smooth migration:
1. Get notified by Salesforce. Salesforce will contact you in advance if your org is scheduled to move to Hyperforce. You’ll receive migration notices containing the Org ID, migration date, and the new target instance name 30 or 90 days before migration based on your support level.
2. Run Salesforce Optimizer. Use the Salesforce Optimizer tool to surface potential blockers ahead of time. It highlights hardcoded URLs, outdated features, API usage, and security risks — all of which can affect your readiness for Hyperforce.
3. Review hard-coded references. Check for instance-specific Salesforce URLs in integrations, custom code (Apex, Lightning components), external systems and APIs, Bookmarks, SSO configs, or browser extensions. Update these references to use My Domain or your new Hyperforce-compatible URLs. Salesforce has some advice on finding and updating these references here.
4. Plan for allowlist updates. Switch from IP-based allowlists to domain-based rules where possible — this helps avoid breakages if cloud infrastructure changes dynamically. If your organization still relies on static IP rules, you’ll need to review and update your lists to include the latest Salesforce IP ranges.
5. Update CI/CD and automation tools. Make sure your DevOps tools, test automation, and CI/CD systems aren’t relying on legacy endpoints or fixed IPs — including static hostnames in test scripts, deployment tools, or proxies. If your team uses Gearset, you won’t need to make any changes as it automatically supports orgs on Hyperforce and connects via My Domain. You’ll just want to double-check for any hardcoded URLs, static hostnames, or IP-based rules in your wider setup. If you have any questions about connecting to your org or validating and deploying post-migration, you can get in touch with your Gearset account manager.
6. Communicate internally. Let stakeholders — including admins, developers, security teams, and integration partners — know about the timing and impact of the move.
7. Schedule go-live support. Make sure your internal teams are available during and after the migration window to test key processes and escalate any issues.
How to tell if your Salesforce org has already migrated to Hyperforce
Most new Salesforce instances are provisioned on Hyperforce by default, and a growing number of existing orgs have been migrated, especially in key regions like North America, Europe, and Asia-Pacific. However, not all existing orgs are on Hyperforce yet — the migration is ongoing and prioritized by region, industry, and compliance needs.
You can check if your org is on Hyperforce by finding your instance name:
- Go to Setup and search Company Information in the Quick Find box.
- Find the Instance field in the Organization Detail section. Depending on the type of Salesforce infrastructure your org is on, your instance’s name is represented by two or three alphabetical characters followed by numbers. If you know your Domain Name, you can also search on the Salesforce Trust Status page to find your instance name.
- You can then search by Instance ID on the Salesforce Find My Instance Map to see your instance’s location and whether it is operating on Hyperforce or Non-Hyperforce infrastructure.
How much does Hyperforce cost
There is no separate or additional cost to use Hyperforce — it’s included as part of your existing Salesforce licenses, and Salesforce manages the infrastructure transition at no extra charge. However, if you need to comply with the European Union’s regulatory frameworks and choose to host your org in the Hyperforce EU Operating Zone (EU OZ), this option does come with an additional cost.
What impact does Hyperforce have on your DevOps workflow?
Hyperforce is designed to be an invisible shift — but with very real benefits for teams looking to develop a more complete DevOps lifecycle. Your Salesforce instance still works the same way, but it’s now powered by a more modern computing infrastructure. Hyperforce’s easily scalable platform means faster deployments, reduced test run times, and the ability to clone sandboxes almost instantly through Quick Clone.
One of the biggest benefits Hyperforce brings to DevOps is environment consistency. By standardising the core infrastructure, it reduces the kind of variability that can cause issues during deployment. CI/CD execution becomes more stable, performance holds steady even under pressure, and large metadata changes flow through with fewer bottlenecks.
And because Hyperforce lets you choose where to store data, it also opens up compliance-ready deployments in locations worldwide — ideal for businesses that need to align with regional regulations or want to expand into new global regions without rebuilding their infrastructure.
Start building on a platform that’s equipped for scale and security
If your Salesforce team needs to release faster, scale more confidently, and stay ahead of architectural changes like Hyperforce, it’s time to get your DevOps workflow in shape.
Gearset supports Salesforce services across classic, Hyperforce, and non-Hyperforce environments — with native support for My Domain, flexible deployment pipelines, and guardrails for every release. We’re already supporting many large enterprises with their app releases on Hyperforce, so you can be confident your team is set up for success from day one.
