How to Prepare for an Instance Migration
|Knowledge Article Number||000176190|
THIS KNOWLEDGE ARTICLE HAS BEEN ARCHIVED.
Starting in 2016, we will no longer be performing instance split or migration maintenances. Instead, we will be conducting "instance refresh" maintenances. Instance refreshes will streamline the customer experience as well as the execution process for our tech teams. More information on instance refreshes can be found in the Instance Refresh Maintenance FAQ article.
To ensure exceptional performance, availability and reliability of our service, we occasionally need to perform a capacity planning activity, called an instance migration (e.g. NA5, EU2, etc), where we move our customers on an existing Salesforce instance in one data center to a new Salesforce instance in another data center. This takes place during a standard system maintenance window, which may be extended for the maintenance. If you are looking for information on preparing for a split - where we move a subset of our customers to a new Salesforce instance - please see the How to prepare for a Split Knowledge Article.
We continuously monitor the growth and performance of all our instances in order to plan ahead for additional capacity and enable the continued growth in the capabilities of the platform. When an instance is identified as one that is nearing our threshold for capacity, we make the decision to perform an instance migration. Prior to doing so, we make every effort to ensure customers are aware and prepared. Below are some common questions we received from customers that you may find valuable.
Note: This document is for informational purposes only, and is not part of any legal or otherwise binding agreement. The policies and practices described in this document are subject to change at Salesforce's sole discretion.
1. Why do you perform an instance migration?
Due to the extraordinary growth and success of our customers, we occasionally need to perform an instance migration, where we move all customers on an instance from one data center to another data center. Moving an entire instance from one data center to another data center enables us to continue to maintain the high level of performance our customers have come to expect from Salesforce.
2. How will this migration benefit me?By scaling our infrastructure, we are planning for your growth and success, and with these improvements, we will continue to provide exceptional performance, availability, and reliability of our service.
3. What factors do you consider when deciding to perform an instance migration?
In order to ensure exceptional performance, availability and reliability of our service, we continuously monitor the growth and performance of all our instances in order to plan ahead for additional capacity and enable the continued growth in the capabilities of the platform. Capacity planning activities include reviewing transaction performance and reliability of the instance, in addition to determining the optimal size of an instance for recoverability. Our goal is to review the factors above and take the necessary steps that will allow us to continue to deliver high levels of performance.
4. When are instance migrations scheduled?
To the extent reasonably possible, we schedule these during the instance’s standard maintenance windows, which usually take place during off-peak business hours. However, due to the types of activities required when moving customers to another instance, the maintenance window may extend beyond the standard maintenance window. During this time, your instance will be unavailable, but may be available in Read-Only mode. You can read more about this functionality in this Read-Only Mode Overview. If Read-Only mode is unavailable during the maintenance, users attempting to access their current or new instances during this window will be presented with a scheduled maintenance notification page.
5. How is Salesforce communicating the change to customers?
Salesforce will leverage our Product and Service Notification emails and rely on our Support teams to ensure you are aware and prepared for this upcoming instance migration.
6. What action do I need to take if my sandbox is on an instance scheduled to migrate to a new data center?
7. If I have built custom configurations in my sandbox, will they be preserved with the instance migration, or do I need to rebuild them?
If you choose not to refresh your sandbox prior to the instance migration maintenance, custom configurations you have built will be preserved with the migration
8. Where can I go if I have further questions?
For further questions, please contact Customer Support by logging a case via the Help & Training portal.
The following questions are technical in nature, and were written for the Administrator at your organization, or your IT department. We recommend that you start with our Customer Instructions, which include best practices for leveraging relative URLs in your integrations and whitelisting IP addresses for all Salesforce data centers.
1. Do I need to make any changes to my IP addresses?
If you or your team have set up your corporate network settings to allow only certain IP ranges, including for Email Security Filters or Email Relaying, or due to Firewalls, please ensure that you are including our newest ranges. More information on which IP ranges to include can be found in the What are the Salesforce IP Addresses to whitelist? Knowledge article.
2. Can I remove my old IP addresses from my set of whitelisted IP ranges after the instance migration is complete?
The best practice is to whitelist all of our data centers with the IP address ranges. There is no risk in whitelisting the specified range of IP addresses as Salesforce owns the range; it is not leased or shared in any way with any other organization. Salesforce has an IP address block allocated directly to Salesforce by the American Registry for Internet Numbers (ARIN).
If your or your team have set up your corporate network settings to allow only certain IP ranges for Email Security Filters or Email Relaying, or due to Firewalls, please ensure that you are including our newest ranges added in April 2015. More information on which IP ranges to include can be found in this Knowledge Article: https://help.salesforce.com/HTViewSolution?id=000003652&language=en_US&release=180.9.
3. Is there a way for me to test the whitelisting of IP ranges on my side?
Yes, you can test the whitelisting of IP ranges by trying to reach an instance that is already live in the data center you are moving to. For example, if your instance is moving to our midwest data center, then your test would be to call (via a ping test or API request) any instances located in the midwest data center - EU1, NA8, NA9, CS7, CS8, CS14.
4. Do I need to restart integrations after the maintenance?
Yes, you may need to restart some integrations after the maintenance. By restarting your integrations following the maintenance window, you would be clearing the DNS lookup cache which would cause your integration to refresh and detect the IP address of the new data center. It is not required, but if you experience any issues with your integrations post-migration, plan on restarting them before contacting support.
5. Do I need to update or make changes to my DNS after the migration?
Yes, if you control your DNS timeout values set, then you will need to refresh your DNS cache and restart any integrations following the maintenance.6. Will this impact my CTI integration?
This maintenance will not impact a CTI integration.
7. Will the CTI screen pop-up keep working after the move?
Yes, the CTI screen pop-up will continue to work after the move.
8. If I have My Domain setup, do I need to do anything in preparation of this maintenance?
This instance migration will be seamless to our My Domain customers, as long as you follow our best practices of whitelisting IP addresses.
9. Should I hold off on implementing My Domain until after the maintenance is complete?
No, there is no technical reason to hold off the implementation of My Domain because of this maintenance. The only timing to watch out for is when you ‘register’ the My Domain name. You should allow 24 hours for the request to complete, so we recommend avoiding making this change right before the maintenance to avoid the very remote chance of getting the DNS paired with an incorrect IP address (and missing the correction during maintenance). This registration step can be done well in advance if you have a tight schedule.
10. Do I need to make any changes to my Sender Policy Framework (SPF) records?
It depends on how you have your SPF setup. We recommend enabling the “Enable compliance with standard email security mechanisms” option, but in the unlikely case where you have specific Salesforce IP addresses listed in your SPF, you will need to change them, or include our SPF records that cover all IP ranges. For more information on the Sender Policy Framework, please see our Knowledge Article.
11. Do I need to compare my sandbox performance levels from before the instance migration to after the move to the new data center?
No, you do not need to be concerned with sandbox performance levels for instance migrations. When we move an instance to a new data center migrations, we make local copies of the customer’s sandbox files in the original data center prior to the instance migration. That way the customer doesn’t have any file access performance issues with sandbox files post-migration.
12. What happens if my sandbox was in the middle of a refresh during the migration?If you were in the middle of a sandbox refresh when the instance migration maintenance began, the sandbox refresh will stop and not complete prior to the migration. Your sandbox will experience the instance migration maintenance. The refresh will automatically be restarted, in the new location, 24 hours after the migration is complete as the suspension is lifted from the queues.
13. Will there be any impact to Web-to-Leads/Cases (W2X)?
No, there will not be any impact to W2X. W2X will be queued and processed once the maintenance is complete.
14. Will there be any impact to Email-to-Case (E2C)?
Yes, while E2C emails are normally queued and processed once the maintenance is complete, our messaging server has a hard limit of holding E2C emails for 24h hours.
This can become an issue if the maintenance exceeds 24 hours, any E2C emails older than 24 hours will be bounced. For this reasons it is recommended alternate means to capture E2C emails during in the maintenance should be arranged.
15. Do I need to update hard-coded references for the migration?
If you have any hard-coded references (for example, na7.salesforce.com), we recommend updating them to relative URLs (for example, login.salesforce.com), especially in Knowledge articles and integrations. This is not required for the migration, but is a best practice that we recommend customers follow and may be necessary for a future maintenance.
16. What does the maintenance page look like when an instance is unavailable (e.g. during maintenance)?
See the image below. However, if a customer has an single sign-on with a customer login page (which they control), they will get a 404 (Page Not Found) error.
17. I have a Partner Portal. Can I control what my end users will see when trying to access my partner portal or community during the migration maintenance window? It depends on several factors. The matrix below describes what to expect for each site type based on whether the domain supports https and whether a custom service-not-available (SNA) page has been set up on the site.
a. It depends on several factors. The matrix below describes what to expect for each site type based on whether the domain supports https and whether a custom service-not-available (SNA) page has been set up on the site.
b. Yes. If you are using a Force.com site on a http-only domain or a Salesforce Community on a custom https domain, assign a maintenance or error page for anyone trying to access your partner portal or community during the maintenance via the following link: https://help.salesforce.com/HTViewHelpDoc?id=sites_error_pages.htm&language=en_US . Please note that in a Force.com site that is not a Salesforce Community, this page is presently shown only on http-only domains and not on https domains. In a Salesforce Community, this page is shown only on custom https domains and not on the force.com subdomain.
c. If you are using Site.com, it will remain online during the maintenance window, though repeaters and forms, which are unique to Site.com, will show errors instead of presenting the repeater data and form data.
d. Any site or domain that can't have a service-not-available page configured from the criteria above will display a browser-specific error message after a timeout period elapses.
e. Any Force.com site that is not a Salesforce Community and does not have a service-not-available page configured will display a page that looks like the following on its http-only domains:
f. If you are accessing your secure.force.com subdomain via https, you will get a browser-specific error message after a timeout.
g. If you attempt to access Salesforce Communities, you will receive a browser-specific error message after timeout.
18. If I have a self-signed certificate that was generated in Salesforce, will this need to be reissued after migrating to a new instance?
No. These certificates will move to the new instance.
19. If I have locally stored certificates with my instance name hard-coded in them, do I need to re-download the certificates following the migration?
No. These certificates will remain the same as they were before the migration.
20. Where can I go to find more information on certificates?
We encourage you to join the Success Community called "Official: Certificate Changes".
21. Does Salesforce offer read-only environments for 24/7 customers who need access to the Salesforce application at all times?
Yes, Read-Only mode may be available for a portion of your maintenance. You can read more about Read-Only mode here: Read Only Mode Overview
22. Do I need to request my Email Logs before the migration?Since you are moving to a new data center during the migration maintenance, you will need to request your Email Logs prior to the migration. Email Logs from your former data center cannot be extracted after the migration maintenance. Once the Email Logs are requested, they will be stored in the database and migrated along with your other data.