Sandbox Migrations – “But I don’t want to move! All my friends live here!”
On occasion, you may receive an email stating “Action Required” which indicates that Salesforce will be migrating your Sandbox instance onto new ‘infrastructure’. Infrastructure refers to the physical servers, typically large groups of integrated servers, upon which all of your Salesforce Sandbox instances reside.
“Yep, we received the Salesforce email about sandbox migrations…how do I know they’re talking about us?”
Individual Sandbox instance locations are identified with a two-letter acronym ‘CS’ followed by a number, presently up to 3 digits; ‘CS’ stands for ‘Customer Sandbox’.
You can identify your sandbox location using the following methods:
- Log into your Salesforce Sandbox instance and look in your web browser’s address bar – barring any special customizations, you’ll see something like “https://cs###.salesforce.com…”, where the “cs###” is your sandbox location
- Log into your Salesforce Production instance and perform the following steps:
-
- In Salesforce Lightning:
- In the upper-right corner, click on the little ‘gear’ icon and then click on ‘Setup’
- In Salesforce Lightning:
-
- In the upper-left corner ‘Quick Find’ box (next to magnifying glass), begin typing ‘sandbox’ and you’ll see the “Sandboxes” menu option pull-up as you type; once it does, click on it
-
-
- In Salesforce Classic:
- In the upper-right corner, click on ‘Setup’; if you don’t see ‘Setup’, click on your name drop-down arrow and you’ll see ‘Setup’ in the list
- In Salesforce Classic:
-
-
- In the upper-left ‘Quick Find/Search…’ box, begin typing ‘sandbox’ and you’ll see the “Sandboxes” menu item pop-up as you type; once it does, click on it
-
-
- Whether you’re using Lightning or Classic, you’ll see the following (sample) sandbox list.
-
- Your current sandbox ‘CS###’ instances will be listed under the “Location” column (circled in red above).
The ‘Action Required’ email Salesforce sends out will list the affected Sandbox “CS###” by their locations; both in the email’s subject line as well as throughout the email body. Salesforce will also list the date and time the migrations will be taking place…
Using your list of Sandboxes, check and see if any of your sandbox instances match the locations listed in the Salesforce email. From there, identify the date and UTC time the migration will occur, making sure to convert to your local time zone.
“Ok, I’ve ID’d my sandbox location using Salesforce’s list and have put the migration date on my schedule for my time-zone...what do I do now?”
Most every business uses some form of network and/or email security to filter external systems from interacting with their internal systems.
Filtering external systems can take many forms but one common example, and one you’re likely familiar with, would be a network firewall. The process of granting access to known/trusted systems is referred to as “whitelisting”. This essentially means adjusting your security settings to allow passage to specific, and known as safe, IP addresses and IP ranges through your network.
You can also filter by what are known as ‘domain names’; you’ve likely already done something similar, if in a far more discrete a fashion, by blocking domains with the use of spam/junk email settings.
Domain filters are more dynamic than IP or IP range filters in that they can house extended and even future content just by utilizing the domain name itself. Domain names are read by computers in a right-to-left fashion and domain filters can read ‘wild card’ asterisk (one or more of any character) characters. Thus, “*.salesforce.com” means any domain that, to computer eyes, begins with “.salesforce.com”. So, with “*.salesforce.com” in place, addresses like “cs###.salesforce.com” will work regardless of what cs number is used; this will also work for any changes to the cs number.
Essentially, if you presently have network security settings in place, and can still freely access Salesforce, then you invariably have some degree of Salesforce IPs/domains already whitelisted.
Our next step would be to confirm you are setup with the most current set of IPs, domains, etc., in use at Salesforce.
Salesforce maintains a Knowledge Article with their latest IP and domain information at the following link (also listed in the ‘Action Required’ email):
The knowledge article is very detailed and goes over all the current IP ranges and domains in use by Salesforce for a variety of network traffic, as well maintaining a history section of recent updates at the bottom of the article.
If your security settings are already up to date with the latest IP ranges and domains from Salesforce, you’re good to go for the sandbox migration. If your security settings are not up to date, you’ll need to update your internal security systems to whitelist any new and/or updated IP ranges as provided in the Salesforce Knowledge Article linked above.
Minimally, this will involve reviewing and updating, as necessary, any firewall and/or domain policies on your respective security-configured systems (firewalls, routers, domain controllers, other security components, etc.).
Once that is complete, the only other element to consider is that, to prevent data loss during the actual migration, your sandboxes will be accessible in ‘read-only’ mode for the time duration listed in the email.
“Ok, ok…it’s true, moving isn’t so bad after all…plus we found that missing TV remote!”
Additional info:
Salesforce provides a great means of checking your instance server status. Should you ever have trouble or experience latency, you can check and see if the issue is with your particular Salesforce instance. To do so, you would just go to the following links:
Main Salesforce server status site – https://trust.salesforce.com
Salesforce Instance (Production and Sandbox) status – https://status.salesforce.com
The top link houses the Salesforce Instance status link as well as a variety of other links for Marketing Cloud status, Pardot status, etc. The bottom link lists all of the customer-used Salesforce instances, including Sandboxes.
