Last updated on October 3, 2024
What is a Site Switch?
Each Salesforce instance is built and maintained in two geographically separate locations. An instance is actively served from one location (the active site) with transactions replicating in near real-time to the other completely redundant location (the ready site). A site switch means the locations of an instance’s active and ready sites are swapped, making the ready site the new active site and vice versa -- the instance name does not change. This infrastructure model allows us to switch the location of the active site for maintenance, compliance, and disaster recovery purposes.
Important Actions
A. Subscribe to Trust Notifications to know when site switches happen.
B. Follow Salesforce infrastructure best practices by not restricting access to Salesforce IP ranges, Government Cloud IP ranges (if applicable), removing hard-coded references, and by setting your DNS timeout value to 5 minutes (default setting).
C. Customers with Live Agent/SOS custom clients should ensure those clients can properly handle redirects to the new active site, otherwise a disruption to your Live Agent service can occur. The best method to avoid these issues is to handle the SwitchServer response and use the 'newUrl' property for the request that resulted in this response and all subsequent requests thereafter. For more information see question 8.
D. If you need to view your email logs after a site switch, request for your email logs prior to the maintenance window. See question 11 for more details.
E. It is important for customers to refresh their DNS cache on both the client endpoints (e.g. PC) as well as with their Internet Service Provider (ISP). In some cases, the ISP needs to be asked to refresh its DNS tables to mitigate any potential login issues that are not attributable to Salesforce.
Frequently Asked Questions
1. How does Salesforce communicate a site switch?
Planned site switches are posted to the maintenance calendar on our Trust site at status.salesforce.com. If we need to perform a site switch during an incident to bring an instance back online, the incident record on status.salesforce.com will be updated to reflect that information. Sign up for Trust Notifications regarding your instance to receive maintenance notification emails (reminders, starting, updates, and completed) as well as incident notification emails (new, updates, resolved, and root cause). See the Trust Notification User Guide for more information on how to sign-up for these emails.
2. How long does a site switch take?
Currently, site switches take approximately twenty minutes to complete. For planned site switches, we post the anticipated site switch activity window to Trust.
3. Can I opt out of a site switch?
Individual orgs cannot be opted out of a site switch. Due to the multi-tenant architecture of our infrastructure, all orgs on the instance must undergo a site switch at the same time.
Planned site switches are only scheduled during preferred system maintenance windows. We ask that you plan maintenance activities for your Salesforce org (software upgrades, integration changes, etc.) outside of the preferred system maintenance windows.
4. Will I be able to access my org during a site switch?
During planned site switches, your org is unavailable. Site switches now are completed in about 20 minutes. We recommend that customers consider the instance unavailable during the site switch.
5. What actions are required to prepare for a site switch?
If you already follow our infrastructure best practices by not restricting access to Salesforce IP ranges and by setting your DNS timeout value to 5 minutes (default setting), a site switch should be seamless to your users.
Otherwise, if you are restricting access to certain IP ranges or data centers, update your network settings to include the complete list of Salesforce IP ranges in order to avoid any unintended service disruptions following a site switch. And if you control your DNS timeout values set, then you may need to refresh your DNS cache and restart any integrations following the maintenance.
6. How does a site switch impact previously scheduled activities (weekly exports, Apex jobs, etc.) and Apex callouts?
Ongoing activities will be paused prior to the site switch and resumed following the site switch. Activities scheduled during the site switch will start following the site switch.
A small subset of Apex, Batch Apex, REST API, SOAP API, and Bulk API jobs started prior to the site switch may return an error following the maintenance window. If you receive an error resulting from a previously scheduled job following the maintenance window, restarting the job will return the expected results. We recommend rescheduling large or long-running jobs after the site switch completes for the most seamless experience.
Apex callouts to external services will not execute during the maintenance. We recommend preventing these callouts from executing during the maintenance period. For more information on how to prevent these callouts, see Callout Limits and Limitations.
7. How does a site switch impact Web-2-Lead, Web-2-Case, and Email-2-Case activities?
Email-2-Case activities that occur during the site switch are queued and processed after the site switch has completed. Web-2-Lead and Web-2-Case are suspended and will be resumed after the maintenance is complete.
8. Will a site switch impact Live Agent?
Yes. During a site switch, your org’s active site gets switched to the ready location, and the ready site gets switched to the active location. When this happens, the URL you use to access Live Agent/SOS changes. Chat clients and deployment code supplied by Salesforce react to this change and appropriately forward HTTP requests to the new endpoint, but some third-party or custom applications, including Live Agent custom REST clients, may not. These custom applications will not be able to find your account on your previous instance and will likely fail.
To minimize impact to your Live Agent/SOS implementation, follow best practices and ensure your Live Agent custom REST client can properly redirect requests to a new instance of the Live Agent service following any maintenance involving a move for your org. The best method to avoid these issues with your custom client (which, again, will not automatically direct requests to the correct endpoint) is to handle the SwitchServer response and use the 'newUrl' property for the request that resulted in this response and all subsequent requests thereafter. For more information on updating your custom client and testing, read the article, How to update your Live Agent custom client when your org instance changes. This will ensure your custom client will not encounter issues after a site switch, and will provide you ample time to later update the endpoint used from the start of its execution.
For more information about Live Agent endpoints and what is meant by hard-coded Live Agent references, review the article, Live Agent server (endpoint URL) has changed and now Live Agent Chat is no longer working.
9. How does a site switch impact ongoing sandbox refreshes?
Sandbox refreshes that are not completed prior to the site switch will be stopped. The sandbox refresh will restart (not resume) following the site switch. In addition, customers will not be able to initiate a sandbox refresh during the site switch.
10. Does site switching affect email sends (for example, to mobile carriers or Office 365)?
After a site switch, emails are sent from Mail Transport Agents (MTAs) that have different IPs from the ones your mail was previously sent from. These MTAs should have an established reputation and email delivery should not be impacted unless you are using Email Relaying with Access Control Lists (ACLs) and allowed lists. In this scenario please check the article, Salesforce IP Addresses and Domains to Allow and ensure you have the IPs for email relaying in your ACLs and allowed lists as needed. To verify if you are using email relaying in Salesforce, navigate to Setup and search for "Email Relay Activation" - if the active checkbox is selected, mail is being delivered to the host noted within the settings using email relaying.
11. If I plan to view my Email Logs after the site switch, do I need to request my Email Logs before the maintenance?
If you will need to view your email logs after the site switch, then you need to request your email logs prior to the maintenance window. You can request your email logs by following the steps in the Request an Email Log article. Once email logs are requested, they will be stored in the database and migrated along with your site switch maintenance. Email Logs from your former data center cannot be extracted after the site switch.
There may be a short period of time where you will notice that email logs will show emails as sent, but the final destination of the email will not be included for up to 30 days after the maintenance. This is because IPs on the newly active site need to establish reputation in the Internet before sending larger volumes of traffic.
12. What is Salesforce’s Continuous Site Switching program?
For more information on the Continuous Site Switching program, review our Continuous Site Switching article.
13. How does a site switch impact platform events and change data capture?
Site switches don't affect the stream of retained events for subscribers, including Pub/Sub API, Streaming API, empApi Lightning components, Apex triggers, event relays, and flows. However, Apex triggers that are used as parallel subscriptions are affected if the trigger is lagging behind and hasn't finished processing all events when the site switch occurs. In this case, the Apex trigger can't continue processing unprocessed events from before the site switch. The parallel subscriptions resume from newly published events after the site switch.
000387541

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.