Usually Data Migration is very crucial for any organization and apart from this if you are doing an ORG Consolidation then the complexity increases by 100 times. Org Consolidation + Data migration cannot be done in a span of 1 or 2 months. This requires a detailed analysis of both Source and Target org and a plan to execute to make this a successful.
If you are doing this activity then I will strongly suggest divide this activity into phases. Discuss with customers what they need on priority and prepare a plan about each phases what and why it is considered in the respective phases.
Take a look on this beautiful document listing best practices for Consolidating Multiple Salesforce Orgs:
Below are few Key considerations for Org Consolidation:
- Identify which Org will act as a source and target?
- Will there be any impact on OWD?
- How many more full/feature licenses required?
- How much more Data and file storage needed?
- How many more roles will get created? (Default Limit is 500)
- What are all the profiles required ‘View All’ and ‘Modify All’ Permission?
- Do you require new record types?
- List all the objects which needs to migrated and which will not be migrated.
- Do you require to enable Multi-Currency? If YES then
- Identify which currency will act as corporate currency?
- What will be the dated exchange rate for OLD records?
- Will there be any impact on existing records on target Org?
- Will there be any impact on Reports/Dashboard and formula, currency fields?
- Do you required to update the currency locale for the existing and new users?
- Do we need to enable the translation workbench?
- Any modification on Standard fields?
- Do you require communities? If yes, then
- Identify whether target is already enabled with community or not?
- Will there be any impact on community URL, if source is also having community?
- Are there any static resources referred in Community?
- Will there be any modification needed on search layout, List Views?
- How many more custom objects and fields needed?
- How many more tabs need to be created?
- Are there any standard fields and object field’s labels overridden?
- What is the sequence of components to be migrated?
- Will there be any impact on triggers, apex classes and visualforce pages ?
- Will there be any impact on existing/new validation rules, WF Rules etc.,?
- Do you require to override any standard tabs ?
- How the field history data will be migrated ?
- Will there be any impact on existing and new reports/dashboard?
- If the content management is enabled, then how and what is the sequence of data to be migrated?
- What are all the Pre and Post Deployment activities to be performed before and after metadata migration?
- Finally – Identifying the tool for metadata migration? (Eclipse IDE or ANT Tool,.. )
Once metadata migration is successful then another big challenge is for Data Migration.
- Plan the window on which you will be performing Data migration (generally put this over weekend)
- Plan the sequence of objects on which you will be performing data load.
- Create an extra legacy field to capture the source system record id
- If data is HUGH, then divide the data into multiple chunks which business needs on priority like the Open Opportunities then load the data.
- Updating the system audit fields (For this, earlier we used to raise a SF case, but now SF has given that control to us only). For this you need to enable at ORG level as well as at profile level (I will explain this in my next blog)
- List all the lookup filters if any as this will give error during data migration if it is not matching the filter criteria.
- Deactivate all the Triggers, workflows, validation rules etc., before start of data migration. Best Practice – Control the execution of trigger, validation rule from a custom setting (Will explain the Custom Setting of Hierarchy type in my next blog to control this).
Do comment your queries. I will be happy to help you out.