B2C Commerce POD Move FAQ - Common Questions about POD Moves

Why is it important to move from the existing POD? What is the upside of doing so and potential downside of not doing so?
The B2C Commerce platform continually enhances our grid computing platform by adding new Points of Delivery (PODs) and refurbishing or upgrading existing equipment. This is necessary in order to stay ahead of our customers’ aggregate capacity requirements, improve disaster recovery capabilities, and to meet security or compliance requirements. The move for customers to a new or different POD is important in that it allows balance of the grid, and brings new capabilities and capacity to the platform overall. If customer realms remained static on equipment, they would be limited by the current technology, and would likely not have the growth capacity needed to scale with demand.

Can I refuse a POD move?
Customers cannot refuse Commerce Cloud's decision to relocate a realm to a different POD, as the management of POD resources are part of the Commerce Cloud model of how resources are allocated and part of our basic operational procedures.

Is there any data that is not included in the Realm Move process that should be manually backed up prior to the move?
Application and Web logs are included in a Realm Move.
IMPEX logs are carried over to the new POD during the move. Customers do not need to back those logs up.
ALL of the data contained in each of the realm specific storage volumes are snap mirrrored over to the new POD. The webdav folder/data lives within the application config volume(s). Everything contained in these volumes are snap mirrored over. We do not migrate data at the directory/file level.

Is it possible to keep an old IP address after a realm move?
No, this is technically not possible.

If our realm is behind eCDN, will any DNS changes be necessary?
 After migrating to the new Embedded CDN (eCDN), you will use a DNS CNAME to the eCDN instead of an A record to the origin IP.  This CNAME will not change, therefore no DNS changes are required in subsequent realm moves. Due to technical limitations in the DNS specification, Apex / root domains (example.com) cannot carry a CNAME record to point to an alias hostname of the eCDN, root domains cannot carry a CNAME. As a solution, please set up a redirect from your root domain to a subdomain! Please also read the following help article: Configure root domains with eCDN

Note: We do not recommend to point your root domain to the eCDN IP. The IP can change without prior warning. 

What does Commerce Cloud need from our Site Administrator to complete this task?
Commerce Cloud asks that customers have their network administrator verify that all Commerce Cloud Grid systems (PODs) are allowed in their security configurations. We would also request that a list of any IP/Port pairs used for site integrations be provided so connectivity can be verified. If a custom maintenance page used during scheduled downtime is not already in place, it should be provided in advance of the move date.

For all customer domains on Production and Development no DNS changes are necessary as all the domains are behind eCDN.

If custom domains are used in Staging, however, the customer's administrator will need to update DNS after the PIG move, since Staging is not behind eCDN.

Administrators will need to change the DNS nameserver entries (A records) for their storefront domains as close as possible to the scheduled POD move maintenance. Commerce Cloud will have proxy servers in place to handle any needed re-direction, but timely change of this configuration is recommended to avoid any performance impact. Commerce Cloud also recommends that DNS TTL (cache) is set to a reduced time (30 min) to minimize delay of changes.

Finally we would ask that customers review their sites following the maintenance, and immediately report any issues to the Commerce Cloud support team.

What are the things that could go wrong during a POD move, and what steps have been taken to mitigate the risk?
Before POD cutover is finalized, the B2C Commerce Technology and Infrastructure team verifies that the data sync of the file system (code, images, files, logs, etc. is 100% complete and the file sizes match). The same process is followed for the database copy so we know that all data has been moved successfully and is an exact match of the source system. They also ensure that connectivity for all known back-end integrations is allowed and verify that the storefront is operational before the maintenance page is removed. An area of concern is always communication with external systems, as security configurations or use of hard-coded IP addresses could disrupt connections needed for integrations. If a problem is discovered during cutover, Commerce Cloud will work in real time to resolve the issue fully, and restore operation to site production as soon as possible.

Will there be any effect on my back-end systems or integrations?
Commerce Cloud Operations will pre-check basic network connections to IP/Port pairs from the new Point of Delivery at a customer’s request. This will help catch any network security filters outside of the Commerce Cloud Grid that may need to be updated with the new PODs IP information. It is recommended that the outbound IP addresses of both the new POD and the disaster recover (DR) POD are allowed at all times.  This not only allows for scheduled realm moves, but is critical in disaster situations where a realm is restarted on a backup POD as part of disaster recovery procedures. Support will provide the POD numbers.  Information on obtaining POD outgoing IP addresses is available below:​

• Locations and Outgoing POD IPs for each Commerce Cloud POD [AMER PODs]
• Locations and Outgoing POD IPs for each Commerce Cloud POD [EMEA/APAC PODs]

Will there be any changes visible to our site visitors or ecommerce customers post realm move?
No, all site pages, storefront content, images and links will remain unchanged. Domain and hostname name resolution is handled via the DNS changes, which will direct traffic to the new POD IP. In the event that some internet nameservers continue to resolve to outdated IP addresses, the temporary proxy put in place will ensure redirection.

Does a POD move have any effect on Search Engine ranking or our SEO?
No, search engines such as Google do consider age of a domain, and calculate trust based on changes to the domain registration information. DNS/IP changes are not included in trust calculations, the content of the site is not changed during a POD move, so there will be no effect on SEO placement or ranking.

Will developer Sandboxes be affected?
Part of the POD move procedure will relocate the Secondary Instance Group (SIG), or POD based sandboxes within a realm. This will result in changes to IP addresses of sandbox instances. Most developers reference sandboxes by their hostname at demandware.net and will see no change, as the new IPs will be updated in DNS. Commerce Cloud will provide the new Business Manager IP for every instance for those developers that desire to use them.

Will On-Demand Sandboxes be affected?

On-demand sandboxes operate on different infrastructure and are not impacted by POD moves. On-demand sandboxes will be fully accessible during the maintenance. 

If the POD move were to fail, what is the backup / rollback plan?
The move of the realm from one POD to another is simply a copy of data, rather than an actual move.  So, up until the point at which the realm comes online on the new POD, all the data for the realm still exists on the original POD in the same state at which it was brought offline.  In the unlikely event that the realm move cannot be completed in the maintenance window, the realm can simply be brought back online on the original POD.  No customer action is needed. 

How much downtime is associated with a POD move? 
There is some required downtime for both PIG & SIG instances to complete this change. Below find the maintenance windows and their maximum length. Keep in mind, 

• SIG Move: 5 hour maximum downtime for SIG instance. 
• PIG Move: 5 hour maximum downtime for Production, plus Staging & Development will be taken offline 5 hours prior to the scheduled PIG move, and will remain down until the entire group is available as a whole. 

Will existing two-factor certificates need to be regenerated?
No, existing certificates will be migrated to the new POD and no changes will be necessary.

Will existing firewall rules be migrated to the new Pod destination?

Yes, all existing firewall rules in place on the source pod will be migrated to the new destination pod. 

Which ports are open by default on the B2C Commerce platform?
TCP ports 22, 80, 443, and 587 are open by default on B2C Commerce and do not need Firewall Rules created. Port 21 (ftp) is not open by default, but a request can be made and it will opened.

If we have integrations with other clouds, such as Marketing Cloud or Service Cloud, do we have to make any changes?
As part of the POD move, it is advised to always check all other integrations to make sure they're working post POD move. Most Cross Cloud integrations use domain names to connect, which will not change with a POD move. They do not use a direct IP to connect. Some endpoints such as Marketing Cloud Personalization can be impacted. In the event API calls are no longer successful post Pod migration, please ensure to add the new destination Pod outgoing IP address to your firewall rule Allow list. 

Will there be any re-establishment steps for integrations like OMS, OCI, PWA Kit or Heroku?
All such integrations are by domain name, not IP, so this should not be impacted in the POD move.

Does OCI cache need to be rebuilt or cleared after a B2C POD move?
No. Cache files are stored in the realm database. Since the entire database is moved during a POD move, the OCI cache tables will be moved along with them.

Will the active baskets be migrated during POD move?
Yes. The active baskets are migrated as part of POD move

In the event a realm has configured the orange to orange configuration, will any additional action need to be completed on the eCDN vendor side?
No. O2O is the technical configuration for the eyeball zone in eCDN to the proxy zone in Salesforce. The POD move will be processed as if a stacked eCDN were implemented.

What HTTP status code is received when the Production instance is down during the PIG move?
The status is 503.

Who will be adjusting the site status to Maintenance Mode during the migration?

The Salesforce Technology team will adjust the site status during the maintenance and will adjust the sites(s) back to online status following the migration. In the event you would like an optional custom maintenance page displayed, please ensure the custom page has been uploaded in Business Manager.  (Administration > Site Development > Custom Maintenance Pages)

Reference: Maintenance Pages

Why is the uploaded custom maintenance page not displayed during the POD move migration? 
The directory inside the zip file uploaded into Business Manager has to have the format www.domain.com, not just domain.com. For example, if it’s configured as domain.com, the maintenance page will only show if the root domain is hit during the Primary instance group realm migration.

Will the POD migration impact Time to First Byte?

No, the time to first byte will not be impacted by the POD migration. 

How will the POD migration impact my hybrid Composable site i.e. PWA deployed in Managed Runtime (MRT) & Site Genesis JavaScript Controllers (SGJC)?

MRT is not impacted by realm moves. SCAPI which means pages that require SCAPI calls to render will fail. The homepage, by default, also requires SCAPI calls to render. SCAPI returns a 503 error status code when maintenance is underway for a given realm. There is no formal notion of maintenance mode in the PWA Kit.  Our suggestion is to place the site in maintenance mode via business manager for the production instance and deploy the bundle displaying the maintenance page temporarily. Customers can also implement a handler for when getting receiving a 503, a static page is returned offering traffic guidance.

What is the best practice when utilizing SLAS clients following a Pod move Region Migration?

Note: When utilizing SLAS and the realm is migrated to a new region (EX.AMER TO EU), it is recommended, the merchant create a new short code and a NEW ODS instance in the new destination region (and then configure NEW SLAS clients on that new instance and no longer use the source region based ODS's instances. 

Can B2C Commerce provide a list of currently allowlisted IPs for my realm on the current POD?
B2C Commerce Support shall provide the list of allow-listed IP address(s) that are allow-listed on the current POD. Usually, this data is provided to the customer ~1 week before the realm move in the form of a PREP/Output file. The IPs that B2C Commerce Support is able to compile and connect on the old POD will be by default moved on to the new POD. If the customer has new IPs to be allow-listed on the B2C Commerce side, they may raise a new case after the realm move is completed.