Plan every phase of a data migration — discovery, ETL build, UAT, cutover, and rollback — with a Gantt chart that tracks quality gates and decision points.
Data migrations fail in predictable ways. The project starts on time, the ETL scripts look good in development, and then UAT reveals that 14% of legacy records have malformed phone numbers, duplicate contact IDs, and null values in required fields. The cutover weekend that was supposed to take 8 hours stretches to 36. The rollback plan that nobody tested doesn't work.
A Gantt chart for a data migration project prevents these failures not by adding process, but by forcing the team to think through every decision point before the migration starts — when changing the plan is cheap, not during a cutover weekend when the business is offline.
This guide covers how to structure a data migration Gantt chart from discovery through post-migration stabilization, with specific phases, realistic durations, and the dependency chains most teams miss.
Most data migrations are managed through spreadsheet checklists or project management tools that track tasks without showing time dependencies. The result: the ETL build starts before the data mapping is complete, UAT begins before test data is anonymized, and the cutover plan is written during the cutover weekend itself.
A Gantt chart makes three things visible that checklists hide:
Dependency chains. The data quality report cannot start until the source system audit is complete. The destination system configuration cannot start until the field mapping is approved. The UAT environment cannot be built until the ETL scripts have passed initial QA. Each of these dependencies has a cost: a blocked task means a delayed milestone.
The critical path. In most data migrations, the critical path runs through data quality remediation — not ETL development. Identifying data quality issues in week 2 instead of week 8 saves the project. The Gantt chart makes the critical path visible so the team invests discovery effort where it matters most.
Cutover math. The cutover weekend has a hard deadline: business opens Monday morning. Working backward from that deadline through delta migration, validation, smoke testing, and go/no-go decision reveals exactly how much time each step has — and whether the plan is realistic.
Every data migration starts with a source system audit. This phase is routinely underestimated and is the single most common reason migrations run late.
Source system documentation review (1–2 weeks)
Collect every data dictionary, schema document, and ERD that exists for the source system. In legacy systems — older CRMs, on-premise ERP systems, custom databases — this documentation is often outdated or missing entirely. The actual schema must be reverse-engineered from the live database.
Run row counts on every table. Count nulls in every column that will map to a required field in the destination. Identify tables with no primary key, duplicate records, and orphaned foreign key references.
Data profiling (1–2 weeks)
Data profiling is structured analysis of what the source data actually contains versus what it should contain. Use a tool like Talend Data Quality, Ataccama, or SQL queries written specifically for this purpose.
For a migration from a legacy CRM to Salesforce, typical profiling findings include:
Document every finding. This report is the input to data remediation planning and is a predecessor to field mapping.
Stakeholder interviews (1 week, overlapping with profiling)
Talk to the people who use the source system daily. They know which fields are actually used versus which fields exist in the schema but have been empty for 5 years. They know which records are "test" accounts that should not migrate. They know which custom fields were workarounds for missing functionality that the destination system handles natively.
These interviews surface migration scope decisions that technical analysis alone misses.
Field mapping is the translation layer: every field in the source system maps to a field in the destination system, with the transformation logic documented.
A field mapping document has this structure:
| Source Field | Source Type | Destination Field | Destination Type | Transformation Rule | Owner |
|---|---|---|---|---|---|
| CUSTPHONE1 | VARCHAR(20) | Phone | Phone | Strip non-numeric, format as (NNN) NNN-NNNN | Data Engineer |
| ACCT_STATUS | INT (1,2,3,4) | Account Status | Picklist | 1→Active, 2→Inactive, 3→Prospect, 4→Dead | Business Analyst |
| CREATED_DT | VARCHAR | CreatedDate | DateTime | Parse as MM/DD/YYYY, convert to ISO 8601 | Data Engineer |
Field mapping requires business decisions, not just technical ones. When the source system has a single "Notes" field containing both internal comments and customer-facing notes mixed together for 8 years, someone must decide what goes into the destination system. That decision gates ETL development.
Complete field mapping before ETL development starts. Every time field mapping changes after ETL development begins, code must be rewritten. Set a field mapping freeze date and enforce it.
Duration: 2–3 weeks for a mid-size migration (50,000–500,000 records, 30–80 mapped fields). Larger legacy systems with hundreds of tables: 4–6 weeks.
ETL (Extract, Transform, Load) development is the core technical work of the migration. Extract data from the source, apply transformations from the field mapping, and load into the destination.
Development sequencing
Build and test transformations in this order:
Data quality gates
Each ETL module passes a quality gate before it moves to the next phase:
Document the acceptance criteria for each quality gate before ETL development begins. "The data looks good" is not an acceptance criterion.
Environment setup timeline
ETL development requires a non-production destination environment. For a Salesforce migration, this is a full sandbox. For an on-premise to cloud migration, this is a staging environment in the target cloud account. Provisioning this environment is frequently on the project's critical path — it requires IT involvement, cloud account setup, licensing, and security review. Start it in week 1, not week 5.
Data remediation is fixing data quality issues found in the discovery phase. It runs in parallel with ETL development because it requires time and often involves the business: someone must manually review and correct records that automated rules cannot fix.
Deduplication
Duplicate records must be resolved before migration, not after. Post-migration deduplication in the destination system is far more expensive and error-prone. Use a deduplication tool (Cloudingo for Salesforce, DataFlux for enterprise) with a defined merge rule set approved by the business owner.
For a 200,000-record CRM migration, plan 3–4 weeks for deduplication: 1 week automated, 2–3 weeks manual review of records the automation flags as uncertain.
Data correction
Records with invalid values (invalid state codes, malformed emails, expired zip codes) can often be corrected automatically with reference data lookups. Records with missing required values need manual review. Build a correction workflow: export the problematic records to a spreadsheet, route to the responsible business user, import corrections, re-run validation.
User acceptance testing is where the business confirms the migrated data is correct — not just technically valid but meaningful to the people who will use it.
UAT environment setup
The UAT environment must mirror the production destination system as closely as possible. For Salesforce, use a partial copy sandbox with production configuration. For a cloud database migration, use a production-equivalent instance size.
Load a representative sample: 100% of all record types, covering edge cases identified in discovery. Loading only "clean" records into UAT and saving problematic records for production is a common mistake that causes cutover failures.
UAT test scripts
Write test scripts that walk business users through specific validation tasks:
Each test script has a pass/fail result. Failed tests generate defect tickets. The UAT phase ends when all critical defects are resolved and closed — not on a calendar date.
Go/no-go criteria
Define the go/no-go criteria for cutover before UAT begins:
The cutover plan is a minute-level Gantt chart for the cutover weekend. Create it 3 weeks before cutover. Every step has a time estimate, an owner, and a rollback trigger.
Typical cutover sequence for a CRM migration:
| Time | Step | Owner | Duration | Rollback Trigger |
|---|---|---|---|---|
| Friday 5:00 PM | Source system freeze — read-only mode | IT | 15 min | — |
| Friday 5:15 PM | Final delta extract — all records changed since UAT load | Data Engineer | 1–2 hours | — |
| Friday 7:00 PM | Delta ETL run and load to destination | Data Engineer | 3–4 hours | Load error rate > 1% |
| Friday 11:00 PM | Row count reconciliation | Data Engineer + BA | 1 hour | > 0.5% variance unexplained |
| Saturday 12:00 AM | Smoke testing — key reports, record lookup | Business Users | 2 hours | Any critical report fails |
| Saturday 2:00 AM | Go/no-go decision | Project Sponsor | 30 min | Any open critical issue |
| Saturday 2:30 AM | DNS cutover, user access provisioned | IT | 1 hour | — |
| Saturday 3:30 AM | End-user notification sent | PM | 15 min | — |
| Monday 8:00 AM | Business opens on new system | — | — | — |
Rollback plan
The rollback plan must be tested before cutover. If the go/no-go decision at 2:00 AM is "no go," the team needs to restore source system access within a defined window. Test the rollback in the UAT environment: take the source system to read-only, run the cutover sequence for 30 minutes, then execute rollback and confirm source system access is restored.
A rollback plan that has never been tested is not a rollback plan.
The two weeks after go-live are hypercare: heightened monitoring, daily check-ins, and a dedicated support resource for data questions.
Post-migration monitoring
Plan for a post-migration data cleanup sprint in weeks 14–16. Every migration has a list of known issues that were below the go/no-go threshold but need to be resolved: records with partially incorrect data, edge cases that the ETL transformation missed, formatting inconsistencies in low-priority fields.
Open gantt-chart.io and structure your data migration project as phases with milestones at each quality gate:
For teams also managing the destination system implementation alongside the migration, link this Gantt to your system configuration project using a shared milestone at the "destination system ready for ETL" gate.
Data migration projects benefit from the same visual dependency tracking used in construction and product development. The complexity is in the data, but the project management discipline is the same: sequence the work correctly, identify the critical path, and make the go/no-go decision with clear criteria before you start the cutover clock.
How long does a data migration project take?
A mid-size CRM migration (50,000–500,000 records, moving from one commercial CRM to another) takes 12–16 weeks with a dedicated team of 2–4 people. An on-premise ERP to cloud migration for a 200-person company typically takes 6–12 months. The primary variable is data quality in the source system — every hour spent in discovery on data quality issues saves 4–8 hours in remediation and UAT.
Should data remediation happen before or after ETL development?
Both. Automated remediation (phone number formatting, state code normalization) should be designed into the ETL transformation layer. Manual remediation (resolving duplicate records, correcting missing required fields) should happen in the source system before migration where possible, or built into a separate post-load correction process. Never plan to "fix it later" in the destination system — it creates data integrity problems that are difficult to untangle.
What's the most common cause of cutover failure?
Underestimating the delta migration volume. Teams plan the full migration load time accurately but forget that changes accumulate in the source system during the weeks of UAT. If UAT takes 4 weeks and the source system processes 500 new records per day, that's 10,000 delta records — plus all updates to existing records. The delta ETL and load takes longer than expected, the cutover window shrinks, and the go/no-go decision happens under time pressure.
How do we handle systems that can't go offline for cutover?
High-availability migrations use a "strangler fig" approach: the new system receives all new records from a cutover date while the old system stays read-only for historical data access. Historical records migrate in parallel without a downtime window. This works for systems with a clean separation between new transactions and historical records, but adds complexity for systems where historical and current data are tightly coupled.