Salesforce is a cloud-based CRM software that has been setting new milestones with every passing year. Last year alone, Salesforce grew its sales by an impressive 21.1% while the entire CRM market itself grew by an average 12.3%.
The company has been growing at such a pace that its original server capacity has already become insufficient to host current client demands. Naturally, Salesforce has been working to increase its server capacity to keep up with the demand.
In May 2016, the company had chosen AWS as the preferred public cloud infrastructure provider. With that, many of Salesforce’s core cloud-based apps like Sales Cloud, App Cloud, Service Cloud, Analytics Cloud, etc. were moved to the new data houses.
Salesforce has also been moving some companies to the new data servers for providing continuous service. In other news, the company has already started prompting for a server switch to shift server instances to the new server. The server switch typically takes two to four hours and requires some prior preparation to avoid any mishaps. Developers, admins, and users need to be kept in the loop of the server switch to resume operations easily after the switching process is complete.
Featured Whitepaper
Be informed that when the server switch is happening, the direct URL for that server instance might change. Other issues are also bound to crop up if you do not follow the best practices as suggested by Salesforce. Hard-coded references may have to be tweaked and re-established to resume access after the server switch. Several other critical aspects are also to be notified to stakeholders for a smooth transition to the new server environment.
In this post, we are going to share four critical steps that you need to follow for a hassle-free Salesforce server switch.
The four critical steps are listed as below:
Step 1: Give prior intimation to stakeholders and user groups
Step 2: Identify hard-coded areas where the server reference is to be updated
Step 3: Direct URL references to dynamic URLs wherever possible
Step 4: Schedule the server switch
Step 1: Give prior intimation to stakeholders and user groups
When the Salesforce server switch is initiated, too many changes will happen in the backend that will have a direct impact on the way how stakeholders use the platform. The first notable change would be the platform becoming accessible only in read-only mode.
Secondly, the login page link would also change permanently. Users who had bookmarked the Salesforce homepage will now have to head to login.Salesforce.com page for logging in. However, the login would fail despite giving the right username and password input.
To avoid these issues and to make troubleshooting easier, IT administrators should give prior intimation to stakeholders and user groups of the scheduled server switch. The new login page should also be informed so that users can bookmark it for future use.
Step 2: Identify hard-coded references
A hard-coded reference is a URL where the instance name is included instead of generic instance names that Salesforce generates.
For example, a hard-coded URL is: https://na9.salesforce.com; whereas a generic URL is sfdc.my.salesforce.com or any other generic characters in place of ‘sfdc’.
Before initiating the server switch process, it is essential that you run a thorough check and find out instances that are hard-coded. Typically email templates, buttons within each object, Apex classes, browser links, chatter posts, S-controls, workflows, etc. have a high probability of having hard-codes.
You can use a free tool like Eclipse or Salesforce’s own Lightning Readiness Assessor Tool to find hard-coded references and link them to the new server’s URL.
Step 3: Direct URL references to dynamic URLs wherever possible
Once the hard-coded references are taken care of, remove all actual server references. Instead of the actual server references, dynamic URL references should be given wherever possible. This will help prevent any issues in logging in or accessing the portal post server switch.
Developers must be able to make necessary changes in the Apex code and Visualforce areas, while admins can take care of email templates, workflows, buttons, and so on. Above all, ensure that all the changes are made in a lower sandbox so that any errors are not carried forward in actual deployment. Also, do a thorough UAT to spot any errors that could have accidentally crept in. After tying up all the loose ends, proceed to the server switch over.
Step 4: Switch Over To New Salesforce Server
The server switch should ideally be scheduled during a period when the server usage is lean. This could be weekends or at night when the requests are bare minimum. If you are running a team that accesses server data round the clock, inform them that the data will be available on read-only mode during the server switch.
Before making the switch over, look for all admin and developer areas where URLs have not been transitioned to the new server URL. Also, ensure that all hard-coded references are re-established with references to dynamic URLs.
Salesforce Server Switching is a delicate process. The stakeholders who use the server need to be informed of the changes in existing processes prior to the switch to avoid pitfalls. Developers and admins must take necessary steps to re-establish references for the old server references so that users can continue to use the platform with ease.
Whitepaper