Step 1:- Working
on Source
- Define
the scope of migration i.e. which objects and fields needs be migrated.
For ex. not all objects, field and records needs to be in target system.
for ex. we may need data of only past 2 years
- Check
the ER of source data and find master detail /
parent child relationships
- For
auditing purpose we should take full backup but it should be different
from migration backup
- Take
the down time and sure no one can modify data while we are performing
migration.
Step 2:- Working on
staging DB
- Perform
all data clean up in staging DB
- If
any calculations/data massaging needs to be done, then that should also be
done in staging. It will remove the load on target system when you load
data in bulk.
- Use
VLOOKUP to maintain referential integrity
- Security of data
- Duration of backup process - data may chnaged while running backup process.
Step 3:- Test data load
in Full Copy Sandbox
- We
should test data load in sandbox environment.
- Disable
all unnecessary activities i.e. triggers, validation rules, workflow,
assignment rules
- Make
sure minimum to sharing calculations are happening
- Decide
which API suites you best i.e SOAP, Bulk with serial mode, Bulk with
parallel mode
- Arrange
data in a way to reduce locking at target system
- We
will need to create external id fields in target system to preserve the
relation ships.
- Prepare
check list / To do list based on challenges you face that you can use for
actual data migration in production.
Step 4:- Actual data
load
- We
will get lot of learning while testing in sandbox. We need to apply all
that in production follow the check list.
- Run
reports and queries to check the statistic make sure they match
- Do
some sample checks
- Enable triggers,
validation rules, workflow, assignment rules
- Update
sharing model to meet your business needs and recalculate sharing
- After migration run both
system in parallel. Don’t immediately discard source system. Keep a limited access to source system
