Launch

The launch phase marks the final stretch of the AEM to WordPress migration journey. It’s where all the planning, development, and testing come together for a successful go-live. This stage includes the final deployment checklists, go-live procedures, and rollback plans.

Work on a deployment checklist

Your deployment checklist serves as pre-launch verification to ensure that everything is ready to go live. This includes reviewing key areas such as server settings, URLs, SEO, and site readiness before going from the staging environment to the live environment.

You can use this deployment checklist to build upon:

Domain configuration

Your domain is the gateway to your website, so it’s essential to ensure it’s properly configured:

• Ensure your domain’s A record is pointing to the correct IP address for your WordPress server.
• Double-check DNS propagation; changes might take up to 48 hours to reflect globally.

A common pitfall:

Rushing DNS changes without verifying can lead to downtime. Tools like What’s My DNS let you monitor the process and ensure everything is resolving correctly.

SSL certificate installation

An SSL certificate encrypts your site, making it safe for users to browse. Beyond security, HTTPS is also a trust signal. Users actually expect to see the padlock icon in their browser bar! So:

• Verify that your SSL certificate is installed and functioning correctly.
• Test URLs to ensure they redirect from HTTP to HTTPS without any issues.

Did you know?

Google flags non-HTTPS sites as “Not Secure,” which can harm your reputation and rankings. A quick SSL test ensures your site stays secure and professional.

Permalink and URL settings

Your URL structure defines how your content is accessed, and it needs to be clean, logical, and consistent. If your previous site had a different URL structure, it’s crucial to set up proper redirects to avoid broken links. We’ve actually already taken care of this during the migration. But link settings should still be checked before going live:

• Review Permalink Settings in WordPress to match your desired URL format.
• Test redirects for legacy URLs, ensuring no valuable SEO equity is lost.

Sampling for consistency

For large datasets, such as 10,000 blog posts, testing 5% for correct taxonomy mapping, media inclusion, and URL consistency before proceeding with the full migration ensures efficient validation.

Plugin and theme compatibility

Your plugins and theme power your site’s functionality and design, but compatibility issues can sometimes arise when moving from staging to production.

• Update all plugins to their latest versions and confirm compatibility with your WordPress version. (You’ve been working on your migration over months—did you miss any updates?)
• Check your theme’s responsiveness across browsers and devices.

Backup plan

Even with the best preparation, things can sometimes go wrong. A backup plan ensures that if the unexpected happens, you can quickly restore your site and minimize downtime.

• Create a full backup of your site, including files and the database.
• Store backups in multiple locations, such as on your server and in cloud storage.

A final staging review: A last-minute check-up

Before flipping the switch to go live, it’s good to give the staging site one final review:

• Remove any test content, such as placeholder posts or dummy data.
• Check key user flows, such as completing a purchase, submitting a form, or signing up for a newsletter.
• Confirm staging and production environments match, small differences can lead to big surprises after launch.

Tip: Having someone outside your team review the site can be invaluable. Fresh eyes often catch issues you might overlook during testing.

Document a go-live procedure

Go-live procedures cover the steps to make the site available for users, coordinate with relevant teams, and communicate the transition to all stakeholders. Here’s a procedure you could build upon:

Final server configuration

Before the big switch, the server needs to be fine-tuned to ensure it performs at its best under real-world conditions. The main focus here is on caching, database optimization, and ensuring everything runs efficiently.

Caching setup

Caching helps serve users quickly without reprocessing everything repeatedly. For this, both page caching and object caching need to be set up. Page caching saves a ready-to-serve version of each page, while object caching, using tools like Redis or Memcached, stores frequent database queries. This ensures visitors experience faster page loads. Review that caching is working correctly.

Database optimization

You don’t want your website to be bogged down by unnecessary clutter in the database. Running optimization commands, like OPTIMIZE TABLE, helps keep the database lean and efficient. It’s like tidying up your workspace so that everything is organized and accessible. Confirm that the database is optimized.

CDN integration

Finally, a Content Delivery Network (CDN), such as Cloudflare, needs to be integrated to speed up content delivery. A CDN ensures that all assets, like images and scripts, are served from a location closest to each user, providing a smooth experience regardless of where they are accessing the site from. Confirm if your CDN integration is working properly.

Switching from staging to production

Now comes the exciting part: moving from staging to the live production environment. This process ensures that what worked in the testing phase transitions smoothly to the real environment.

Back up before you move

Before making any changes, it’s important to create a complete backup of the staging site, including both the files and the database. This serves as a safety net—if anything goes wrong, we can quickly roll back and avoid downtime.

Update the DNS

The next step involves updating DNS records to point the domain name to the new production server. The DNS update may take anywhere between a few minutes to a couple of hours depending on your domain’s TTL (Time to Live) settings, so it’s good to be patient.

Replace staging URLs

After the DNS update, it’s crucial to replace any leftover URLs from staging with production URLs. This can be done easily using WP-CLI to search and replace all references, ensuring there are no broken links or image references that point to the staging environment. This guarantees that users will have a seamless experience without hitting any “not found” errors.

Activate SSL for security

We also need to activate the SSL certificate to make sure the website is accessible securely through HTTPS. This encrypts all data between users and your server, fostering trust and ensuring data privacy. 

Activate CDN and caching

Once the site is live, we need to ensure it’s running efficiently and delivering content quickly. Activating the CDN and setting up caching are the keys to making this happen.

Enable CDN for global reach

A CDN helps deliver images, scripts, and other resources quickly to users, no matter where they are. By serving static content from servers closest to users, the CDN greatly reduces load time, ensuring a snappy experience. If you’ve added a CDN to your setup, see that it’s enabled.

Set up page and object caching

Now, let’s make sure caching is properly enabled:

Page caching

It allows the server to serve pages instantly without recreating them every time.

Object caching

Using tools like Redis, stores database query results in memory so that future requests can be served faster.

Testing the caching

After enabling caching, it’s crucial to verify it’s working. A simple command like curl -I https://www.example.com can help check if headers such as Cache-Control or X-Cache are set correctly, indicating that caching is functioning as expected. Additionally, tools like GTmetrix or Pingdom can help assess the performance and verify that assets are being served from the CDN.

Create a rollback plan

Even with the most thorough planning, unexpected issues can arise once a website goes live. That’s why a solid rollback plan is essential. It provides a safety net that ensures you can revert to a stable version quickly if any issues occur. The goal of a rollback plan is not just to “go back,” but to do it efficiently, minimizing downtime and preserving data integrity.

Two key elements of a rollback plan

1. Backup verification

The first and most crucial part of the rollback plan is to verify your backups. Before launching, ensure that full backups of the website are available; this includes both the files and the database. It’s not just about creating a backup but also verifying its completeness and usability. These backups should be stored securely, ideally in multiple locations (local and cloud storage), so they can be accessed easily if needed.

Testing the restoration process is also key. A backup that can’t be restored effectively is as good as no backup at all. Perform a test restore in a sandbox environment to verify that the backup can be used without issues.

2. Reversion strategy: Planning the path back

The reversion strategy outlines the steps to follow if things don’t go as planned after the launch. The goal is to minimize disruption to users and bring the website back to a stable state as smoothly as possible. Here’s what your reversion strategy could look like:

• Restoring from a backup: If an issue arises, the most direct approach is to restore the backup taken from the staging or production environment. This ensures that the site reverts to its last known stable state. Using backup tools that support automated restoration can speed up this process and minimize downtime.
• Restoring to an earlier version using a version control system: If the issues relate specifically to some code or design changes, then reverting to a previous commit via a version control system like Git is an efficient approach. Rolling back to a stable commit is often faster and more controlled compared to restoring the entire site.
• Keeping the previous AEM environment on standby: During the initial days post-launch, it’s wise to keep a copy of the previous AEM environment readily available as a fallback. This way, if the new WordPress site experiences significant issues, the AEM site can be temporarily reinstated while you work on resolving problems. This serves as an ultimate failsafe, especially during the crucial early period when unexpected bugs or performance issues are most likely to surface.

With all these resources, you’re now ready to publish your new WordPress stack! Once you successfully launch your new WordPress website, you enter the post-migration phase.