Five Tips for Effective Salesforce® System Data Migrations
Tip #1- Fully Understand Contents of the Source System
Perform a System Scan of All Fields and Objects
Evaluate the contents of the source system to be migrated, which objects and fields are still relevant to the business, and which fields contain data that will be needed in the target system.
Watch for Special Custom Objects
There may be unique custom objects as well as objects created by installed AppExchange® Apps which contain important information. Determine if installed packages, templates or VF pages need to be reinstalled.
Migrate Only What is Needed
Data to be migrated in old systems often contains many years of sales, support and marketing history. There could be millions of support cases. Salesforce has storage limits and if you exceed your allotted storage, you could be facing significant additional costs.
Tip #2- Create Custom Fields for Critical Legacy Data
Record IDs in the Target System will be New
During a migration, records being copied from the source system will be recreated as entirely new records in the target system. This means that all new created records, users, notes, etc. will have a new unique Salesforce Record ID. Old cases will be recreated as new cases, with new case numbers and new case creation dates.
Capture Legacy Dates, Owners and IDs on Every Record
Create fields on every record type (including standard and custom objects) tasks, activities, events and note records that capture the legacy data such as legacy record owners, legacy record ID, legacy record creation date, closed date, status fields, etc.
Having records in the new target system which contain this legacy information will be helpful if users or customers need to refer to old case numbers. In addition, updating records and correcting errors will be much quicker.
Tip #3- Set up an Ongoing Synchronization vs. One-Time Cutover
Ongoing Synchronization Approach
This method of migrating data into a new Salesforce system allows a gradual load of data (movement of records) into the target system. Because completely populating the target system can take days or even weeks, an ongoing sync allows users to remain active on the source system until the data has been completely copied into the target system.
Users can then be activated in the new system and deactivated in the source system.
Ask for a Temporary API Call Increase
API calls are limited each 24-hour period. During data migration, the volume of records being loaded will often exceed the API limit slowing down or even halting migration efforts.
Implement Data Backups
Set up daily automatic backups on both the source and target systems during the migration process.
Tip #4- Evaluate the Business Processes of the Source and Target Systems
Beware of Rules, Workflows, Triggers in the Target System
Often there are active workflows that send emails and these will need to be paused during the data migration.
Evaluate the source organization’s use of Queues, Profiles, Public Groups, Chatter, Templates, Apex Triggers and Workflows. Specifically, identify whether to package or recreate them manually, but more importantly, identify if they are even still relevant. Many Orgs have dozens of obsolete Templates and Workflows.
Analyze Where Data Resides
Many fields in the source system will be populated on less than 5% of the total records. If rarely used, fields may not need to be recreated and this data will not need to be mapped.
Evaluate which installed Apps are still in use in the source system. There may be many old Apps which do not need to be re-installed in the target system.
Tip #5 Migrating Data
Cascade Inserted Data
Once the new Org is set up to receive the data, the record flow should be cascaded in the following order- Users, Accounts, Contacts, Leads, then Cases, Opportunities, Activities, attachments, etc.
Consider Field Restrictions
Data cannot be mapped to a formula field (and certain other field types) and will need to be loaded into a text field.
Many records have fields that default to value lists. Where relevant a value list will be re-created in the new Org. Check all value lists in the target system and ensure they are unrestricted.
When migrating code from a legacy Org, ensure the Apex classes have no hard-coded Org names or record IDs
User Set Up
Internal Users need to be set up first. Community Users should be set up after all data is loaded.
Community Users will need to be recreated and notified of the new community location. Change any posted public links that lead to the old community location.
Test the Migration
Appoint two or three users to begin testing. Have these users keep a running document of notes and issues.
Retain a license or two in the source (migrate) system to enable access for a period after the migration is complete.
Disclaimer:
The views and opinions expressed in this article are those of the authors. Examples cited in this article are only examples. Salesforce®, Salesforce1 Mobile App™, AppExchange® are trademarks of salesforce.com, inc.
© 2017 Edgemont CRM, LLC. All Rights Reserved - August 2017
www.edgemontcrm.com