← All guides

How to Use a Gantt Chart for Microservices Migration Projects

Plan a monolith-to-microservices migration with a Gantt chart. Covers DDD, strangler fig, service extraction order, data migration, and traffic shifting timelines.

How to Use a Gantt Chart for Microservices Migration Projects

A monolith-to-microservices migration is one of the most complex technical transformations an engineering organization can undertake. The failure rate is high, the timeline is typically measured in years, and the risks -- service outages, data inconsistency, team fragmentation, runaway complexity -- are real. A Gantt chart does not eliminate these risks, but it does make them manageable by forcing explicit sequencing decisions, surfacing inter-team dependencies, and creating a shared view of progress across an organization that is, by design, becoming more distributed.

This guide covers building a migration Gantt from domain modeling through service decommission, with particular attention to the sequencing decisions that determine whether a migration succeeds or stalls.

Assessment and Architecture Phase

A migration without an architecture phase produces a distributed monolith -- the worst of both worlds. Budget 6-12 weeks for this phase.

Domain-driven design (DDD) workshop. The first task is identifying bounded contexts: the natural seams in the monolith where domain logic is cohesive internally and loosely coupled externally. DDD workshops bring together engineers, product managers, and domain experts to map the business domain using event storming or context mapping. Each bounded context becomes a candidate service. Rushing this work produces incorrect service boundaries that create tight coupling between microservices -- which defeats the entire purpose of the migration.

Strangler fig vs. big bang decision. The strangler fig pattern gradually replaces monolith functionality one bounded context at a time, with the monolith continuing to run until all traffic has shifted to new services. The big bang approach migrates everything simultaneously. For production systems with real user traffic, the strangler fig pattern is almost always safer -- big bang migrations require the new architecture to be perfect on day one, which it never is. Document this decision explicitly in the architecture phase; it determines how the entire Gantt chart is structured.

Service decomposition map. Produce a map that shows: which monolith modules correspond to which services, what APIs each service will expose, what data each service owns, and what the inter-service communication patterns will be (synchronous REST/gRPC vs. asynchronous event-driven messaging). This document is the source of truth for the entire migration and must be approved before extraction begins.

API gateway selection. All external traffic entering the microservices architecture must route through an API gateway. Evaluate Kong, AWS API Gateway, Azure API Management, or Nginx depending on your infrastructure. The gateway must be deployed and traffic-tested before the first service goes live.

Service mesh evaluation. For inter-service communication, a service mesh (Istio, Linkerd, AWS App Mesh) provides mutual TLS, circuit breaking, retries, and distributed tracing without requiring each service to implement these independently. Evaluate whether your scale and complexity justify service mesh overhead -- for smaller migrations (under 20 services), a simpler approach may be adequate.

Infrastructure Preparation

Infrastructure preparation is a dependency for every service extraction. It is not parallel with extraction -- it must be complete before the first service goes live.

Container platform deployment. Kubernetes on a managed service (EKS, GKE, AKS) or self-managed must be provisioned, configured, and production-ready before service extraction begins. This includes cluster sizing, node pool configuration, namespace strategy, network policy setup, and RBAC configuration.

CI/CD pipeline per service. Each microservice needs its own deployment pipeline -- the shared monolith pipeline does not scale to dozens of independent services. GitHub Actions, CircleCI, or Jenkins with ArgoCD for GitOps deployment are common choices. Build one reference pipeline implementation, then templatize it for subsequent services.

Observability stack. This is the most frequently underestimated infrastructure requirement. In a monolith, you log to one place and trace one call stack. In a microservices architecture, a single user request may touch 10 services, and debugging requires distributed tracing. Deploy your observability stack before the first service goes live, not after. The required components:

  • Metrics collection and visualization: Prometheus + Grafana
  • Distributed tracing: Jaeger, Zipkin, or Tempo (for correlating requests across service boundaries)
  • Log aggregation: ELK stack (Elasticsearch + Logstash + Kibana) or EFK (Fluentd instead of Logstash)
  • Alerting: PagerDuty, OpsGenie, or native alerting through Grafana

Operating microservices without distributed tracing is operating blind. A service that is slow might be slow because of its own code, or because a downstream service it calls is slow. Without tracing, you cannot tell.

Service Extraction Sequence

Sequence matters more in microservices migration than almost any other technical project. Extracting services in the wrong order creates cascading dependency problems.

Extract low-dependency services first. The correct order is: services with few inbound dependencies from other monolith modules, high business value, and clear domain boundaries. Classic first extractions: authentication and authorization service, notification service (email, SMS, push), user profile service. These services have few callers inside the monolith and clearly defined contracts.

Never extract high-dependency services first. A service that is called by 40 other monolith modules should be extracted last, not first. Extracting it early requires simultaneously updating 40 call sites in the monolith to use the new service API -- which creates massive scope and high risk of breakage.

Parallel extraction. Multiple service extractions can run in parallel when teams are independent and the services being extracted do not share data stores. Map this explicitly in the Gantt chart -- when teams are extracting services that share database tables, they are not independent and cannot parallelize without coordination.

Team assignment. Under Conway's Law, the architecture of a system reflects the communication structure of the organization. Assign a single, stable team to each service being extracted. Teams that own multiple services or rotate between services produce inconsistent quality and lack the domain knowledge depth that good service ownership requires.

Data Migration Track

Data migration is frequently the hardest part of a microservices migration, and the part most often underestimated on the project timeline.

Database per service pattern. Each microservice should own its own data store. This means decomposing what is often a single, shared monolith database into per-service databases. Identifying which tables belong to which service, and which tables are shared between multiple services, requires the domain model produced in the architecture phase.

Shared table identification. Shared tables are migration blockers. A table that is written by three different monolith modules cannot simply be moved to one service's database -- the other two modules need access to that data. Resolution strategies include: event sourcing (services publish events, others consume), CQRS (separate read and write models), data replication, or establishing clear data ownership and creating APIs for cross-service access.

Dual-write periods. During service extraction, there is a period when both the monolith and the new service need to write to what will become the service's database. The dual-write approach writes to both the old (shared) location and the new service's database simultaneously, then validates consistency before cutting over reads. Dual-write periods are operationally complex -- plan them explicitly as Gantt tasks with defined entry criteria (start dual-write) and exit criteria (reads fully cut over to new service, dual-write discontinued).

Historical data migration. When the service database schema differs from the monolith schema, historical data must be migrated and transformed. Budget time for ETL scripting, migration validation, and rollback planning.

Traffic Migration

Traffic migration is where the strangler fig pattern becomes concrete: shifting traffic from the monolith to new services incrementally, with stability gates at each step.

Feature flags for gradual traffic shifting. Use feature flags (LaunchDarkly, Unleash, or custom) to control what percentage of traffic routes to the new service vs. the monolith. A typical traffic migration schedule:

  • 1% of traffic → monitor for 48 hours, check error rates and latency
  • 5% → monitor for 48 hours
  • 25% → monitor for 1 week
  • 50% → monitor for 1 week
  • 100% → service extraction complete

Stability gates at each step are non-negotiable. The criteria for passing a gate should include: error rate below baseline, p99 latency within SLA, no data consistency anomalies detected, and on-call team comfortable with the rollout.

Map each traffic migration as a task in the Gantt chart with clear duration (the monitoring window) and explicit gates (criteria that must pass before advancing to the next percentage).

Decommission Track

The monolith shrinks over time as services are extracted and traffic migrates. The decommission track covers removing the corresponding monolith code after each service reaches 100% traffic.

Monolith code removal. After a service has served 100% of traffic for a defined stability period (typically 30 days), the corresponding code in the monolith can be removed. Removing code reduces the monolith's complexity, eliminates dead code that could confuse future developers, and reduces the monolith's resource footprint.

Database cleanup. Tables that have been migrated to service databases should be dropped from the shared monolith database after the migration is validated and all reads have moved to the new service.

Incremental monolith sunset. As services are extracted, the monolith becomes smaller. The end state of a strangler fig migration is a monolith containing only the remaining tightly coupled code that has not yet justified its own service -- or a fully decomposed architecture where the monolith has been retired entirely. Map this end state explicitly; a migration without a defined finish line tends to drift.

Risk Management

A Gantt chart for microservices migration should include explicit risk tracking:

Scope creep risk: service boundaries discovered to be incorrect after extraction begins. Mitigation: thorough DDD workshops, architecture review gates before extraction starts.

Team capacity risk: infrastructure preparation underresourced relative to service extraction pace. Mitigation: infrastructure track must finish before extraction begins, not concurrently.

Data consistency risk: dual-write periods producing inconsistent state between monolith and service. Mitigation: automated consistency validation scripts running continuously during dual-write.

Cultural risk: teams defaulting back to monolith patterns under delivery pressure. Mitigation: strong platform engineering support, clear service ownership accountabilities, and executive sponsorship of the migration strategy.

Use gantt-chart.io to build the parallel tracks -- infrastructure, service extraction, data migration, traffic migration, decommission -- with dependencies linking each track's completion to the next track's start. The visualization makes it immediately apparent when a planned extraction sequence would require infrastructure that has not yet been deployed.