AWS Hosting Migration for WordPress

Most WordPress sites we move to AWS are not moving because the owner loves AWS. They are moving because the current host has hit a ceiling: PHP workers max out at lunchtime, a 512 MB memory limit kills WooCommerce imports, or the managed host charges per visit and the bill has doubled. An AWS hosting migration for WordPress removes those ceilings, but only if the architecture is chosen for the site you actually run, not the one on a reference diagram.

symptoms that point to the host, not a plugin

Before we quote, we confirm the host is the bottleneck. The usual signs:

• Server response time (TTFB) above 800 ms even with page caching enabled and a plain theme.
• 503 errors or “Resource Limit Reached” pages under modest traffic, which means the PHP-FPM pool is exhausted.
• WP-Cron jobs, WooCommerce Action Scheduler queues or image regeneration that never finish because of a low max_execution_time.
• Backups that fail at the database step because wp_postmeta or wp_options has grown past what the shared MySQL server will export in one pass.

If the problem is the site itself, we say so and point you to Core Web Vitals optimization for WordPress or a database cleanup instead. Moving a slow site to a bigger box just makes it slow on a bigger box.

picking the right AWS services

There are three shapes we recommend, and the choice depends on traffic, budget and how much you want to manage.

• Lightsail for brochure sites and small shops: a fixed monthly price, a bundled static IP and snapshots. We replace the Bitnami stack with a plain Ubuntu, Nginx, PHP-FPM 8.3 and MariaDB build so it stays upgradable.
• EC2 with RDS for WooCommerce and membership sites: a t3 or t4g instance behind an Application Load Balancer, RDS for MySQL with automated snapshots, S3 for uploads through WP Offload Media, and CloudFront serving cached HTML and assets.
• Multiple instances in an Auto Scaling group only when traffic is genuinely spiky and the site has been made stateless, with sessions in ElastiCache Redis and uploads in S3.

We write down the monthly AWS estimate for each option using the AWS Pricing Calculator and your current bandwidth figures, so the decision is made on numbers rather than optimism.

how the move itself happens

The server is built with a repeatable script: Nginx with FastCGI cache, PHP-FPM tuned to the instance memory (pm.max_children set from real process size, not defaults), opcache enabled and a Redis object cache. We then copy the site while the old host is still serving traffic:

• rsync -avz --exclude wp-content/cache over SSH for files, run twice so the second pass only carries changes.
• mysqldump --single-transaction of the database, imported into RDS or local MariaDB, then wp search-replace for any path or protocol changes, with --dry-run first.
• Media offload to S3 with a bucket policy that allows CloudFront only, plus a one-off sync of the existing uploads folder.
• A hosts-file test of the new server on the real domain so you can click through checkout, forms and the admin before anyone else sees it.

For WooCommerce we schedule the final sync in a short maintenance window, put the old site into read-only with a maintenance page, take a last database delta and switch DNS in Route 53 with a 60-second TTL set the day before. Orders placed after cutover exist only on AWS; nothing is lost in between.

what you get after cutover

The migration is not finished at DNS. We hand over CloudWatch alarms for CPU, disk and 5xx counts, automated EBS or RDS snapshots on a schedule, a Let’s Encrypt or ACM certificate that renews itself, and security groups that expose only 80, 443 and an SSH port limited to your IP. Documentation covers how to log in, where logs live and how to restore. If you want offsite copies as well, our automated WordPress backup system setup adds versioned S3 backups with restore drills, and website maintenance and support keeps the OS, PHP and plugins patched afterwards.

timeline, risk and pricing

A single-site AWS hosting migration for WordPress onto Lightsail or one EC2 instance typically takes three to five working days from access to cutover. An EC2 with RDS, S3 and CloudFront build for a WooCommerce store runs one to two weeks, most of it testing. The old host stays untouched until you sign off, so the rollback is a DNS change back. We quote a fixed price after a short audit of the current site (size of uploads, database, plugins that write to disk, cron load) and the price does not change unless you change the scope. The AWS bill is yours directly; we set up the account or work inside your existing one with a scoped IAM user.

If you want the reasoning behind the service choices in more depth, the guide AWS Hosting Migration for WordPress: Lightsail vs EC2 vs Managed Hosting walks through the cost and effort of each path. When you are ready for a plan for your own site, send us the current host and a rough traffic figure and you will have a scope and a fixed price within 24 hours.