Print this page

How to prepare for a migration to Government Cloud

Knowledge Article Number 000228273
Description

At Salesforce, customer success is our top priority. When upgrading to the Salesforce Government Cloud, our existing customers will need to migrate their production organization to one of the secure Government Cloud instances.  

Prior to performing this migration, we make every effort to ensure the migrating customer is aware and prepared. Below are some common questions we receive from customers that you may find valuable

Note: This document is for informational purposes only, and is not part of any legal or otherwise binding agreement. The policies and practices described in this document are subject to change at Salesforce's sole discretion. 

Materials

Pre-Migration Checklist (see attachment below)

This spreadsheet explains the steps you should take before the migration occurs.

Post-Migration Checklist (see attachment below)

This spreadsheet explains the steps to take once the migration has been completed.
Resolution

Table of Contents

Technical FAQs

Hard-Coded References

My Domain

Network Settings

Batch Jobs / Scheduled Jobs / Bulk API Jobs

Integrations & Certificates

Email

WSDLs

OAuth & Salesforce for Outlook

AppExchange

Search

Sandbox

Physical Delete

Read-Only Environments

Partner Portals

 
The following questions are technical in nature, and were written for the Administrator at your organization, or your IT department. We recommend that you start with our Customer Instructions, which include best practices for leveraging relative URLs in your integration and whitelisting IP addresses for all Salesforce data centers.
 

1.  What is the difference between a hard-coded reference and a relative URL?

2.  How can I find hard-coded references?

The following Customer Instructions provide in-depth details of different options of how to find hard-coded references: https://help.salesforce.com/apex/HTViewSolution?urlname=Updating-Hard-Coded-References-FAQ&language=en_US

Salesforce’s recommended best practice is to use relative URLs (e.g. login.salesforce.com) with any integration or Salesforce code, instead of hard-coding instances (na6.salesforce.com). By following this best practice, it will make it significantly easier for you to prepare for future instance migrations, one-off org migrations, or to implement My Domain functionality.  Make sure to update all hard-coded references in Knowledge articles and integration.  

3.  What if I am using the self-service portal and it is pointing to an instance URL for login?

The self service login URL: sserv/login.jsp?orgid will redirect to the correct instance based on the OrgId.   

4.  How can I make references to Visualforce pages server agnostic? For example, https://c.na1.visual.force.com/apex/MyContactPage?id={!Contact.Id} is tied to a custom button.

To make references to Visualforce pages server agnostic, run a query within your custom button to pull the URL for the result you’re looking for.

For the above example, the following will work with a custom button: {!URLFOR("../apex/MyContactPage", Contact.Id, [id=Contact.Id])}

5.  How can I search and update Knowledge Articles that reference other articles and sometimes hosted images which reference “[instance].salesforce.com” in the article content?

You will need to search and manually update the Knowledge Articles as it is not possible to find and update them with the Force.com IDE.  You can try to search through the regular API. Using workbench, perform the following SQL query:  

SELECT Id, MyField__c

FROM MyKnowledge__kav

WHERE PublishStatus = 'online' AND Language = 'en_US' AND MyText__c

LIKE '%salesforce.com%';

Note that the WHERE clause may not work for all types of fields. For instance, if you use RTA, you cannot filter on it. In this case, you need to get all the records and run a local search, or use a different filter. If you have further questions, log a case with Support.

Note that all links created through "Smart Link" functionality in the RTA editor will not be affected by a migration. While the host name displays on the page for these specific links, the host name is not actually referenced in the HREF of the underlying code. Therefore, these links will not be affected and continue to function as expected post-migration without requiring any changes.

6.  Do I need to update Email Templates that contain hard-coded references?

Yes, you will need to update Email Templates that contain hard-coded references as the migration process does not update any customer code.

7.  Do I need to update any Chatter links, browser bookmarked URLs, etc?

No, you will not need to update any Chatter links, browser bookmarked URLs, etc. Any links accessed by browsers will automatically be redirected to the new instance via our servers.

8. Will Content URL links be redirected?

Yes, Content URL links will be redirected.

9. Is there a way to automatically change hard-coded links in Chatter posts to reflect the new instance?

No, there is no way to automatically change hard-coded links in Chatter posts to reflect the new instance. Please remember though that all browser links will be redirected to the new instance.

10. Will Org IDs change as a result of the migration?

No, there will not be a change to Org IDs.

11. Will the Salesforce IDs and root-relative URLs of records be preserved?

Yes, Salesforce IDs and root-relative URLs for records will remain the same.

12. Do record IDs change at all as a result of a migration?

Existing record ids will not change after a migration.  However, new thread IDs may have a new format to reflect the new instance id.  Please do not create your own custom thread ID formats, as that is not a Salesforce supported functionality and formats may change over time.   
 

13. Do I need to change Live Agent Server endpoints (e.g. the URLs within Live Agent Chat buttons)?

If you have hard-coded references within your buttons, Salesforce will redirect them so they will work. However, we do recommend that you follow best practices and avoid the use of hard-coded references whenever possible.


My Domain

14. If I have My Domain setup, do I need to do anything in preparation of this migration?
 
This migration will be seamless to our My Domain customers, as long as you follow our best practices of whitelisting IP addresses, and you don’t have hard-coded references in your Visualforce pages.

If you have a Partner Portal, please note that instance-specific URLs won’t redirect to MyDomain URLs in Partner Portal.  In order to fix this, you will need to remove hard-coded references from your Visualforce pages and Widgets in Partner Portal before switching to My Domain.  Please see more information about this in our KB article here:
https://help.salesforce.com/apex/HTViewSolution?urlname=How-to-prepare-for-a-Split&language=en_US
 
15. Should I hold off on implementing My Domain until after the migration is complete?
 
No. My Domain implementation is required in order to migrate to Government Cloud.

Network Settings

16. Will I need to update my network settings prior to the migration window? If so, why?

Because you are moving to a new data center as part of this migration, you will need to ensure your network settings include the IP ranges of both your current data center and your new data center.  If you do not add the IP ranges of the data center you are moving to, you will block your end-users from the new instance, causing them to receive an error message after the migration is complete.

Additionally, if you or your team have set up your corporate network settings to allow only certain IP ranges, including for Email Security Filters or Email Relaying, or due to Firewalls, please ensure that you are including our newest ranges added in April 2015.  More information on which IP ranges to include can be found in the What are the Salesforce IP Addresses to whitelist? Knowledge article.
 

17.  Can I remove my old IP addresses from my set of whitelisted IP ranges after the migration is complete?
 
The best practice is to whitelist all of our data centers with the IP address ranges. There is no risk in whitelisting the specified range of IP addresses as Salesforce owns the range; it is not leased or shared in any way with any other organization. Salesforce has an IP address block allocated directly to Salesforce by the American Registry for Internet Numbers (ARIN).
 
If you still want to whitelist IP addresses for specific data centers, please ensure you include IP ranges for the data center that you are moving to, and the data center that will be used for your new instances’ disaster recovery.
 
Please note that if you remove the previous instance’s data center IP ranges, or put access restrictions to [previous instance name].salesforce.com, browser requests from static links (such as bookmarked URLs) pointing to that previous instance will not be redirected to the new instance. This is because they will not be able to reach the previous instances’ servers to be processed. Check out this Knowledge Article on Whitelisting for more information.
 
18.  Is there a way for me to test the whitelisting of IP ranges on my side?
 
Yes, you can test the whitelisting of IP ranges by trying to reach an instance that is already live in the data center you are moving to. For example, if your new instance will be located in our Midwest data center, then your test would be to call (via a ping test or API request) any instances located in the Midwest data center - EU1, NA8, NA9, CS7, CS8, CS14.
 
19. Do I need to update or make changes to my DNS after the migration?
 
Yes, if you control your DNS timeout values set, then you will need to refresh your DNS cache and restart any integration following the migration .

Batch Jobs / Scheduled Jobs / Bulk API Jobs
 

20. Do I need to take any action on our batch, scheduled, long-running transactions, or bulk API jobs prior to the migration?

No, you do not need to take any action on batch, scheduled, long-running transactions, or bulk API jobs prior to the maintenance. Salesforce will queue all jobs and process them once the migration is complete.

21.  Will there be any impact to Web-to-Leads/Cases (W2X)?

No, there will not be any impact to W2X. W2X will be queued and processed once the migration is complete.

22. Will there be any impact to Email-to-Case (E2C)?

Yes, while E2C emails are normally queued and processed once the migration is complete, our messaging server has a hard limit of holding E2C emails for 24h hours. This can become an issue if the migration exceeds 24 hours, any E2C emails older than 24 hours will be bounced.

 

For this reason it is recommended alternate means to capture E2C emails during the migration should be arranged.
The email service address will not be automatically updated to point to the new instance, but it will continue to work as we will do the redirection internally.

23. Will there be a delay in Email-to-X (e.g. Email-to-Case) or Web-to-X (e.g. Web-to-Case) after the migration?

Yes, Email-to-X and Web-to-X will be queued and then processed once the migration is complete.

24. Does the Migration impact my Weekly Exports?

Yes. If the export is in the midst of processing when the migration begins,  they will not be resumed after the migration is completed. Weekly Exports will restart at the next scheduled export after the migration.  A Weekly Export can be manually initiated to compensate for the suspended Weekly Export as long as they do not exceed the limit of one Weekly Export every six days.

 

Integrations & Certificates

Yes, you may need to restart some integration after the migration. By restarting your integration following the migration window, you would be clearing the DNS lookup cache which would cause your integration to refresh and detect the IP address of the new data center.
 
26.  Is there a way to test our integration prior to the migration in order to ensure they are set up correctly?
 
Yes. For best results, you will need to implement MyDomain on your organization prior to migration.

Also, to test your integration on Government Cloud, reach out to your account executive or success manager to request a test environment in Government Cloud. This should be completed more than 2 weeks prior to the scheduled migration.

 
27. Will this impact my CTI integration?
 
If you are using Open CTI and the CTI Adapter URL in your Call Center definition is hard-coded with your Salesforce instance (e.g. https://c.na6-visual.force.com/apex/Softphone), this will impact your CTI integration. Please change this to a relative URL (e.g. /apex/Softphone) to ensure your CTI Integration will continue to work post-migration.
 
If you are using the Salesforce Desktop CTI Integration Toolkit, this migration will not impact your CTI integration. URLs that the CTI integration directs the browser to will correctly redirect to the new instance.
 
To update this, you can navigate to the specific code path of the call center object: Setup-> Customer -> Call Centers.
 
For relative CTI Adapter URLs, or URLs pointing to non-Salesforce domains, this migration will not impact a CTI integration.
 
28. Will the CTI screen pop-up keep working after the move?
 
If you are using Open CTI and your Call Center definition is hard-coded with your Salesforce instance (e.g. https://c.na6.visual.force.com/apex/Softphone), this will impact your CTI screen pop-up. Please change this to a relative URL (e.g. /apex/Softphone) to ensure your CTI integration will continue to work post-migration.
 
If you are using the Salesforce Desktop CTI Integration Toolkit, the CTI screen pop-up will continue to work after the move. CTI does normal login calls to Salesforce much like logging into the app, and thus the redirects at the front door will take care of this.
 
For relative CTI Adapter URLs, or URLs pointing to non-Salesforce domains, the CTI screen pop-up will continue to work after the move.
 
29. If I have certificates, do I need to re-download them post-migration?

a. Yes, if you have stored the salesforce.com, my.salesforce.com, force.com, database.com, or cloudforce.com certificates locally previous to the migration.

b. No, if you have NOT stored your certificates locally.

i. Certificates and keys that are set up in the Certificates and Keys Setup within your Salesforce org will move to the new instance. No action is needed on your part to keep these certificates; they will all move to the new instance.
 

c. If you are manipulating the hostnames that the API connects to (and not using DNS hostnames), your Java implementation might cache the certificates, which would require a restart of your Java API after the move.

 
30.  Will the certificates used with the current instance at [INSTANCE].salesforce.com and [INSTANCE]-api.salesforce.com be used with the new instance?
 
Yes, the certificates used for the current instance at [INSTANCE].salesforce.com and [INSTANCE]-api.salesforce.com which are usually the cause for concern with certificate changes, will remain the same for the new instance.  Please contact Support for these customer-to-Salesforce certificates.
 
31. Will the same intermediate, root, and outbound customer-to-Salesforce certificates be used with the new instance?
 
Yes, the intermediate and root certificates will remain the same. Additionally, outbound certificates that are used for SAML, SSO, and APEX will not change.
 
32. Will this migration impact SSO?
 
No, this migration should not impact SSO. If your Org is not moving to a new data center, then nothing will change.  If your Org is moving to a new data center, then the originating IP address will change to the new data center’s' outbound proxy. The outbound SSO cert that customers use for SSO or APEX SSL authentication will not change.  ​ 

Email

33. Do I need to make any changes to the IP addresses for mail relay?

Please review your email server IP ranges and mail relay IP addresses to ensure they are updated per this What salesforce.com network IP ranges do I need to whitelist? Knowledge Article. 
 

 34. Do I need to make any changes to my Sender Policy Framework (SPF) records?

It depends on how you have your SPF setup. We recommend enabling the “Enable compliance with standard email security mechanisms” option, but in the unlikely case where you have specific Salesforce IP addresses listed in your SPF, you will need to change them, or include our SPF records that cover all IP ranges.
 

35. Will the Apex Email Services (e.g. InboundEmailHandler) address continue to work after the migration?

The address will continue to work as Salesforce will redirect the mail internally to the org's new instance. You may regenerate the email address to avoid unnecessary redirection if you’d like, but it’s not necessary. 
 

36. Will the EmailService Address change post-migration?

No, the EmailService Address will not change post-migration.

 

WSDLs

NOTE: Generic server endpoints such as login.salesforce.com and test.salesforce.com are not supported in Government Cloud. Best practice is to configure all endpoints to use your organization's My Domain URL (e.g. <mydomain>.my.salesforce.com)

See: Using WSDLs in the Salesforce Government Cloud

37. What actions do I need to take for any Apex Web Services Generated WSDLs?

​For any Apex Web Services Generated WSDLs, you need to modify the WSDL to point to the new instance, or you will need to regenerate the WSDL after the move to the new instance. You can regenerate the WSDL before the migration if you’d prefer, but you cannot implement it until the migration has taken place.  

38. Is there a way to rewrite these WSDLs now so they are unbreakable and do not have to change before/after the migration?

Yes. If the org has MyDomain enabled, the endpoint specified in the Apex WSDL points to the MyDomain host name (xxx.my.salesforce.com), which will not change after the migration.

39. Does a partner WSDL need to be regenerated after the move?

The Partner WSDL will need to be manually edited to have the endpoint defined as a the MyDomain URL (e.g. 'xxx.my.salesforce.com'). To verify this, you can download the Partner WSDL from the org SETUP > DEVELOP > API menu, open up the XML, and search through to see if there are any generic or instance-specific. If there are, manually update the WSDL before using it.

See: Using WSDLs in the Salesforce Government Cloud

OAuth & Salesforce for Outlook

40. Will OAuth refresh tokens be affected by this migration?

If you have OAuth refresh tokens, they will not be impacted after the migration - with the exception of Salesforce for Outlook (SFO).  All versions of SFO will be required to login again. Follow the steps in the "Salesforce for Outlook OAuth re authentication" to ensure post-migration users will be prompted to login again to the SFO plugin and any connectivity issues post-migration are resolved.

AppExchange

41. Will installed apps from the AppExchange be impacted by this change?

No, we work with our ISV partners to ensure they don’t have any hard-coded URLs in their AppExchange apps. Additionally, many ISV partners follow our best practices to not hard-code specific instances in their integrations or code.  
 

42. Can new packages from the AppExchange be installed?

Yes. Packages that are searchable directly through the Salesforce AppExchange may be installed on Government Cloud organizations.
 

See Also: Packaging and AppExchange Considerations for Government Cloud

Search

43. Will there be any impact to Search after the migration is complete?

No, Search will not be impacted after the migration is complete.  

Sandbox
 

44. Do I need to make any changes to my Sandbox before or after the migration?

No, as long as you don’t have any hard-coded references to your current production instance in your Sandbox, no changes are required to your Sandbox environment before or after the migration. If you have hard-coded references to your production instance in your Sandbox, please check out our Hard-Coded References section for details on how to update them. 

 

See Also: 

45. Should I refresh my Sandbox once the migration is complete?

The migration to Government Cloud causes you to move to a new data center. We recommend that you refresh your Sandbox after the migration is complete. 
 

46. Can I get an up-to-date Sandbox refresh before the migration begins?

No, we cannot guarantee that you can get an up-to-date Sandbox refresh before the migration begins. We cannot predict how long a Sandbox refresh will take, so if you request a refresh of your Sandbox prior to the migration, and it does not finish in time, it will either resume once the migration is complete, or if you’re moving instances, restart the refresh request once the migrationis complete. Please evaluate how long your previous Sandbox refreshes have taken, and plan accordingly.  

47. What happens to my Sandbox if it is in the middle of a refresh when the migration occurs?

If your org was migrated while you were in the midst of a Sandbox refresh, the Sandbox copy will be interrupted and may need to be manually restarted by Salesforce support after the migration is complete.

As a best practice, it is recommended that you wait until after the migration for any needed sandbox refreshes.

 

Physical Delete 

48.  How is physical delete impacted by a migration?
Physical Delete will be suspended on the org for the duration of the migration window and will resume automatically sometime after the migration completes.

Read-Only Environments

49. Does Salesforce offer read-only environments for 24/7 customers who need access to the Salesforce application at all times?

Yes, Read-Only mode may be available for a portion of your migration. You can read more about Read-Only mode here: https://help.salesforce.com/apex/HTViewSolution?urlname=Read-Only-Mode-Overview&language=en_US.  

 

Partner Portals

50.  Can I control what my end users will see when trying to access my partner portal or community during the migration window?  
a.  It depends on several factors. The matrix below describes what to expect for each site type based on whether the domain supports https and whether a custom service-not-available (SNA) page has been set up on the site.
Site Type
HTTP-Only Domain, No SNA
HTTP-Only Domain, SNA Set
HTTPS Domain, No SNA
HTTPS Domain, SNA Set
Salesforce Site.com Communities
Generic service is unavailable page
Generic service is unavailable page
Generic service is unavailable page
Generic service is unavailable page
Salesforce Force.com Communities
Generic service is unavailable page
N/A
Generic service is unavailable page

N/A

Force.com Sites (non-Community)
Generic service is unavailable page
Custom SNA page
Blank page or connection error message
Blank page or connection error message
Site.com (non-Community)
Site is rendered while showing the error view for repeaters and forms
Site is always available
Site is rendered while showing the error view for repeaters and forms
Site is always available
b. Yes. If you are using a Force.com site on a http-only domain or a Salesforce Community on a custom https domain, assign a migration or error page for anyone trying to access your partner portal or community during the migration via the following link: https://help.salesforce.com/HTViewHelpDoc?id=sites_error_pages.htm&language=en_US . Please note that in a Force.com site that is not a Salesforce Community, this page is presently shown only on http-only domains and not on https domains. In a Salesforce Community, this page is shown only on custom https domains and not on the force.com subdomain.
c. If you are using Site.com, it will remain online during the
migration, though repeaters and forms, which are unique to Site.com, will show errors instead of presenting the repeater data and form data.
d. Any site or domain that can't have a service-not-available page configured from the criteria above will display a browser-specific error message after a timeout period elapses.
e. Any Force.com site that is not a Salesforce Community and does not have a service-not-available page configured will display a page that looks like the following on its http-only domains:

User-added image

f. If you are accessing your secure.force.com subdomain via https, you will get a browser-specific error message after a timeout.
g. If you attempt to access Salesforce Communities, you will receive a browser-specific error message after timeout.

 





promote demote