Data Migration Template for Engineering Teams

Small migrations (under 100K records, simple schemas) take 2-4 weeks including planning and validation. Medium migrations (millions of records, complex relationships) take 6-12 weeks. Large platform migrations with custom objects and integrations take 3-6 months. The migration code itself runs in hours or days. Planning, mapping, testing, and validation are what take weeks.

Phased migrations are safer for most teams. Migrate one entity type at a time, validate it, then move to the next. Big bang cutovers (everything at once) are faster but riskier because a single failure can block the entire migration and force a full rollback. Use big bang only when entities are so tightly coupled that phased migration would create inconsistencies. The [risk assessment matrix](/frameworks/rice-framework) can help evaluate which approach fits your situation.

Three options: create a custom field in the destination system, store the data in a notes or metadata field, or intentionally drop it. Document the decision for every orphaned field in your mapping document. Never silently drop data. If a field is not migrated, the mapping should show "Not migrated" with a reason (e.g. "field deprecated, no business use in past 12 months").

Silent data loss. The migration runs, record counts match, but specific field values are wrong because a transformation rule had a bug. This is why field-level spot checks matter. Comparing record counts alone is not enough. Randomly sample records and verify that key business fields (revenue, status, dates, relationships) match between source and destination.

During the parallel run period, changes in the source system must propagate to the destination. Options: manual re-sync at cutover, automated bidirectional sync via middleware (Workato, Zapier, custom), or a hard cutover date where teams stop using the source. Bidirectional sync is complex and error-prone. Most teams choose a short parallel run (1-2 weeks) followed by a hard cutover. ---