Org Split Considerations

The Basics

To start with the basics, all organizations (orgs) are on what Salesforce call pods (or instances). To know what pod you’re org is on, take a look at the Salesforce url. It will start with an ‘na’ for production and a number. In this image, this org is on the pod ‘na15’.

Another really cool tool Salesforce offers is the ability to see what’s going on with your pod at any given time. By going to trust.salesforce.com and clicking on ‘Check System Status’ you can see how your pod has been running for up to the last 30 days. You can also find out about schedule maintenance, security, and a host of other great ‘behind the curtain’ information related to your Salesforce org.

Split Notification

Recently Salesforce sent out an email notification for all organizations on the na11 pod (you may have been one of those recipients). They monitor the growth and performance of these pods on a regular basis. When it’s determined it has reached near threshold for capacity,  Salesforce needs to perform a ‘split’. Factors they consider are; capacity of the overall instance, CPU size, storage size, number of transactions and licenses, and projected growth.  Some organizations stay on the current pod, some are moved to a new pod.  The email you receive will clarify what’s happening to your org.

The actual split (or migration) takes place during standard maintenance windows which are usually on off-peak business hours.  These windows may be extended a bit given the complexity of the migration, and, it’s important to know that your org WILL NOT be available during this time.

What do I need to do if I’m staying on the current Instance?

No action is required, you just need to know your Salesforce org will be unavailable during the maintenance window which will be emailed to you at least 3 months prior.

What do I need to do if I’m moving to the new instance?

Salesforce highly recommends you follow best practices for using relative URL’s vs hard-coded references. The difference is that a hard-coded reference has the naxx.salesforce.com at the beginning of the url whereas relative URL’s don’t contain this part. For example; “https://naX.salesforce.com/servlet/servlet.FileDownload?file=01560000000BRIM” (hard coded) vs “/servlet/servlet.FileDownload?file=01560000000BRIM” (relative). How can you find if you have hard-coded references you ask? Check out the details in this Knowledge article, How to find hard-coded references using the Force.com IDE.

It’s also recommended to do the following:

• Review all custom links to confirm you use relative URL references
• Review any integration that uses the Force.com web services API to verify there are no hard-coded references to [instance].salesforce.com
• Review any customer and/or partner portal setup for hard-coded references to [instance].salesforce.com
• Continue to follow best practices and whitelist IP address ranges from all of our data centers. Go to the ‘What are the Salesforce IP Addresses to whitelist’  Knowledge Article

Other Impacts?

• Org ID - There will be no change to your Org ID after migration to the new instance.
• My Domain - The split will be seamless to all My Domain customers as long as you follow best practices for whitelisting IP Addresses and have no hard-code references.
• Sandboxes - There is no impact on your sandboxes if you don’t have any hard-coded url references. It is also recommended you refresh your Sandbox after migration is done. 
• Batch Jobs, Scheduled Job, Bulk API Jobs - There is no impact on these, Salesforce will queue up your jobs and process them once the migration is done. 
• Web to Lead/Case - There is no impact 
• Email to Case - Salesforce only holds these for 24 hours, if the maintenance window takes longer than 24 hours these emails may bounce. They recommend alternate means of capturing these during the maintenance window. 
• Email Templates - You would need to update any email template that has a hard-coded url. 
• Chatter Links or Browser Bookmarks - No need to update these. 
• Apps from the AppExchange Installed - No impact, all ISV partner adhere to best practices regarding hard-coded URLs.

For those moving to a new instance, here are a few detailed Knowledge articles on how to prepare for a split and how to prepare for migration.  There’s some overlap in information between these two articles but worth reviewing both.  They also contain checklists for pre-split and post-split that would be beneficial to utilize. It’s good to walk through these to ensure you’re ready for the split. Salesforce is also readily available to answer any specific questions you may have, reach out to them by submitting a support case.

Do you have your own recommendations for getting ready for an instance split? Please feel free to comment below, on our Facebook page, or directly at me on Twitter @LeiferAshley or in the Success Community.