Loading

B2C Commerce Hyperforce Realm Move — Pre-Move Checklist, Move Timeline, and Post-Move Verification

Publiceringsdatum: Aug 12, 2026
Beskrivning

Salesforce migrates B2C Commerce realms from legacy POD (Point of Delivery) infrastructure to Hyperforce, Salesforce's next-generation, public-cloud-native infrastructure built on hyperscaler providers (AWS, GCP). Hyperforce provides enhanced security, data residency options, and scalability compared to legacy POD infrastructure.
A Hyperforce realm move migrates a customer's entire B2C Commerce Primary Instance Group (PIG) — Production, Staging, and Development — to a new Hyperforce POD. Salesforce performs the move during a planned 2–7 AM maintenance window, and it takes approximately 5 hours. All PIG instances and storefronts stay offline during the move.

 

Real-Life Example

Consider a customer, Acme Retail, whose B2C Commerce realm is scheduled for a Hyperforce move on a Saturday at 2 AM PT. Thirty days before the move, Acme's team enables HTTPS enforcement, allowlists the Hyperforce outbound IPs in their WAF and payment gateway firewalls, migrates their legacy eCDN zone to a proxy zone, and uploads their 2FA (Two-Factor Authentication) client certificate so code uploads to Staging keep working after the cutover. During the move window, Acme's storefront and Business Manager are offline for about 5 hours while Salesforce migrates the databases and web/app layers to the new POD. After the move completes, Acme's support engineer verifies Business Manager access, confirms a test order completes payment processing successfully, and checks that an order-confirmation email reaches a test inbox — confirming the realm move succeeded with no service disruption.

 

Pre-Realm Move Steps

Complete the following steps at least 30 days before the scheduled migration date. Skipping any of these can cause service disruption after the move.

  • Migrate to HTTPS. Hyperforce enforces TLS (Transport Layer Security) encryption on all traffic and rejects unencrypted HTTP connections to protect customer data from interception. Enable it in Business Manager under Administration > Global Preferences > Security > Access Restriction tab > Enable Enforce HTTPS. See Enforce HTTPS for B2C Commerce.
  • Allowlist all Hyperforce outgoing IPs (see the Outbound IP Addresses table below) in the firewall settings of every integration, including third-party systems, so back-end connectivity keeps working after the move.
  • Migrate any legacy zone to a proxy zone. Legacy storefront zones are deprecated on Hyperforce; only proxy zones are supported. Migrating gives a standardized eCDN, auto-renewing certificates, and better troubleshooting. Check the zone type in Business Manager under Administration > Sites > Embedded CDN Settings (legacy zones show a "Legacy Zone" label). See Migrate a Legacy Zone to a Proxy Zone and the eCDN Proxy Zone FAQ for B2C Commerce.
  • Upload 2FA (Two-Factor Authentication) client certificates to eCDN. WebDAV authentication for code upload to Staging moves to eCDN as part of the migration, so code uploads fail without this step. Generate a self-signed certificate bundle, then upload the root CA (Certificate Authority) certificate via Business Manager or the CDN API, using a client certificate signed from the same root CA. See Generate, Sign, and Use Client Certificates for Secure Code Uploads, which covers mTLS (mutual TLS) certificate generation.
  • If using Salesforce SMTP, confirm sending email domains are listed and approved in Business Manager under Administration > Operations > Email Settings > Domains, and that the required DNS (Domain Name System) records are in place — this keeps outbound mail delivering after the move.
  • Verify the SPF (Sender Policy Framework) record points to the Production domain (for example, production-realmname.demandware.net) rather than an IP address, so confirmation emails keep sending smoothly post-move.
  • Update the maintenance page if using a custom maintenance page for when Production is offline.
  • Avoid submitting firewall change requests within 72 hours of the realm move, since changes made too close to the move window can't be validated in time.
Lösning

Hyperforce IP Allowlist by Region

Add all of the following IP addresses to the firewall allowlists of every third-party integration. All five regions must be allowlisted regardless of your primary Hyperforce region — Salesforce may route traffic from an alternate region during failover events.

RegionIP Address 1IP Address 2IP Address 3
useast2 (US East)18.190.166.58/323.130.91.8/323.136.57.110/32
apsoutheast2 (AP Southeast)54.79.57.97/323.24.132.176/323.106.175.125/32
apnortheast1 (AP Northeast)52.198.115.116/3252.194.10.115/3213.114.79.3/32
eunorth1 (EU North)13.49.122.164/3251.21.12.245/3213.48.103.142/32
apsouth2 (AP South)18.61.46.39/3298.130.30.92/3218.60.70.158/32

 

Please note that these Hyperforce IPs for Commerce Cloud, along with any future revisions, will be added to the official Hyperforce IP ranges, which can be found in JSON format at the URL https://ip-ranges.salesforce.com/ip-ranges.json. Customers using IP Allowlist are advised to allowlist all the IP ranges in the JSON file and monitor its updates. For a full explanation and best practices, read Hyperforce IPs to Allow - Sales, Service, Industries, and Tableau Clouds.

Realm Move Steps (Performed by Salesforce)

The realm move itself is performed by Salesforce during the 2–7 AM maintenance window (source POD's time zone) and is communicated to you via case.

  1. ~5 hours before the move: Staging and Development instances go offline first, to prevent replications and other data changes that would extend downtime.
  2. Pre-move count check: Salesforce records the customer and order counts from Production Business Manager (Merchant Tools | Customers, and Merchant Tools | Orders), noting the time and time zone, in case of any Elasticsearch discrepancies after the move.
  3. Follow-the-sun coverage: The case is flagged for global handover so a support engineer is monitoring throughout the move window.
  4. ~0200 POD time — move begins: The maintenance page goes up and the case is updated to note maintenance has started.
  5. Core cutover activities: Salesforce shuts down the web/app layer on the old POD, kicks off final data replication to the new Hyperforce POD, starts up databases and the web/app layer on the new POD, then shuts down the old POD's databases.
  6. ~0300–0700 POD time — move completes: Support confirms Business Manager, storefront, and MongoDB functionality, then takes down the maintenance page and updates the case.

Any storefront IPs behind eCDN are handled directly by Salesforce Operations during this window — no customer action is needed for those.

Please note that if the Hyperforce move coincides with a pre-scheduled monthly release update, the monthly release update will be deployed immediately following the Hyperforce move in the same maintenance window.

Post-Realm Move Steps

After the move completes, verify the following to confirm your storefront is fully operational on the new POD:

  • Business Manager instances and storefronts are up and reachable.
  • Code upload works properly (this depends on the 2FA certificates uploaded during pre-move steps).
  • Third-party integrations, payment processing, and order completion all work end-to-end.
  • External firewalls allow inbound access from the new Hyperforce POD.
  • Outgoing mail works — confirm shoppers receive order confirmation and signup emails.

If you encounter issues, please see Common Customer Issues Post-Hyperforce Migration in B2C Commerce: Mail and SFTP Failures.

Ytterligare resurser
Knowledge-artikelnummer

002888834

 
Laddar
Salesforce Help | Article