It’s not super common to abandon a Salesforce org and start fresh in a new Salesforce org, but it’s certainly not out of the realm of possibility. Salesforce has been around for quite some time now, and oftentimes orgs can get overly customized, for e.g. apex lines of code, governor limits, fields that are no longer used, AppExchange apps that have expired, etc. It’s like an old car where the maintenance costs are too much, so you might as well get a new car.

Or it could also be that the client wants to use some industry-focused packages like Financial Services Cloud or Manufacturing cloud that are better off to start in a new org. But there are functionalities that you cannot part ways with like the self-service partner community that your partners are used to and also saves tons of support costs to your company. Another reason why such a migration would be necessary is in the case of when companies spin off from their parent company and they want to stand up their own Salesforce instance which includes standing up of Experience cloud as well.

So, in such cases, you’d need to understand what the Experience Cloud migration effort is going to look like.

In this article, I will focus on Experience Cloud migration from one Salesforce instance to another. I frequently hear “lift and shift” and I cringe at that as nothing ever is that simple even with the most simple of Experience Clouds and I will explain why!

 

Analyze

Everything starts with analysis – do a current state analysis sitting down with business stakeholders. Let them hold your hand and guide you through how the current Experience Cloud is being used. Factor time for such a guided walkthrough and ask them questions about what’s used and what’s not used. Next, document all the information and share your findings with the stakeholder to validate your understanding. Maybe out of the ten features that Experience Cloud is being used for today, only five need to be moved over and the rest of the features are not being used. So, categorize features into must-haves, nice-to-haves, and discard-pile. Also, use this as an opportunity to analyze which customizations need to be retired because of some of the out-of-the-box capabilities that Salesforce adds to every release. These are important factors in migration efforts.

 

Create Inventory

Now that you know what to bring over and what not, you can start creating an inventory of the items that need to be moved over. Your inventory will be categorized into things that need to move as is and things that need to be built using some out-of-the-box capabilities. For the category of items that fall into “things that need to move”, a top-down approach would be better because it will uncover some of the dependencies. For this approach, creating an unmanaged package will uncover these dependencies, although security is something that is still a manual step. For example, if you need a lightning web component in the new org (LWC), here are all the things that go along with it:

1. The LWC itself

2. Apex classes that the LWC uses. Test class that this apex class uses.

3. Objects and fields referenced in the LWC

4. Custom labels referenced in the LWC

5. Security: sharing sets, sharing rules, groups, profiles, Org Wide Defaults (OWD) etc. Note that this will still be a manual effort.

You can do a similar exercise for flow-related dependencies, actions, etc. Note that some items may not have such deep dependencies but still need to exist in the target Experience Cloud such as objects and fields. Let’s say you have a support community and you are using out-of-the-box page layouts specific to your community profiles and custom fields, these need to be migrated as well. So, pay attention to items like these as well and factor this in your migration efforts. For this specific example, you’d need to create object pages in the community, make sure that the right page layout assignments for the profiles, field level security for fields on those pages, and ensure profiles have the right access to objects.

 

Start Planning the Move

Once you have uncovered all the required metadata to move to the target org, start with standing up Experience Cloud in the target org. This can be done in parallel while the packages are getting ready. There is no reason to hold this hostage to the completion of the package build. So, start doing the base set-up of your Experience Cloud and when the packages have moved over, you are ready to start putting the puzzle together.

Another consideration is the movement of users and data which is not really a focus of this article. But I do want to emphasize that you must have a cutover plan. Your cut-over plan should include data migration – you don’t want your customer support to be inundated with new requests about “Oh! What happened to the case that support agent XYZ is helping me on?” So, have a solid data migration plan on how far back you want to go and things that are in flight like open cases, open opportunities with partners, knowledge articles, etc. Communicate often and early with your internal and external users about what they should expect and when exactly the switch is happening.

 

Test

I cannot emphasize enough how important testing will be to all this effort to make sure you haven’t missed any core functionalities.

I hope this provides a framework to better understand what entails moving Experience Cloud from an old org to a new org.