A launch is the execution of a plan you’ve already tested. If Phases 1 through 7 were done properly, launch should feel controlled, not chaotic.
Create Final Backups
Before you deploy anything, take a fresh, complete backup of both sites:
- Your live Sitecore site: Exactly as it stands right now. Keep this backup of the live site and upload it to, let’s say, old.yourwebsite.com with HTTP auth enabled, password-protected, and SEO crawlers blocked completely so that it’s only accessible to a few people internally in your team. This will help you compare the WordPress site with the old Sitecore website. Keep it for a few months, until your WordPress website is stabilized, and then discard it.
- Your WordPress staging environment: The version you’ve tested and are about to launch.
When you have this saved, you have a rollback point to go back to if anything goes wrong during deployment.
Run a Delta Migration
Remember the content freeze from Phase 4? Even with a freeze in place, time has passed since your original content export.
A delta migration captures anything that changed on the live Sitecore site since your original export (an urgent update, a time-sensitive announcement) and brings just those changes into WordPress before you cut over.
This is a smaller, faster version of Phase 4’s export-and-import process, focused only on what’s new or changed.
Deploy the New Website
With final backups taken and any delta content merged in, deploy your tested WordPress site to your production environment. The specifics depend on your hosting setup, but generally this means either:
- Pointing your domain’s DNS to your new WordPress hosting environment, or
- Promoting your staging environment directly to live, if your host supports it
Do this during a planned low-traffic window, and have your team on standby, not scattered, for the first few hours after go-live.
Activate Redirects
Turn on the 301 redirect map you built in Phase 6. This step is time-sensitive. The moment your new site goes live, every old URL that isn’t redirected becomes a dead link, whether it’s a visitor clicking a bookmarked page or Google crawling a link it already knows.
Test a sample of redirects right after activation. Start with your highest-traffic pages from your original content inventory.
Submit Updated Sitemaps
As soon as the site is live, submit your new WordPress XML sitemap to Google Search Console and Bing Webmaster Tools.
The sooner search engines can crawl and re-index your new pages under their URLs, the sooner your search visibility stabilizes.
Verify Tracking and Monitoring Tools
Confirm that analytics, conversion tracking, and uptime monitoring are all live and reporting correctly:
- Check Google Analytics for real-time visitor data
- Submit a test form and confirm the conversion event fires
- Confirm your uptime monitoring tool (if you use one) is watching the new site, not still pointed at the old one
- Watch Google Search Console over the following days for crawl errors or sudden indexing issues
Problems tend to show up in the first 24 to 48 hours after launch. Have your team actively watching. That’s what catches a small issue before it grows into a real one.
What You Should Have When This Phase Is Done
By the end of Phase 8, you should have:
- Latest backups of both Sitecore and your WordPress staging environment
- Any last-minute content changes captured through a delta migration
- The WordPress site is fully deployed to production
- All redirects are live and spot-tested
- Updated sitemaps submitted to Google Search Console and Bing Webmaster Tools
- Analytics, conversion tracking, and monitoring confirmed working in real time
Your WordPress site is live. But launch day isn’t the finish line. It’s the start of a new phase, where the real work is watching, measuring, and fine-tuning what you’ve built.