Gantt Chart for Website Migration

Plan a website migration with a Gantt chart covering URL mapping, DNS cutover, SEO baseline, QA phases, post-launch monitoring, and CMS editor training.

Website migrations are among the most technically demanding and organizationally complex projects a digital team undertakes. Moving a site to a new domain, a new CMS, a new hosting platform, or a new URL structure touches every system that touches the site — search engine rankings, analytics tracking, CRM integrations, email sign-up forms, paid media landing pages, and dozens of other dependencies that surface only when something breaks after launch.

The technical risk is real. A poorly planned migration can crater organic search traffic by 50% or more within weeks. A missed redirect loses link equity accumulated over years. A broken form on a landing page silently kills conversion for weeks before anyone notices.

A Gantt chart for website migration structures the full project — from content audit through 30-day post-launch SEO monitoring — in a way that makes dependencies visible, assigns accountability, and prevents the most common and most costly migration failures.

Phase 1: Content Audit and URL Mapping

The migration starts with a complete inventory of what exists before anything moves.

Content audit tasks:

URL mapping:

Every URL that exists on the current site must be mapped to one of three outcomes on the new site:

  1. Preserved — same content at same or new URL; requires 301 redirect if URL structure changes
  2. Consolidated — content merged into another page; requires 301 to the destination
  3. Retired — content no longer needed; 410 (Gone) preferred over 301 to homepage for truly dead pages

The URL map is a spreadsheet with:

The URL map is the most important deliverable of the pre-migration phase. Every other migration task depends on it.

Phase 2: DNS TTL Reduction Scheduling

DNS changes propagate based on Time-to-Live (TTL) values — the duration that DNS resolvers cache the record before checking for updates. If TTL is set to 86400 seconds (24 hours) and you reduce it the day before cutover, you'll still have some visitors being served cached DNS for 24 hours after the change.

DNS TTL reduction task sequence:

This is one of the most commonly skipped steps in migration planning because it requires action 2–4 weeks before the actual launch date. The Gantt makes the 30-day pre-launch DNS TTL reduction a hard milestone.

Phase 3: Staging Environment Build

The migration must be built, tested, and validated in a staging environment before any traffic hits it.

Staging environment tasks:

Phase 4: SEO Baseline Capture

Before any change goes live, capture a complete SEO baseline. If rankings drop post-migration, you need pre-migration data to diagnose what changed.

SEO baseline data to capture (Day -14 to Day -7):

Store all baseline data in a dated folder that will be used for post-migration comparison at Day +7, Day +30, and Day +90.

Phase 5: QA Testing Phases

Quality assurance runs in three phases on the staging environment before go-live, then again immediately after launch.

Functional QA (staging, Week -3 to Week -2):

Cross-browser and device QA (staging, Week -2):

Focus on: navigation behavior, form rendering, image sizing, font rendering, CTA button sizes (minimum 44px touch target for mobile).

Performance QA (staging, Week -2):

Redirect QA (staging, Week -1):

Phase 6: Go-Live Cutover Window

The cutover is the highest-risk moment. Plan it carefully and schedule it at the lowest-traffic period of the week (typically Tuesday through Thursday, early morning).

Cutover checklist:

Target cutover window: 2–4 hours. If issues arise that cannot be resolved within the window, revert to the old site.

Phase 7: Post-Migration Monitoring

48-hour intensive monitoring:

30-day SEO impact check:

If organic traffic declines more than 15% in the first 30 days, treat it as a priority investigation: pull affected pages, check redirect chains, verify canonical tags, review content changes.

Parallel Track: CMS Training for Editors

Content editors should not be learning the new CMS after launch while managing live content. Training runs as a parallel track to the technical migration.

Training timeline:

Parallel Period Operation

For large migrations, a parallel site operation period — running both old and new sites simultaneously — reduces risk. The Gantt schedules parallel operation for:

During parallel operation: old site remains live; new site is accessible via staging URL; final QA and stakeholder approvals proceed without time pressure. At cutover, DNS switches; old site remains on standby for rapid rollback for 48–72 hours.

Why the Website Migration Gantt Matters

Website migrations routinely run over schedule and over budget because the dependencies are underestimated. The Gantt surfaces those dependencies — DNS TTL reduction that must start 30 days before launch, baseline capture that must happen before any changes are made, CMS training that must complete before go-live. Without the Gantt, each team sees only its own tasks; nobody sees the full chain.

A Gantt chart for website migration is the project infrastructure that turns a technically complex, organizationally distributed project into a coordinated execution — and protects the search visibility and business performance that the website drives.