A site migration checklist template documents every task, dependency, and validation step before, during, and post-launch to prevent ranking drops and technical failures. This walkthrough shows you what sections to build, how to populate them for your environment, and how to use the completed template as both a coordination tool and rollback reference.
Your template needs three main phases: pre-migration audit and prep, deployment execution, and post-launch monitoring. Within pre-migration, create rows for technical baseline capture, stakeholder alignment, and risk mitigation. Capture current sitemap URLs, Google Search Console performance snapshots, Analytics goal configurations, and server response codes in tabular format so you can diff against post-launch data.
Add columns for task owner, status, deadline, and blocker flag. In the deployment phase, sequence tasks in dependency order: DNS propagation waits for SSL provisioning, canonical tag rollout waits for redirect deployment. Include rows for robots.txt updates, XML sitemap submission, CDN purge, and any platform-specific steps like Shopify theme activation or WordPress permalink flushing. The post-launch section should mirror your pre-migration baseline rows to enable side-by-side comparison of indexation counts, Core Web Vitals, and top landing page traffic.
Document your current URL inventory with crawl tool exports showing status codes, canonical targets, hreflang declarations if you serve bilingual or regional variants, and internal link counts. For Canadian sites serving both English and French, note which URL patterns correspond to which language so you can verify hreflang preservation post-launch. Capture Search Console impressions and clicks for your top fifty landing pages; these become your comparison set.
Record Analytics configuration: goal URLs, ecommerce tracking setup, event tracking snippets, UTM parameter handling, cross-domain tracking if applicable. Note third-party tag integrations and consent management configurations. On the server side, document current hosting stack details: PHP or runtime version, database engine, caching layers, SSL certificate issuer and expiry. This granularity helps you spot discrepancies when the new environment behaves differently under load or renders pages with altered DOM structure.
Create a dedicated section for URL redirect rules with columns for old URL, new URL, redirect type, implementation layer, and test result. Most migrations involve hundreds or thousands of redirects; maintain this as a separate tab or CSV you reference from the master checklist. Include validation rows that check redirect chains, verify that high-value legacy URLs return 301 to their new equivalents, and confirm no redirect loops exist.
For large inventories, split redirect rows by URL pattern or site section so different team members can validate their domains in parallel. Add a row to verify that non-canonical parameters like session IDs or tracking tokens preserve redirect logic without creating duplicate redirect entries. Include a final row to test redirect performance under load, ensuring that mass redirects do not introduce latency spikes that degrade crawl efficiency or user experience on launch day.
List every environment variable, caching rule, CDN behaviour, and edge configuration that differs between old and new hosting. If migrating from Apache to Nginx, document how rewrite rules translate and add test rows for each critical pattern. For managed platforms like Shopify or WordPress, note plugin dependencies, theme customizations, and any hardcoded domain references in database content that need find-and-replace operations.
Include rows for SSL certificate installation, HTTP to HTTPS enforcement, HSTS header activation, and security header verification. If you use a CDN, verify cache purge mechanisms work and that origin pull respects canonical headers. For Canadian sites, confirm geolocation routing or province-specific content variants load correctly. Add a row to validate that server logs and error monitoring tools point to the new environment and that you can access real-time data during the launch window to catch issues immediately.
Mirror your pre-migration baseline rows in the post-launch phase with columns that show the delta. Compare indexed page counts in Search Console before and after, flagging any drop exceeding expected rolloff from pruned or consolidated URLs. Track organic sessions and conversions by landing page for the first seventy-two hours, looking for anomalies that indicate broken funnels or lost internal links.
Verify structured data markup still validates, meta robots tags match intent, and pagination or infinite scroll implementations preserve crawlability. For bilingual sites, confirm that hreflang annotations still point to the correct language variants and that search engines surface the intended version in regional results. Include a row to monitor crawl rate in Search Console; a spike may indicate redirect loops or orphaned URLs generating excessive bot traffic. Schedule a final reconciliation row at the two-week mark to compare ranking positions for target keywords against pre-migration snapshots and flag any sustained drops for investigation.
Share the template as a live spreadsheet or project management board where all migration participants update status in real time. Assign each row to a specific owner and set slack or email notifications when blockers get flagged. During the deployment window, use the checklist as the single source of truth for go or no-go decisions; if a critical row shows red status, you pause until resolution.
After launch, the completed template becomes your rollback plan. If traffic tanks or indexation stalls, you reference the pre-migration snapshot rows to identify what changed and which configuration to revert. Keep the final version in version control or a shared document repository with a clear naming convention that includes migration date and domain. This artifact also satisfies audit requirements if stakeholders or external partners later question why certain technical decisions were made, giving you a timestamped record of every task and validation step executed.
Each row should specify the exact action, the tool or file involved, the expected outcome, and the person responsible. For example, instead of saying 'check redirects,' write 'run Screaming Frog crawl against staging to verify 301 redirects for top 200 legacy URLs return correct targets without chains' with the tester's name and a pass or fail result column. This granularity prevents ambiguity during high-pressure deployment windows.
Create a separate section for external dependencies with columns for vendor name, SLA or response time, escalation contact, and contingency plan. Mark these rows with a dependency flag and include a buffer in your timeline. For example, if DNS propagation through a registrar typically takes four hours, schedule that step eight hours before launch and have a fallback provider credential ready if delays occur.
Yes, maintain modular templates for common scenarios. A domain change emphasizes redirect mapping and brand signal preservation, while a platform migration focuses on theme compatibility and plugin functionality. Create a master framework with universal rows for SEO fundamentals, then add scenario-specific tabs. This approach lets you quickly assemble a tailored checklist by copying relevant sections rather than building from scratch each time.
Run a dry-run migration on a staging environment and work through the checklist as if it were launch day. Any task you perform that is not listed gets added as a new row. Compare your template against post-mortems from past migrations or industry frameworks to spot gaps. Have a colleague unfamiliar with the project attempt to execute the checklist; if they get stuck or ask clarifying questions, the instructions need more detail.
Keep tracking Search Console indexation coverage, Core Web Vitals trends, and top landing page traffic for at least thirty days. Add a monthly reconciliation row that compares organic visibility to pre-migration levels, flagging any sustained ranking losses. Monitor server error logs and crawl stats to catch issues like resource timeouts or orphaned URL proliferation that emerge gradually as search engines re-crawl the site under the new structure.
Save each major revision with a date stamp and a brief change note in the filename, like 'migration-checklist-2024-12-15-cdn-added.xlsx.' Maintain a changelog tab within the spreadsheet that lists what rows were added, removed, or modified and why. This history is critical if you need to explain timeline shifts to stakeholders or if a later issue traces back to a scope change that altered task sequencing.