Skip Navigation
Pod/Datacenter Migrations/Transports General Process
Answer ID 5688   |   Last Review Date 09/10/2019

What information do we need to know about a pod migration/transport and how it works?


Pod/Datacenter Migration/Transport


What is a pod/datacenter migration/transport?
A pod or datacenter is where the sites (instances) are hosted by Oracle. There are various pods all over the world. A pod migration/transport is when sites are moved to a different pod.

Why move the site to a different pod?
There are many reasons to request a different pod. Every scenario is different based on customer business needs.

Will a pod migration affect Configuration Assistant self-service tool?
Yes. The Configuration Assistant uses the pod that the site is hosted on in the url (ossc-<pod> 
The contract/license change process includes the back end entitlement information which affects the Configuration Assistant. 
After the contract/license changes are complete, you will not be able to access the Configuration Assistant until the site(s) are physically on the new pod. 

How is the pod determined?
The pod that your site(s) is hosted on is determined during the sales/provisioning processes of the initial site/instance purchase.  Oracle B2C Service Technical Support has no insight into this decision. Questions regarding this decision should be addressed with your sales account manager. 

What is happening while moving the production site?
An internal transport site is created, which is a running duplicate of the production site. The internal transport site is moved to the new pod while the active production site is still on the old pod. Then, databases are compared and synchronized. Once the synchronization is completed, all live traffic is directed to the new pod and final transport steps are completed.
During these processes, your production site will be moved into maintenance mode. The standard maintenance page will be displayed. The average time to complete the cutover steps on the production site is between 5 and 30 minutes. However, until DNS fully propagates, an "HTTP 404" message may be displayed. 

What is the overall process of a pod migration/transport?
1. The customer determines that they need to move their sites to a different pod. 
2. The customer needs to contact their sales account manager and process the pod migration request. Because the pod is part of the contract with Oracle, the contract will need to be updated.  This process must be completed by the sales account manager. 
  • The Configuration Assistant self-service tool ( is based off the information in the contract. Therefore, during the time between when the contract is changed and sites are physically moved to the new pod, the Configuration Assistant will not be able to display the sites. During this time, customers will need to submit service requests for the tasks that are needed. It is helpful to mention in the service request that a pod migration is currently in progress. 

3. Once the contract is updated, the customer can submit a service request to Oracle B2C Service Technical Support team ( to request a pod migration.  The Technical Support agent co-ordinates the request with the internal team.  

  • Please allow for at least 7 business days for scheduling the request. The pod migration process is not a simple task. Please allow for ample time to complete the entire process for each site being migrated/transported. Due the complexity of the tasks to move the sites to a new pod, errors can be encountered that can delay the processes. Our teams make every effort to resolve any issues encountered as quickly as possible. 
  • Test site(s) will be migrated/transported first. IF there are no test sites, then a "sitename__mig" (migration) site will be created by cloning the production site to a new/separate temporary test site and moving to the new pod. 
  • Customer should provide the designated test site to be migrated when submitting the service request. 
4. Technical Support agent updates customer that the test site has been scheduled to be migrated to the new pod.
5. Technical Support agent updates customer when test site has been migrated and is ready to be accessed. 
6. Customer will test on the test site.

  • As every customer has different configuration and business practices, there is no standard steps of what to test. It is recommended that customer test their typical business processes, tasks, and functions. 
  • If there are multiple test sites, customer will need to update service request with next test site to migrate to the new pod. 
7. Customer updates the service request to proceed with production site migration/transport.  Please allow for ample scheduling time (at least 7 business days).  
8. Technical Support agent co-ordinates production site schedule for migration/transport with internal team.  Agent updates the service request to notify customer of schedule. 
9. The production site is transported to the new pod and the internal team notifies the Technical Support agent. Please note, we are unable to predict how long this process will take as it can vary greatly due to many factors. 
10. The Technical Support agent updates the customer. 

To help to ensure a smooth migration/transport, please note following items that should be avoided during a pod migration/transport.
  • Refrain from executing broadcast mailings during the 24 hour period prior to the cutover to ensure mailings aren't interrupted as part of the migration cutover.
  • Please do not conduct a Customer Portal deploy during the 24 hour period prior to the cutover to ensure consistency with the final site migration cutover.
  • Please do not submit any upgrade site requests until after all pod migration tasks are completed. An upgrade and pod migration/transport cannot occur simultaneously. 
  • Please refrain from making Custom Business Object deployments or Custom Field changes during the scheduled time of pod migration. 

What changes are needed on the customers' side prior to the transport cutover?
Organizations have different policies for internet access. Many organizations do not restrict outbound internet access (i.e. employees can access anything on the internet), if that is your policy, then there will be no changes required. Select organizations deploy restrictions for access based on content or site names (i.e. social networks, game sites), if that is your policy, then you are likely to not need to make any changes but it is important to validate. Other organizations deploy very rigid access policies by selecting specific IP addresses that can access in or out of the internal corporate networks. In this scenario, a change to the network access policy will be required to allow the Oracle IP range.
If you are hosting your own service mailboxes (responsible for incident creation and updates) externally to Oracle, you will need to work with your 3rd party provider to ensure that the provider accepts inbound requests from the communicated IP ranges on ports 110 and 443.

What changes are needed on the customers' side after the transport cutover?

After cutover, you will want to check all of the mailboxes that have any address using the domain are prepended with the new pod designation. For example, if you are migrating from the MW pod to the VA pod, your current domain addresses should look like After the cutover, the addresses should be If the addresses are not set to the new pod, please edit the address fields in the mailboxes component to match the new pod designation. 

Verifying the new pod designation ensures that your email is being routed properly through our infrastructure and provides for better email performance.

*Note: If you are forwarding mail to an Oracle hosted mailbox, please change the forward to match the new pod designation as well to improve email performance. Email will still be processed if sent to the old pod designation, but it will take more hops to get to where it needs to be.