INTRODUCTION
Goal is to outline migration strategies, issues and implications in any Data Migration Project.
DATA MIGRATION CONSIDERATION
Before Migration
- While giving a migration estimate, always consider – on how many sandboxes migration will take place. Also migration will be done on sandboxes just for a set of records or full?
- Analyze resources|tools (Data loader, Batch, ETL, access to source and target system etc) required for migration and ask for it upfront. Unavailability of any tool may impact estimates and timeline heavily.
- Volume of data must be known before providing timeline and estimate.
- Identify the fields to be migrated and let the field mapping get confirmed with stakeholders. If you miss even a single field, it may cause re-doing of everything or updating all records.
- Audit Fields: Research and prepare the list of audit fields (CreatedDate, Last Modified Date, CreatedById, CreatedByDate, CloseDate etc). Here is a Salesforce help article for the same: https://help.salesforce.com/articleView?id=000331038&type=1&mode=1
- Do check the licenses before User migration – Feature License like Service Cloud User, Chat User, Knowledge User OR external user license.
- Maintain ExternalId: Create an ‘External Id’ field to track the external primary key of each record being migrated. Keep it unique and External in field definition.
- It’s worth brainstorming to identify the limitations (Governor Limits, Org Data Storage Limit) of migration like:
- Field Length/Size match – for example if source org has a ‘Field’ having more characters than related field in Salesforce.
- We have faced issues while migrating Case Description, Case Comment, Chatter Post etc
- API limit of data migration. For example, the maximum number of content versions that can be published in a 24-hour period is 5,000.
- Storage Limit: if any object is going to consume a lot of storage, flag it with stakeholders as Salesforce is not a data storage place and can cause huge price and performance issues.
- Field Length/Size match – for example if source org has a ‘Field’ having more characters than related field in Salesforce.
- Date field’s timezone consideration if the dev team is in a different timezone.
- Best is to use ETL tools (Dataloader, Dataloader.io, Dell Boomi, Talend etc) instead of using manual or code based approach (batch). However, if there is no workaround, it’s ok to use code.
- Do create a strong strategy for delta migration (data created in existing system during migration window)
During migration
- Keep email deliverability off.
- While moving Persons (User, Lead, Contact), make sure you invalidate the email in Sandboxes.
- If possible, deactivate the email alerts.
- Identify triggers|Flow|Process Builders which are not required to run on these records being migrated and turn them off to increase the speed.
- Keep track of failed records otherwise you may lose some records in between.
- Rich Text Area or HTML Supported Field: Keep here special attention:
- Any images hosted on an existing system must be migrated to Salesforce and then the link of the image source must be updated in rich text.
- Find out inline links and replace them with new endpoint links otherwise users will get redirected to the older system when they click on the link.
- Import fields of existing system into custom fields you are unsure about. Sometimes Stakeholders ask for it though they have not asked in original requirement.
After migration
- Do a sanity check on some records for each object.
- Pull some reports over migrated data and share with stakeholders to verify and approve it.
- New records due to migration may have triggered scheduled jobs or time based job, don’t forget to visit there and deleted these jobs
- Timebased Workflow
- Scheduled Apex
- Paused and waiting interview flows