How to Manage a Platform Rewrite Project Gantt Chart
The Problem: Platform Rewrites Are Where Engineering Ambitions Go to Die
"We'll rewrite the platform in 6 months" is one of the most dangerous statements in software engineering. Platform rewrites routinely take 2-3x their estimate, often abandon feature parity halfway through, and frequently get cancelled before completion—leaving the codebase worse than before, with half the team having worked on code that never shipped.
The reason isn't incompetence. It's the underestimation of feature parity. The old system has years of edge cases, bug fixes, and "we handle this weird case because of Customer X" logic baked in. The new system needs to match all of it before cutover, not just the happy path.
A platform rewrite Gantt chart built around the strangler fig pattern—progressively replacing the old system without a big bang cutover—dramatically reduces this risk. gantt-chart.io is free and requires no account.
Prerequisites
- Why rewrite: Technical debt, scaling limits, new architecture pattern, acquired tech to replace?
- Scope: Full rewrite or targeted replacement of core modules?
- Strategy: Big bang rewrite (high risk) or strangler fig / incremental (recommended)?
- Feature inventory: Complete list of what the current system does (including edge cases)
- Traffic migration plan: How will you progressively shift load to the new system?
- Rollback plan: If the new system fails, how fast can you revert?
Step-by-Step Instructions
Step 1: Set Up the Timeline
- Open gantt-chart.io
- Title the chart:
Platform Rewrite - [System Name] - Plan 16–24 weeks for a focused module rewrite; 12–18 months for a full platform
- Add cutover milestones progressively—don't have one big cutover at the end
- Use Week view for development phases
Step 2: Define the Rewrite Phases (Strangler Fig Approach)
- Inventory & Planning — catalog all capabilities, dependencies, and edge cases
- New Foundation — set up new architecture, core libraries, infrastructure
- Module Migration — migrate one module at a time with parallel running
- Traffic Migration — progressively shift traffic to new system module by module
- Legacy Decommission — remove old system components as new system takes over
Step 3: Inventory & Planning (Week 1-4)
This is the most critical phase. Rushing it causes feature gaps discovered at cutover.
Feature inventory: every capability the old system provides— Week 1-2Edge case documentation— Week 1-3Dependency mapping (databases, external services, internal callers)— Week 2-3API contract documentation— Week 2-3Performance baseline: current system latency, throughput— Week 3Migration strategy finalized— Week 4 (milestone)
Step 4: New Foundation (Week 4-8)
New architecture design and ADR— Week 4-5Infrastructure provisioning (new environment)— Week 5-6Core framework and shared libraries— Week 5-7Authentication and authorization layer— Week 6-7Observability and monitoring— Week 7-8New system foundation complete— Week 8 (milestone)
Step 5: Module Migration (Week 8-20, iterative)
For each module, follow this pattern:
Phase A: Build in new system
Build [Module] in new system— 2-4 weeks per moduleUnit and integration tests for [Module]— parallel with build
Phase B: Parallel running
Run new module in shadow mode (takes traffic, results discarded)— 1-2 weeksCompare new vs. old results for divergences— parallel with shadow modeFix divergences— as found
Phase C: Traffic shift
Route 10% of traffic to new module— 1 weekMonitor for errors, latency, correctness— ongoingRoute 50% of traffic— 1 weekRoute 100% of traffic— 1 weekModule cutover complete— (milestone)
Apply this pattern per module in sequence:
- Module 1: Week 8-14
- Module 2: Week 12-18
- Module 3: Week 16-22 (overlap is fine once patterns are established)
Step 6: Legacy Decommission (Rolling, from Week 14)
As each module fully migrates:
Remove old module from traffic routing— after 100% traffic shiftedRun old module in standby for 2 weeks— rollback safetyDecommission old module code— 2 weeks after cutoverUpdate documentation— ongoing
Step 7: Final Cutover Milestone
When all modules are migrated:
Final feature parity audit— 1 week before cutoverLoad test on new system at full traffic— 1 week before cutoverOld system decommissioned— final milestone
Feature Parity Tracking
The most important artifact in a platform rewrite is the feature parity checklist. Build it in Week 1 and track it throughout:
| Feature | Old System Status | New System Status | Tested? |
|---|---|---|---|
| User authentication | Live | Complete | ✓ |
| Batch processing | Live | In progress | - |
| Edge case: bulk delete | Live | Not started | - |
This table, updated weekly, is the single source of truth for whether cutover is safe.
Common Mistakes
Big bang cutover. Switching all traffic at once means you discover production bugs affecting all users simultaneously. Strangler fig with progressive traffic migration lets you find problems at 10% traffic, not 100%.
No shadow mode phase. Running the new system in parallel without serving results—and comparing outputs—is the fastest way to find divergences before they affect users.
Scope creep during the rewrite. The team decides to "fix" things in the new system that weren't broken. Every new feature added during the rewrite extends the timeline and delays feature parity.
Build your platform rewrite Gantt chart at gantt-chart.io—free, no account required.