During an org migration, your org moves from one instance to another. If you follow our best practices, this maintenance should be seamless. Below are some frequently asked questions regarding org migrations. Pre & Post org migration checklists attached.
Frequently Asked Questions
What actions do I need to take to prepare for an org migration? What will happen if I don’t follow Salesforce Infrastructure Best Practices?
If you are not following our best practices outlined on the Plan and Prepare for Org Maintenance and Releases site, your end users may not be able to access Salesforce after the maintenance is complete.
In order to avoid unintended service disruptions, you may need to take the following actions:
i. Enabling My Domain (NOTE: My Domain is required for customers that have requested the org migration.), and if you have any hard-coded references (for example, na1.salesforce.com) make sure that you update them to relative URLs (for example, login.salesforce.com or your My Domain subdomain) prior to the org migration.
Will an org migration impact Live Agent?
It's possible. During an org migration, your org’s instance name changes. 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, How to update your Live Agent custom client when your org instance changes article. 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.
Frequently Asked Questions
What actions do I need to take to prepare for an org migration? What will happen if I don’t follow Salesforce Infrastructure Best Practices?
If you are not following our best practices outlined on the Plan and Prepare for Org Maintenance and Releases site, your end users may not be able to access Salesforce after the maintenance is complete.
In order to avoid unintended service disruptions, you may need to take the following actions:
i. Enabling My Domain (NOTE: My Domain is required for customers that have requested the org migration.), and if you have any hard-coded references (for example, na1.salesforce.com) make sure that you update them to relative URLs (for example, login.salesforce.com or your My Domain subdomain) prior to the org migration.
Will an org migration impact Live Agent?
It's possible. During an org migration, your org’s instance name changes. 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, How to update your Live Agent custom client when your org instance changes article. 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.