7

For legal reasons we have to clone a salesforce production org (i.e. migrate entire org to a new one - recreate all the standard and custom metadata, data, managed packages, users, integrations etc)

  • What are the steps to follow?
  • How to perform the analysis?
  • In which order must be deployed metadata?
  • What must be created manually?
  • Are there tools that are better than the salesforce migration tool ?
  • How to test and validate the migration?


I'm going to use the salesforce migration tool, but some metadata are not supported, for example standard object picklist values.

8

Some principles/tips

Do not allow for new development in the old org during the migration unless critically needed. Establish a policy for communicating changes in the old org.

Before the migration - Make sure that the minimum test coverage is reached for every single Apex class and there are no @SeeAllData annotations (this could be a separate project). Otherwise, the coverage will not pass and you simply won't be able to deploy ApexCode into Prod with all dependent metadata (custom buttons, layouts etc).

Migrate everything. Data cleaning, Metadata cleaning, Unused fields removal - all this is a different project and must be performed before or after but not together with migration! A missing profile or a field or an installed package will have a huge impact on the speed of migration.

Prepare to resolve a lot of conflicts. Field references, User references, missing metadata, missing data..

Plan to spend time fixing hardcoded ids in Workflows, Classes, Validation Rules and Formula Fields after the metadata and data migration is performed. It can be a Record id, RecordType id, CustomField id etc.

Migrate all the installed packages using Force.com migration tool. Don’t worry about trial versions. When trial expires metadata won’t be deleted. For tests trial period is negotiable with package vendors. Double Check you will migrate packages referenced in code. Client team may have no knowledge about installed packages that facilitate background technical processes and may not be able to specify all the packages necessary to migrate. In case of no time to investigate references insist on migrating all of the packages anyway. Those that are not needed will expire their trial period silently without causing any problems later.

Engage client as much as possible. Delegate some tasks to someone on client side if possible (org wide email address confirmation, manual declarative tasks). Make them prepare test cases (at least the critical points) and then perform those tests.

Plan a lot of time for testing use cases and fixing to reach expected behaviour (substituting hardcoded ids, making apex tests pass).

Align carefully features that are enabled in the old org (e.g. Territory Management, Forecasting) and work with salesforce support in order to enable or disable features in the new org in order to make it as equal as possible to the old one. Again - If the client wants to change their feature set - this should be addressed as a separate project before or after the migration. Some features may not available in the new org like Site.com! Some user license types may not be available in the new org - create a mapping in order to migrate all the profiles.

When using Force.com migration tool to migrate metadata:

  • for each metadata type deployment use git to track what metadata was changed/removed from original one in order resolve deployment errors and specify deployment errors in commit messages.
  • Prefer a lot of small deployments. one metadata type at a time vs large one
  • Just to remind. In order to migrate Profile settings you need to include other metadata in retrieve call: CustomObject, CustomField, RecordType, Layout,Apps,Tabs
  • In order to migrate translations you need to include other metadata in retrieve call: CustomApplication, CustomLabels, CustomPageWebLink, CustomTab, CustomObject

Don’t deploy restrictive metadata to production before finishing data migration. You can deploy it first to a sandbox to perform tests. ValidationRule, Workflow, Trigger, ProcessBuilder Flow, AssignmentRule, AutoResponseRule, DuplicateRule

Before migrating reports and dashboards ask users to move their private reports to some public folder if they need to use them in the new Prod.

Tech tips

Tools for migration

approximate order of metadata to migrate

  • org wide email addresses
  • installed packages
  • Profiles (name and license, standard permissions) and users
  • Unsupported Metadata Types (manually), translation workbench settings, Chatter settings, territory management, salesforce knowledge settings etc.
  • Data model: Custom objects (without validation rules), record types, List views
  • Profiles (Object CRUD settings, FLS settings, RecordType visibility)
  • Sharing rules and settings
  • Permission Sets, Permission Set assignment
  • roles, groups
  • StaticResources, Documents, CustomLabels, BusinessProcess, Certificate,CorsWhitelistOrigin,CustomPermission,FieldSet,Letterhead,MatchingRules,Queue,RemoteSiteSetting, other Settings
  • ApexCode (Classes,Pages,Components) (+profile access settings)
  • Metadata dependent on classes - Layout (+profile and record type layout assignment), WebLink, ObjectActions
  • Email Templates
  • Apps,Tabs (+profile visibility)
  • Enable Communities, migrate profile settings for Guest Site user and community user profile, enable necessary Apex classes and pages
  • Restrictive metadata (ValidationRule, Workflow, Trigger, ProcessBuilder Flow, AssignmentRule, AutoResponseRule, DuplicateRule)
  • Analytic snapshot (I couldn't deploy it automatically per salesforce issue and workaround didn't help in my case)
  • schedule batch apex
1

When I have done large migrations in the past I used a combination of the Salesforce Toolkit : http://packagebuilder.herokuapp.com/ and the Workbench : https://workbench.developerforce.com/login.php to get the job done. First I would use the Salesforce Toolkit to get the package.xml. I then would use the Workbench to export all the metadata. I then would use the workbench while logged into the other org and import the metadata.

That's at least how I would go about migrating a large amount of metadata. Keep in mind that these are third party tools not official Salesforce tools.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.