← All guides

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:

  • Crawl the current site using Screaming Frog, Sitebulb, or equivalent (capture all URLs, status codes, page titles, meta descriptions, H1s, canonical tags, and internal link counts)
  • Export sitemap(s) — all XML sitemaps, including image and video sitemaps if applicable
  • Export Google Search Console data: top 500 pages by organic impressions, top pages by clicks, all manual actions and security issues
  • Export Google Analytics (or equivalent): top pages by sessions, top landing pages, pages by conversion
  • Export backlink profile: all pages receiving external backlinks (Ahrefs, Majestic, or SEMrush)
  • Document pages with significant organic traffic (define threshold: e.g., >100 monthly organic sessions)
  • Document pages with significant backlinks (define threshold: e.g., >3 referring domains)
  • Identify pages with manual actions or security issues that must be resolved before or during migration

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:

  • Current URL
  • New URL (or "retire")
  • Redirect type (301 or 410)
  • Priority (High = significant traffic or backlinks; Medium = moderate; Low = minimal)
  • Migration status (pending / implemented / verified)

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:

  • Day -30: Check current TTL for all relevant DNS records (A records, CNAME, MX)
  • Day -14: Reduce TTL to 3600 seconds (1 hour) — allows faster propagation when the final cutover happens
  • Day -7: Reduce TTL further to 900 seconds (15 minutes) if the DNS provider supports it
  • Day -1: Review TTL settings; confirm reduced TTL has been in effect long enough for caches to refresh
  • Day 0 (cutover): Update DNS records to new IP/CNAME — propagates within 15–60 minutes at low TTL
  • Day +7: After successful migration confirmed, restore TTL to 3600 or 86400 for normal operation

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:

  • Staging server provisioned (same infrastructure as production to detect environment-specific issues)
  • Domain or subdomain configured for staging (e.g., staging.example.com or behind HTTP auth)
  • New CMS or platform installed and configured
  • Content migrated to staging:
  • Database migration or content import
  • Media library migration (images, documents, video embeds)
  • Template and theme configuration
  • Plugin/module installation and configuration
  • Integrations configured in staging:
  • Analytics (GA4, GTM container)
  • CRM forms (HubSpot, Salesforce, Marketo)
  • Live chat or help desk widgets
  • A/B testing tools
  • Personalization tools
  • Paid media tracking pixels and conversion tags
  • 301 redirects implemented in staging and verified
  • robots.txt configured for staging (block indexing of staging environment)
  • SSL certificate installed and verified on staging

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):

  • Full site crawl: Complete crawl report from Screaming Frog; save file for post-migration comparison
  • Search Console data export: Last 16 months of queries, pages, countries, devices; impressions, clicks, CTR, average position
  • Ranking snapshot: 500+ primary keywords; current position, featured snippet status, URL ranking (tools: SEMrush, Ahrefs, Moz)
  • Backlink profile export: All referring domains, their DR, linked pages, and anchor text
  • Page speed benchmarks: Core Web Vitals (LCP, CLS, INP) for top 20 pages using PageSpeed Insights; save screenshots
  • Analytics baseline: Average weekly sessions, bounce rate, conversion rate for top landing pages over prior 90 days
  • Internal link counts: Which pages receive the most internal links (indicates PageRank distribution)

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):

  • All pages load without errors (check for 404s, 500s, redirect loops)
  • All forms submit correctly and trigger correct notifications
  • All CTA buttons link to correct destinations
  • All images load (check for broken images, missing alt text)
  • All downloadable content (PDFs, whitepapers) downloads correctly
  • All video embeds play
  • Navigation menus work at all levels
  • Search functionality works (if applicable)
  • User account creation and login (if applicable)
  • E-commerce checkout flow (if applicable — critical path, test extensively)
  • Comment or review submission (if applicable)

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

  • Chrome (Windows and Mac)
  • Firefox (Windows and Mac)
  • Safari (Mac and iOS)
  • Edge (Windows)
  • Mobile: iOS Safari, Android Chrome
  • Tablet: iPad Safari, Android tablet

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

Performance QA (staging, Week -2):

  • PageSpeed Insights Core Web Vitals for top 10 pages — must match or improve on baseline
  • LCP (Largest Contentful Paint): target <2.5 seconds
  • CLS (Cumulative Layout Shift): target <0.1
  • INP (Interaction to Next Paint): target <200ms
  • Total page weight for homepage and top landing pages
  • HTTP/2 or HTTP/3 enabled
  • Image compression and format (WebP where supported)
  • CSS and JS minification
  • Caching headers configured

Redirect QA (staging, Week -1):

  • Every URL in the URL map with a 301 redirect tested and verified
  • Redirect chains identified and resolved (301 → 301 is a chain; should be 301 → final URL)
  • Redirect loops identified and resolved
  • Canonical tags on migrated pages pointing to correct URLs

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:

  • [ ] Staging environment fully tested and signed off by QA and stakeholders
  • [ ] DNS TTL reduced and propagating at low TTL
  • [ ] All team members available: developer, SEO lead, analytics lead, project manager
  • [ ] Rollback plan documented and tested (how to revert DNS in under 30 minutes if catastrophic failure)
  • [ ] Maintenance mode page ready (if cutover window requires site downtime)
  • [ ] DNS record updated to new server
  • [ ] SSL certificate verified on production domain
  • [ ] robots.txt on production verified (confirm it's not blocking indexing)
  • [ ] XML sitemap submitted to Google Search Console
  • [ ] Analytics tracking verified (fire test events in GTM; confirm data flowing to GA4)
  • [ ] Form submission tested on production
  • [ ] Sample of high-priority 301 redirects tested on production
  • [ ] Google Search Console: "Request indexing" for homepage and top 10 pages

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:

  • Check Google Search Console Coverage report for spike in crawl errors
  • Monitor server logs for unusual 404 patterns
  • Check analytics for traffic anomalies (sharp drop in sessions)
  • Monitor Google Search Console for manual action notifications
  • Test all integrations: form submissions, analytics events, pixel firing
  • Re-test critical 301 redirects on production

30-day SEO impact check:

  • Export Search Console data; compare impressions, clicks, and average position to pre-migration baseline
  • Run full site crawl; compare crawl depth, page count, and error count to pre-migration crawl
  • Check ranking snapshot: compare positions of 500 primary keywords to pre-migration baseline
  • Identify pages with significant ranking losses; investigate redirect implementation, canonical tags, content changes
  • Check backlinks: any significant link equity loss?
  • Review Core Web Vitals in Search Console (takes 28 days for full data)

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:

  • Week -4: Training plan developed; training environment configured with sample content
  • Week -3: CMS documentation written or sourced (vendor docs + internal workflow guide)
  • Week -2: Initial training sessions (content creation, editing, media upload, SEO fields)
  • Week -1: Practice sessions in staging; editors create and publish test content under supervision
  • Day 0 (launch): Editors have been using the CMS for 2 weeks before touching live content
  • Week +2: Q&A session after editors have worked in the live environment
  • Week +4: Advanced training (workflow, approvals, analytics integration) for power users

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:

  • 2–4 weeks for moderately complex migrations
  • 4–8 weeks for high-traffic or highly integrated e-commerce or SaaS sites

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.