WordPress to AWS Migration: Practical Case Study

Migrating an existing WordPress website to Amazon Web Services (AWS) involves much more than copying files from one hosting account to another.

A complete WordPress migration can involve the database, themes, plugins, media files, DNS, IP addressing, HTTPS, backups, security and technical SEO.

In this practical case study, I document how I deployed a WordPress environment on Amazon Lightsail and prepared it for the migration of an existing WordPress website.

The objective was to create a straightforward AWS hosting environment without introducing unnecessary infrastructure complexity.

Project Overview

For this project, I wanted to move an existing WordPress website from traditional hosting into AWS.

Rather than changing the live domain immediately, I used a safer migration approach:

1. Create the AWS hosting environment.
2. Configure a static IP address.
3. Verify the WordPress installation.
4. Back up the existing website.
5. Migrate WordPress into AWS.
6. Test the migrated website.
7. Connect the production domain.
8. Configure HTTPS.
9. Perform technical SEO and post-migration checks.

This approach allows the existing website to remain available while the new AWS environment is prepared and tested.

Why I Chose Amazon Lightsail for WordPress

AWS offers several ways to host WordPress.

Amazon EC2 provides extensive control over the underlying infrastructure, but that control also means taking responsibility for more server administration.

Depending on the architecture, an EC2 WordPress deployment may involve manually managing:

• Linux
• Apache or Nginx
• PHP
• MySQL/MariaDB
• Networking
• Security groups
• File permissions
• SSL certificates
• Backups
• Server maintenance

For this project, I wanted a simpler deployment while still gaining hands-on AWS experience.

I therefore chose Amazon Lightsail.

Lightsail provides a more streamlined environment for deploying applications such as WordPress while still exposing important cloud concepts including compute resources, IP addressing, networking, DNS, snapshots and server access.

For portfolio websites, blogs and many small-business WordPress websites, this can be a practical starting point.

WordPress AWS Hosting Architecture

The infrastructure can be understood through the following layers.

Keeping the architecture relatively simple makes the deployment easier to maintain while still providing practical exposure to AWS infrastructure.

Step 1: Back Up the Existing WordPress Website

Before beginning any WordPress migration, creating a complete backup is essential.

A WordPress website contains much more than visible pages.

The migration needs to account for:

• WordPress database
• Pages and posts
• Media library
• Themes
• Plugins
• Navigation menus
• Users
• Theme settings
• Page-builder layouts
• Plugin configuration
• SEO metadata
• Redirects

The backup also provides a recovery point if something goes wrong during the migration.

For a straightforward WordPress migration, tools such as All-in-One WP Migration or Duplicator can simplify this process.

The original hosting should remain active during the migration rather than being cancelled immediately.

Step 2: Create the WordPress Instance in Amazon Lightsail

The next stage was creating the AWS environment.

I created a WordPress instance in Amazon Lightsail using a Linux-based WordPress configuration.

For this deployment, the instance was created in the AWS Sydney Region (ap-southeast-2).

The Lightsail instance provides the infrastructure required to run WordPress, while AWS provides a management interface for the server.

My instance configuration included:

This provided a practical environment for the WordPress migration.

Step 3: Assign a Static IP Address

One of the important networking steps was assigning a static IPv4 address to the Lightsail instance.

A production website should not depend on a temporary IP address that could potentially change.

The static IP provides a consistent destination that can later be associated with the production domain through DNS.

After configuration, the Lightsail console confirmed that the WordPress instance was running successfully with its static IP attached.

My Amazon Lightsail WordPress Deployment

Figure 1: My WordPress instance running on Amazon Lightsail with a static IPv4 address configured in the Sydney AWS Region.

Recommended image alt text:

WordPress website deployed on Amazon Lightsail with static IP

This screenshot demonstrates the actual AWS environment used during the project, including the WordPress instance, Sydney region, static IP configuration and running instance status.

Step 4: Verify WordPress Before Migration

Before importing the existing website, I first verified that the new WordPress installation was working correctly.

The server could initially be accessed through its public IP address.

For example:

http://SERVER-IP

The WordPress administration area could similarly be accessed through:

http://SERVER-IP/wp-admin/

At this stage, using HTTP for temporary IP-based testing is acceptable.

The final production configuration should use the real domain with HTTPS.

The initial checks included:

• Lightsail instance is running
• Public IP responds correctly
• WordPress loads
• WordPress Admin is accessible
• PHP is functioning
• Database connectivity is working

Completing these checks before migration makes troubleshooting easier because it establishes that the underlying WordPress environment is functioning.

Step 5: Export the Existing WordPress Website

Once the AWS environment was ready, the existing WordPress website could be prepared for migration.

A migration plugin can package the important components of the website, including:

• Database
• Pages
• Posts
• Images
• Themes
• Plugins
• WordPress configuration
• Theme settings
• Plugin settings

The resulting migration backup should be stored safely until the entire deployment has been verified.

For larger WordPress websites, the migration process may require a different approach depending on upload limits, database size and hosting configuration.

Step 6: Import the Existing Website into AWS

The corresponding migration plugin can then be installed on the new AWS WordPress environment.

The existing website backup can be imported into the Lightsail WordPress installation.

After importing, the website should be checked carefully.

Important areas include:

• Homepage
• Pages
• Blog posts
• Images
• Navigation
• Theme
• Plugins
• Forms
• Page-builder layouts
• WordPress users
• SEO configuration

It is also important to remember that importing the original database may restore the administrator credentials from the original website.

Step 7: Check WordPress URL Configuration

One of the more interesting technical areas during a WordPress cloud migration is URL configuration.

WordPress may temporarily reference addresses such as:

http://127.0.0.1

or:

http://SERVER-IP

These should not become the permanent public URL of the website.

Once the production domain is connected, WordPress should ultimately use an address such as:

https://example.co.nz

Important settings to verify include:

• WordPress Address
• Site Address
• WP_HOME
• WP_SITEURL
• Internal links
• Media URLs
• Canonical URLs
• Redirects

Incorrect URL configuration can result in problems such as redirect loops, broken images, incorrect links or inaccessible WordPress administration pages.

This was an important reminder that WordPress configuration and AWS server configuration are separate layers that need to work together.

Step 8: Test Before Changing DNS

The production domain should not be moved to AWS simply because the migration has completed.

The migrated website should first be tested.

Content Checks

Check:

• Homepage
• About page
• Service pages
• Portfolio
• Blog posts
• Contact page
• Images
• Navigation

WordPress Checks

Verify:

• Admin login
• Theme
• Plugins
• Media library
• Forms
• Page builder
• Permalinks

Technical Checks

Review:

• Database connectivity
• PHP functionality
• File permissions
• Internal URLs
• Redirects
• Mobile responsiveness
• Basic website performance

Keeping the original hosting active during this stage provides a fallback if problems are discovered.

Step 9: Connect the Domain to AWS

Once the migrated website has been verified, the production domain can be directed to AWS.

The DNS configuration will typically use an A record pointing the root domain to the Lightsail static IP.

An example configuration is:

The www hostname also needs to be configured appropriately.

For example:

The exact configuration depends on the DNS provider and the preferred domain structure.

DNS changes may also require some time to propagate.

Step 10: Configure HTTPS

HTTPS is essential for the production website.

During the initial setup, the AWS instance may be tested using:

http://SERVER-IP

However, the final production website should use:

https://example.co.nz

The SSL/TLS certificate should be configured for the production domain.

After HTTPS is enabled, I recommend checking:

• HTTPS loads successfully
• HTTP redirects to HTTPS
• Root domain works
• www version behaves correctly
• WordPress Address uses HTTPS
• Site Address uses HTTPS
• Images load over HTTPS
• CSS and JavaScript load correctly
• No mixed-content warnings exist
• Canonical URLs use HTTPS

The goal is to establish one consistent version of the website for users and search engines.

Step 11: Check Permalinks and Redirects

WordPress permalinks should also be verified after migration.

In WordPress:

Settings → Permalinks

The existing permalink structure should normally be preserved.

Important URLs should then be tested manually.

For example:

/

/about/

/contact/

/blog/

/services/

Where possible, the existing URL structure should remain unchanged.

A hosting migration does not normally require changing page URLs.

Preserving URLs reduces the risk of broken links, unnecessary redirects and loss of existing organic search visibility.

Step 12: Perform Technical SEO Checks

As an SEO practitioner, I consider technical SEO verification an important part of the migration rather than a separate task.

A website can technically load successfully after migration while still having SEO problems.

Indexability

Check:

WordPress → Settings → Reading

Make sure the production website is not unintentionally configured to discourage search engines from indexing it.

Canonical URLs

Canonical tags should reference the correct production HTTPS URLs.

Temporary IP addresses or old hosting URLs should not appear in canonical tags.

XML Sitemap

Verify that the XML sitemap loads correctly and contains the correct production URLs.

Robots.txt

Review robots.txt to ensure important pages and resources are not unintentionally blocked.

Redirects

Check:

• HTTP to HTTPS
• www to non-www, or the reverse
• Existing 301 redirects
• Old URLs
• Trailing-slash behaviour

Google Search Console

After the migration, Google Search Console can be monitored for:

• Indexing issues
• Crawl errors
• Sitemap problems
• Canonicalisation issues
• Changes in indexed pages

Analytics

Google Analytics 4 and Google Tag Manager should also be tested to ensure tracking continues after the hosting change.

Step 13: Test WordPress Performance

Migrating WordPress to AWS does not automatically make the website fast.

Performance still depends on:

• WordPress theme
• Page builder
• Plugins
• Images
• Database queries
• PHP processing
• JavaScript
• CSS
• Fonts
• Caching
• Server resources

After migration, I would therefore review:

• Image optimisation
• Page caching
• Browser caching
• Unnecessary plugins
• Database optimisation
• JavaScript execution
• CSS delivery
• Font loading
• Core Web Vitals

A CDN can also be considered if the website's traffic and geographic audience justify it.

Step 14: Configure Backups and Recovery

Hosting WordPress in AWS does not remove the need for backups.

A production website needs a recovery strategy.

AWS Lightsail snapshots can provide an additional recovery layer alongside WordPress-level backups.

The important question is not simply whether a backup exists.

The important question is whether the website can actually be restored from it.

Step 15: Review Security

AWS provides the hosting infrastructure, but WordPress security still requires ongoing management.

Important practices include:

• Keep WordPress updated
• Update plugins
• Update themes
• Remove unused plugins
• Remove unused themes
• Use strong administrator credentials
• Minimise administrator accounts
• Use HTTPS
• Maintain regular backups
• Restrict unnecessary server access
• Review network configuration
• Monitor suspicious activity

Moving WordPress to AWS should therefore be considered a change in hosting infrastructure, not a replacement for WordPress security practices.

Challenges and Lessons Learned

One of the most valuable parts of this project was understanding the relationship between WordPress and the infrastructure underneath it.

For example, I encountered WordPress URL configuration involving:

WP_HOME

and:

WP_SITEURL

During troubleshooting, temporary addresses such as 127.0.0.1 and the public server IP also became relevant.

This highlighted an important distinction between:

Understanding these layers made troubleshooting much easier.

File permissions were another useful learning area. WordPress, Linux and command-line tools may have different permission requirements when configuration files need to be changed.

These challenges made the migration more valuable as a practical cloud deployment exercise.

Skills Demonstrated in This Project

This project brought several areas of my web development experience together.

AWS & Cloud

• Amazon Lightsail
• Cloud server deployment
• Static IPv4 configuration
• AWS regions
• Networking concepts
• DNS
• SSL/TLS
• Server access
• Snapshots and recovery planning

WordPress

• WordPress migration
• Database migration
• Themes and plugins
• Media migration
• WordPress configuration
• Permalinks
• Troubleshooting
• Backup and recovery

Technical SEO

• URL preservation
• HTTPS migration
• Redirect verification
• Canonical URLs
• XML sitemaps
• Robots.txt
• Search Console
• Analytics verification
• Post-migration monitoring

This is what makes the project useful to me as a developer: it combines WordPress development, AWS cloud infrastructure and technical SEO rather than treating them as completely separate disciplines.

WordPress to AWS Migration Checklist

Here is the workflow I would use for a controlled WordPress migration.

When Should the Old Hosting Be Cancelled?

Not immediately after changing DNS.

Before decommissioning the old hosting environment, I would verify that:

• The domain resolves to AWS
• HTTPS works
• Important pages load
• Images load
• Forms work
• WordPress Admin works
• Redirects work
• Analytics is receiving data
• Search engines can access the site
• Backups are available
• Email functionality works where applicable
• No important resources still depend on the old server

Only after these checks should the old hosting environment be removed.

Final Thoughts

This WordPress-to-AWS project demonstrated that a website migration is not simply a file-transfer exercise.

A successful migration requires coordination between WordPress, cloud infrastructure, networking, DNS, HTTPS, security, performance and SEO.

For this deployment, Amazon Lightsail provided a manageable way to gain practical AWS experience without introducing unnecessary infrastructure complexity.

The project also reinforced one of the most important lessons in website migration:

The migration is not finished when the website has been copied to the new server. It is finished when the website, domain, HTTPS, redirects, SEO, analytics, security and recovery process have all been verified.

For me, this was also a useful step in expanding my WordPress development experience into practical cloud deployment and AWS infrastructure.