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

1. Open gantt-chart.io
2. Title the chart: Platform Rewrite - [System Name]
3. Plan 16–24 weeks for a focused module rewrite; 12–18 months for a full platform
4. Add cutover milestones progressively—don't have one big cutover at the end
5. Use Week view for development phases

Step 2: Define the Rewrite Phases (Strangler Fig Approach)

1. Inventory & Planning — catalog all capabilities, dependencies, and edge cases
2. New Foundation — set up new architecture, core libraries, infrastructure
3. Module Migration — migrate one module at a time with parallel running
4. Traffic Migration — progressively shift traffic to new system module by module
5. 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.

1. Feature inventory: every capability the old system provides — Week 1-2
2. Edge case documentation — Week 1-3
3. Dependency mapping (databases, external services, internal callers) — Week 2-3
4. API contract documentation — Week 2-3
5. Performance baseline: current system latency, throughput — Week 3
6. Migration strategy finalized — Week 4 (milestone)

Step 4: New Foundation (Week 4-8)

1. New architecture design and ADR — Week 4-5
2. Infrastructure provisioning (new environment) — Week 5-6
3. Core framework and shared libraries — Week 5-7
4. Authentication and authorization layer — Week 6-7
5. Observability and monitoring — Week 7-8
6. New 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

1. Build [Module] in new system — 2-4 weeks per module
2. Unit and integration tests for [Module] — parallel with build

Phase B: Parallel running

1. Run new module in shadow mode (takes traffic, results discarded) — 1-2 weeks
2. Compare new vs. old results for divergences — parallel with shadow mode
3. Fix divergences — as found

Phase C: Traffic shift

1. Route 10% of traffic to new module — 1 week
2. Monitor for errors, latency, correctness — ongoing
3. Route 50% of traffic — 1 week
4. Route 100% of traffic — 1 week
5. Module 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:

1. Remove old module from traffic routing — after 100% traffic shifted
2. Run old module in standby for 2 weeks — rollback safety
3. Decommission old module code — 2 weeks after cutover
4. Update documentation — ongoing

Step 7: Final Cutover Milestone

When all modules are migrated:

1. Final feature parity audit — 1 week before cutover
2. Load test on new system at full traffic — 1 week before cutover
3. Old 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.