Gantt Chart for Data Migration Projects
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.
Why Data Migrations Need Gantt Charts
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.
Phase 1: Discovery and Inventory (Weeks 1–4)
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:
- 12–18% of contact records have duplicate entries (same email, different IDs)
- 3–7% of opportunity records reference account IDs that no longer exist
- Phone number formatting inconsistency across 40+ formats (no standardization applied over 10 years)
- Date fields stored as VARCHAR in inconsistent formats
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.
Phase 2: Field Mapping and Transformation Design (Weeks 3–6)
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.
Phase 3: ETL Pipeline Development (Weeks 5–10)
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:
- High-volume, low-complexity tables first — get the bulk data moving and validate infrastructure
- Lookup tables and reference data — these are dependencies for the complex tables
- Parent records before child records — accounts before contacts, projects before tasks
- Complex transformation logic last — this is where most bugs live and it needs the most testing time
Data quality gates
Each ETL module passes a quality gate before it moves to the next phase:
- Row count reconciliation: source row count matches (loaded rows + documented exclusions)
- Null check: no nulls in required destination fields
- Referential integrity: all foreign key references resolve
- Business rule validation: custom rules defined by the business analyst (e.g., no opportunity without an associated account)
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.
Phase 4: Data Remediation (Weeks 4–8, Overlapping with ETL)
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.
Phase 5: UAT and Validation (Weeks 9–12)
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:
- Search for their 10 most-used accounts and verify all fields are correct
- Pull a report they run weekly and verify the numbers match the source system
- Attempt to create a new record using the migrated data as context (does referential integrity hold?)
- Verify documents, attachments, and notes are accessible
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:
- Zero critical defects open
- High-severity defect count below threshold (define the threshold)
- Row count reconciliation within tolerance (e.g., 0.1% variance allowed for known exclusions)
- Business owner sign-off from each functional area
Phase 6: Cutover Planning and Execution (Weeks 11–13)
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.
Phase 7: Hypercare and Stabilization (Weeks 13–16)
The two weeks after go-live are hypercare: heightened monitoring, daily check-ins, and a dedicated support resource for data questions.
Post-migration monitoring
- Run source vs. destination record count reconciliation daily for the first 2 weeks
- Monitor for records created in the destination system that reference migrated data incorrectly
- Track support tickets related to missing or incorrect data
- Run the weekly reports that business users depend on and compare to source system outputs
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.
How to Build This in gantt-chart.io
Open gantt-chart.io and structure your data migration project as phases with milestones at each quality gate:
- Set your go-live date as a fixed milestone and work backward
- Add phase rows for Discovery, Field Mapping, ETL Development, Remediation, UAT, Cutover, and Hypercare
- Add quality gate milestones — Data Profile Report Complete, Field Mapping Frozen, ETL QA Passed, UAT Sign-Off, Go/No-Go Decision
- Set predecessors — UAT cannot start before ETL QA passes; cutover planning requires UAT sign-off
- Add the cutover plan as a separate view at the task level, with hour-resolution for cutover weekend steps
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.
FAQ
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.