Those submissions went to the old server. It was still answering for a slice of the internet twenty hours after the DNS change, and by then I had already stopped syncing it.

That is the failure that separates a bulk WordPress migration from moving a single site. When you move one site you watch it. When you move twenty in a weekend, you are running a pipeline, and the things that go wrong are the ones nobody is watching: writes landing on a server you have mentally decommissioned, cron firing on two boxes at once, a certificate that never issued because a DNS record was still pointing at the old IP when the challenge ran.

This is the process I use for fleet moves onto a single VPS: the manifest that makes the weekend repeatable, the two-pass sync, the database step people rush, the certificate limits that bite specifically at fleet scale, and a cutover order that keeps rollback cheap. It assumes SSH on both boxes and some comfort on the command line.

The failure that actually costs you: writes landing on the old server

Every migration guide tells you to lower your TTL. Almost none of them tell you what happens in the gap afterwards, and the gap is where the money goes.

Here is the mechanism. You change the A record. Most resolvers pick up the new IP inside the TTL window. Some do not: corporate resolvers that clamp minimum TTLs, ISP resolvers that ignore short values, browsers holding a connection open, a mail server that resolved the host an hour ago. For those clients, the old server is still the site. It still has a working database. It still accepts comments, form entries, orders, user registrations and password resets.

Nothing errors. Nothing logs. The write succeeds on a database you are about to throw away.

There are only two honest answers to this, and picking one per site is the first real decision of the weekend.

• Accept the loss. Fine for brochure sites, documentation, most blogs. A missed comment is not a business problem.
• Make the old server read-only the moment DNS changes. Mandatory for anything with a checkout, a booking flow, a members area or a lead form that feeds a sales process.

Read-only in practice means maintenance mode on the old copy, a static holding page on the old vhost, or pointing the old install’s wp-config.php at a database user with SELECT only. Any of those turns silent data loss into a visible error the visitor can react to. Someone who sees “temporarily unavailable” comes back. Someone whose order vanished does not.

Do not skip this because the old server “will be off soon”. The window between DNS change and old server shutdown is the longest, least supervised part of the whole weekend.

Build the fleet manifest before you touch a server

Twenty sites is the point where memory stops working. You will not remember which one runs an old PHP branch, which one has a hardcoded absolute path in a theme, which one has MX records pointing somewhere else entirely.

So the first artifact is a table. One row per site, filled in before anything moves.

• Document root and database name
• Current siteurl and home values, exactly as stored
• PHP version the site currently runs under
• Disk size of the document root and dump size of the database
• Where DNS is authoritative, and who holds the login
• Whether mail for that domain is on this server or elsewhere
• Does it take writes from the public: comments, forms, checkout, registration
• Cache and object cache in use
• Cutover batch number and rollback owner

Most of that you can pull off the old server rather than typing it. This walks a DirectAdmin-style layout and prints a tab-separated line per WordPress install:

for d in /home/*/domains/*/public_html; do
  [ -f "$d/wp-config.php" ] || continue
  printf '%st%st%sn' 
    "$d" 
    "$(wp --path="$d" option get siteurl --skip-plugins --skip-themes 2>/dev/null)" 
    "$(du -sh "$d" | cut -f1)"
done

The --skip-plugins --skip-themes flags matter here. Without them WP-CLI boots the full site, and one broken plugin on one install will stop your inventory halfway through with a fatal error.

The DNS column is the one people fill in last and regret. Check where each zone actually lives before the weekend, not during it. A domain whose nameservers point at Cloudflare while you are editing records in the old host’s DNS panel will not move no matter how many times you refresh.

Rebuild the stack, don’t clone the disk

There is a tempting shortcut where you image the old server and restore it onto the new one. It usually works and it is usually the wrong call, because you have just carried across every accumulated fix, every orphaned config, and every reason the old box got slow enough to need replacing.

Build the destination clean. Whatever the provider is, whether that is Contabo, InterServer, Hetzner or a machine you already have, the sequence is the same: base OS, web server, PHP with the version and extensions the manifest says you need, database server, control panel if you use one, firewall, then a hardening pass.

Two things to get right before any files land.

PHP versions. If three sites need an older branch and seventeen are happy on current, install both and make the per-site assignment explicit in the manifest. Discovering the mismatch after cutover means a white screen on a live domain instead of a note in a spreadsheet. Check the extension list too, not just the version number, because imagick, soap and intl are the usual absentees.

Access during the weekend. If you lock SSH and the control panel behind an IP allowlist, decide beforehand what your source address will be. A rotating home IP is how people lock themselves out of their own migration at two in the morning. A dedicated-IP option from a VPN provider such as NordVPN or Surfshark gives you one stable address to allowlist; a second admin path on a non-standard port works too. Deciding at the moment you are locked out does not.

Two-pass rsync beats one big copy

The mistake at fleet scale is treating the file copy as a cutover-day task. Copy everything on cutover day and your maintenance window is however long twenty document roots take, which for a media-heavy fleet is hours you do not have.

Split it. Do a warm sync days in advance while both sites are live, then a delta sync at cutover that moves only what changed.

Warm sync, run from the old server, no deletes:

rsync -aHAX --numeric-ids --info=progress2 
  -e "ssh -p 22" 
  /home/user/domains/example.com/public_html/ 
  root@NEW_SERVER_IP:/home/user/domains/example.com/public_html/

What those flags buy you: -a preserves permissions, times, symlinks and ownership; -H keeps hard links, which some backup plugins and dedup schemes rely on; -A and -X carry ACLs and extended attributes; --numeric-ids stops rsync remapping ownership through name lookups when the UIDs differ between boxes, which is exactly what happens when the new server creates users in a different order.

Delta sync at cutover, same command with one addition:

rsync -aHAX --numeric-ids --delete --info=progress2 
  -e "ssh -p 22" 
  /home/user/domains/example.com/public_html/ 
  root@NEW_SERVER_IP:/home/user/domains/example.com/public_html/

--delete removes files on the destination that no longer exist on the source. It is what makes the second pass an accurate mirror rather than a merge of two states. It is also the flag that will destroy your afternoon if you get the paths wrong, so check the trailing slashes: a source path ending in a slash copies the contents of the directory, one without it copies the directory itself, one level deeper than you meant.

Run the delta pass once with --dry-run before running it for real. And on SELinux systems, relabel the tree afterwards: files arriving over rsync carry contexts the web server may not accept, and that produces a 403 which has nothing to do with permission bits.

Databases last, and never with sed

Files can be stale for a few days. Databases cannot. Dump each database as late as you reasonably can, immediately before that site’s cutover, not on Friday for a Sunday move.

# on the old server, per site
wp --path=/home/user/domains/example.com/public_html db export 
  /root/migration/example.com.sql --skip-plugins --skip-themes

Import on the new box, then handle URLs. If the domain is not changing, you may have nothing to replace. If the site is moving from HTTP to HTTPS, or from a staging hostname, or from a temporary preview domain you used for testing, you do.

The rule that matters: do not run a find-and-replace over the SQL file with sed. WordPress stores widget settings, theme options, page builder layouts and plugin config as PHP serialized arrays, and every serialized string carries a byte-length prefix. Change the string without recalculating the prefix and the array fails to unserialize. The site does not error loudly. It loses its widgets, or its theme options revert to defaults, or the page builder renders an empty page.

WP-CLI unserializes, replaces and reserializes, which is why it is the only tool I use for this.

wp search-replace 'http://example.com' 'https://example.com' 
  --all-tables-with-prefix 
  --precise 
  --skip-columns=guid 
  --report-changed-only 
  --dry-run

Read the dry-run output before you commit. Each flag earns its place: --all-tables-with-prefix catches plugin tables that share your prefix and would otherwise be skipped, --precise forces a full unserialize pass on every column instead of the faster string-level path, and --skip-columns=guid leaves the GUID column alone because feed readers use it as an identifier, not as a URL to fetch. Drop --dry-run to apply.

Flush the object cache afterwards if the site uses one. A stale Redis or Memcached entry will happily serve you the old values and convince you the replacement failed.

TLS at fleet scale: where Let’s Encrypt rate limits actually bite

Twenty certificates in one weekend is where a limit you have never noticed becomes the thing that blocks you.

Let’s Encrypt publishes its limits and they are worth reading properly before a fleet move. Two of them are the ones that catch migrations.

• New certificates per registered domain. Up to 50 certificates per registered domain every 7 days, counted globally across all accounts. If your twenty sites are twenty separate registered domains, you are nowhere near it. If they are subdomains of one or two parent domains, which is common for an agency fleet, you can burn through it.
• Authorization failures per identifier per account. Up to 5 failures per hostname per account per hour, refilling at one every 12 minutes. This is the one that actually bites, because it is triggered by the exact thing you are doing: requesting a certificate for a hostname whose DNS still points at the old server, so the HTTP-01 challenge is served by the wrong machine and fails.

Order matters as a result. If you issue before DNS moves, HTTP-01 fails. If you issue after DNS moves, visitors hit a certificate error in the gap. Three ways out, in the order I reach for them:

1. DNS-01 validation. Proves control through a TXT record instead of an HTTP request, so it does not care where the A record points. You can issue every certificate before touching DNS. This is the clean answer if your DNS provider has an API your ACME client supports.
2. Cut DNS first, issue immediately after. Simple, and the exposure is short if you are watching. Batch it so you are never waiting on twenty challenges at once.
3. Copy the existing certificates and keys across. Buys you a bridge until the new server can renew on its own. Only viable if you control the old server’s filesystem and the certificates have real time left.

Whichever you choose, test the plumbing against the staging environment first. Most ACME clients expose this as a dry-run mode, and it exists precisely so you can fail as many times as you like without spending production budget.

One more thing that catches people: if any site has HSTS enabled with a long max-age, browsers that have seen it will refuse to fall back to HTTP. There is no grace period and no way to talk them out of it. Those sites need a valid certificate on the new server from the first request, which pushes them firmly toward DNS-01 or a copied certificate.

Planning the cutover order for a bulk WordPress migration

Do not move twenty sites at once. Batch them, and batch by risk rather than alphabetically or by size.

1. Batch one: the throwaways. Two or three low-traffic sites you own or that nobody would notice. This batch exists to prove the stack, not to make progress.
2. Batch two: the ordinary majority. Standard brochure and content sites, no checkout, no logins that matter.
3. Batch three: the ones with writes. Stores, membership sites, anything with a form feeding a sales process.
4. Batch four: the awkward ones. Custom stacks, odd PHP requirements, third-party integrations that whitelist your server IP.

Stop between batches. Look at the error logs on the new server, not just the homepages. Twenty sites failing the same way is one problem; catching it after three is a fifteen-minute fix, catching it after twenty is a rollback.

The per-site sequence inside a batch:

1. Drop the TTL on that domain’s records to a low value, at least a day ahead.
2. Run the delta rsync.
3. Dump, transfer and import the database.
4. Run search-replace if the URL is changing at all.
5. Test through a hosts-file entry or a resolved request, before DNS moves.
6. Change the A and AAAA records.
7. Put the old copy read-only.
8. Verify from outside, then move to the next site.

Step five is the one people skip and should not. You can send a request to the new server as if DNS had already changed, without changing anything:

curl -sSI --resolve example.com:443:NEW_SERVER_IP https://example.com/
curl -sS --resolve example.com:443:NEW_SERVER_IP https://example.com/wp-login.php | head -n 20

That gives you real status codes, real redirects and a real TLS handshake against the new box while the live site is untouched. If that returns a 301 loop or a 500, you have found it before any visitor did.

Cron, email, and the things that run twice

During the overlap window you have two live copies of every site. Both have a database. Both have a scheduler.

WordPress schedules through wp-cron.php, fired by visitor traffic. The old server still gets traffic, so it still fires cron, so it still sends the newsletter, still processes the subscription renewal, still runs the backup plugin. Subscribers get things twice. Worse, the site’s system crontab came across in your file sync and is now also running on the new box.

Handle it explicitly. On the old copy, disable the loopback scheduler when you make it read-only:

define( 'DISABLE_WP_CRON', true );

And on the new server, set up a real system cron per site rather than leaving it to traffic, because a site with no traffic yet has no scheduler at all:

wp --path=/home/user/domains/example.com/public_html cron event run --due-now

Wrap that in a cron entry or a systemd timer at whatever interval the site needs, and check wp cron event list before assuming nothing important is queued.

Email is the parallel problem and it fails quietly in the other direction. Your sites now send from a new IP. If SPF still authorizes only the old server’s address, and DKIM keys did not come across, and DMARC is set to anything stricter than none, your transactional mail starts landing in spam. Nothing bounces visibly. Password resets just stop arriving and you hear about it in support tickets a week later.

Three records to check per domain. MX is the one not to touch casually: if mail lives elsewhere and you replace a zone wholesale, the mailboxes go with it.

• MX: unchanged unless mail is genuinely moving with you.
• SPF: add the new server’s IP before cutover, remove the old one after the overlap window closes, not during.
• DKIM: keys are per-server. Either copy them or regenerate and publish the new public key.

The more resilient answer is to stop sending through the server at all. Routing WordPress mail through an authenticated SMTP relay means outbound deliverability stops depending on which machine the site happens to live on, which makes the next migration a non-event.

Troubleshooting the weekend

Redirect loop on the new server. Usually siteurl and home disagreeing with what the vhost or reverse proxy is doing about HTTPS. Check both values with wp option get siteurl and wp option get home. If the site sits behind a proxy or CDN that terminates TLS, WordPress may see HTTP on the back end and redirect forever.

Site loads, media does not. Either uploads did not finish syncing, ownership is wrong, or database paths still reference the old host. Compare a file listing on both sides before assuming it is a database problem.

Widgets or theme options empty after import. This is the serialization damage described earlier. It is not recoverable by re-running the replacement. Restore the database from the dump and redo the URL change with WP-CLI.

Certificate issuance failing repeatedly. Confirm what the challenge is actually hitting before retrying, because each failure spends part of your hourly authorization budget.

dig +noall +answer example.com A
dig +noall +answer @1.1.1.1 example.com A
openssl s_client -connect NEW_SERVER_IP:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -dates

The first query uses your local resolver, the second asks a public one directly, and the difference between them tells you whether you are looking at a real propagation state or your own DNS cache.

Site fine, admin slow. Often a plugin trying to reach an external service that whitelisted the old IP. Look for API integrations, license checks and payment gateways in the manifest’s awkward-ones column.

Common mistakes

• Lowering TTL on cutover day. The old value is still cached; the change has no effect for as long as the old TTL says.
• Cancelling the old server as soon as the sites load. Keep it running, read-only, for the whole overlap plus a margin. It is your rollback.
• Replacing an entire DNS zone instead of editing the A record, and taking MX, SPF and verification TXT records with it.
• Running search-replace before importing, or on the SQL file instead of the live database.
• Testing only the homepage. Homepages are static and cached. Test a login, a form submission, an admin page and an uploaded image.
• Leaving both schedulers live and finding out through duplicate customer emails.
• Assuming the new server’s PHP extension set matches the old one because the version number does.
• Treating rollback as a fleet-level decision. Per-site rollback is what keeps one bad site from stalling nineteen good ones.

Best practices for a fleet move

• Write the manifest first and update it as you go. It is the migration record and the handover document.
• Take a restorable backup of each site to somewhere off both servers before you start, and test restoring one. A backup you have not restored is a hypothesis.
• Warm sync early, delta sync at cutover, dump databases last. Batch by risk, and prove the stack on sites nobody will miss.
• Verify every site from outside with a resolved request before its DNS moves.
• Point uptime monitoring at the new IP before cutover, not after. UptimeRobot or Better Stack will tell you about a broken site faster than the client will.
• Make the old copy read-only at the moment of DNS change, not at the end of the weekend.
• Keep a rollback note per site: which records changed, what they were before, who can revert them.
• Re-check cache configuration after the move rather than assuming it carried over, whether that is WP Rocket, WP Fastest Cache or a server-level layer.
• Retire the old server on a scheduled date with a final archived backup, not by forgetting to renew it.

Frequently asked questions

Is a bulk WordPress migration of 20 sites realistic in one weekend?

Yes, if the preparation happens in the week before. The weekend itself should be delta syncs, database moves and DNS changes. If you are still installing PHP extensions on Saturday morning, the weekend is not long enough.

How low should I set the TTL, and how far ahead?

A low value like 300 seconds, set at least 24 to 48 hours before cutover so the previous TTL has fully expired everywhere. Going much lower than 300 buys little and increases query load. Raise it back after the migration settles.

Will moving hosts hurt my search rankings?

Changing the server behind an unchanged domain is not itself a ranking event. What hurts is what goes wrong during it: 5xx responses while crawlers visit, failed certificates, redirect loops, a staging copy left indexable. Keep URLs identical, keep the site responding, and check Search Console afterwards.

Can I use a migration plugin instead of the command line for this?

For one site, plugins are a reasonable choice and handle serialized data correctly. At twenty the arithmetic changes: twenty manual export and import cycles through a browser, with no dry run and no delta sync. The command line is repeatable and scriptable, which is the point at fleet scale.

How long should I keep the old VPS running?

At least a week after the last site cuts over, in read-only mode. Some problems only appear over a full traffic cycle: weekly scheduled jobs, integrations that call in periodically, mail arriving at the old MX. Keep an archived backup after you destroy it.

What if one site breaks after cutover?

Revert that site’s A record and lift the read-only restriction on the old copy. That is why the old server stays up and why rollback is per site. If you sync the database back afterwards, be careful not to overwrite writes that landed on the new server in the meantime.

Do I need to move email at the same time?

No, and separating them is usually wiser. Move web first, confirm it is stable, then plan mailbox migration as its own change with its own window. Combining them means a single mistake in one DNS zone takes down both.

The one thing worth remembering

A bulk WordPress migration is not twenty small migrations. It is one process run twenty times, and the difference is that at scale the visible failures get caught while the invisible ones do not.

The copy is the easy part. rsync and WP-CLI are reliable, well documented and boring. What costs you is the overlap window: two servers both answering, both writing, both scheduling, for hours after you have mentally finished. Decide before the weekend what happens to writes on the old server, make that decision per site, and act on it at the moment DNS changes rather than at the end.

Do that, batch by risk, and keep a rollback that works at the level of a single site, and twenty sites in a weekend is an ordinary piece of work rather than a gamble.

Need help moving a fleet of sites?

Migrations are a good thing to have a second pair of hands on, because the expensive mistakes are the quiet ones. This is work I do regularly:

• Auditing an existing fleet and producing the migration manifest, batch order and rollback plan before anything moves
• Provisioning and hardening the destination VPS, including multiple PHP versions, control panel setup and firewall rules
• Running the sync and database cutover with WP-CLI, including URL replacement on serialized data
• Planning TLS issuance around ACME rate limits, including DNS-01 validation and automated renewal
• Sorting out post-migration email: SPF, DKIM, DMARC and moving transactional mail onto an authenticated relay
• Sitting in as the on-call engineer for the cutover window itself, or reviewing a plan you have already written

If you are planning a move and something in it worries you, send me the concrete thing: the site list, the current vhost config, the rsync output, the certbot error. I would rather look at the actual output than talk in general terms.

The post Bulk WordPress Migration: Moving 20 Sites to a New VPS in One Weekend appeared first on John Nessime.

The instance snapshot exported fine. The managed database did not. Neither did the load balancer, the CDN distribution, the static IP, or the DNS zone. AWS documents this plainly: the export feature covers instance snapshots and block storage disk snapshots, and nothing else. Every other piece had to be rebuilt by hand, and a maintenance window turned into an afternoon.

That is the part nobody prices in. When you choose compute for a small client workload, you are not just choosing where the process runs. You are choosing how much of the platform you will have to recreate when the client grows, leaves, or hands the account to somebody else.

This post compares Lightsail vs EC2 vs ECS for small client work: single sites, small APIs, internal tools, the kind of thing that runs on one or two boxes with no dedicated ops team behind it. Each option gets a profile with where it wins and where it doesn’t, then a decision procedure, then the arguments I hear most often that fall apart on contact with a real project.

Why the exit path matters more than the launch

All three services will host a small workload. The launch is not the hard part. What separates them is what happens eighteen months later when the requirements change.

Lightsail is the clearest case because its boundaries are documented. Instance and disk snapshots export to EC2 as an AMI and EBS snapshots. Managed databases, container services, distributions, load balancers, static IPs, and DNS records do not export at all. AWS also warns that a Linux instance built from an exported Lightsail snapshot can carry residual SSH keys from the Lightsail service, which you should remove.

So the question is not “which is cheapest for a small site.” It is “how much of this stack is portable, and who operates it after handover.”

Amazon Lightsail: where it wins and where it doesn’t

Lightsail bundles compute, SSD storage, and a monthly data transfer allowance into one flat plan price. There are no separate line items for the instance, the volume, and the egress. For a client who wants to know what the bill will be, that is worth a lot more than a theoretical discount.

Where it wins

• Predictable billing. One number per month, plus egress overage only if you blow through the allowance. Easy to quote, easy to hand to a client.
• The data transfer allowance is generous for content sites. Inbound and outbound both count toward it, but only outbound overage is billed, and transfer between Lightsail resources over private addresses in the same region is free.
• Console surface small enough to hand to a non-engineer. A client can restart an instance or take a snapshot without you, and without an IAM policy discussion.
• IPv6-only bundles exist and cost less than the IPv4 equivalents, which is a real saving if the workload sits behind Cloudflare or another proxy anyway.

Where it doesn’t

• Networking is deliberately shallow. Lightsail resources live in a Lightsail-managed VPC, and connecting to the rest of AWS means enabling VPC peering with the default VPC in the same account and the same region. Not a custom VPC. Not another account.
• Peering is a region-level switch, not a per-instance setting, and the CIDR ranges must not overlap. The route table on the Lightsail side is managed by AWS and you cannot edit it.
• The exit is partial, and the instance type list is short. There is no picking a memory-optimized family because the workload turned out to be memory-bound.
• No Savings Plans, no Reserved Instances, no Spot. The flat rate is the rate.

Worth saying plainly: if all you want is a flat-rate box, Lightsail competes with plain VPS hosts as much as with EC2. Providers like Contabo and InterServer sell the same shape of product, often with more RAM per unit of spend. Lightsail’s edge is that it sits inside an AWS account, so IAM, billing, and eventual migration to EC2 stay in one place. If the client will never touch another AWS service, that edge is worth less than it looks.

Amazon EC2: where it wins and where it doesn’t

EC2 is the general case: a real VPC, real subnets, real security groups, and every instance family AWS sells. You also get to build all of that yourself.

Where it wins

• Instance selection. If profiling shows the workload is memory-bound rather than CPU-bound, you change families instead of buying a bigger everything. For a PHP or Node app with an ARM-clean dependency tree, the Graviton families are usually the easiest price-performance win on the table.
• Commitment discounts. Savings Plans and Reserved Instances make a steady 24/7 workload meaningfully cheaper, and Spot makes non-critical work cheaper still.
• Full networking. Custom VPCs, private subnets, VPC endpoints, cross-account peering, Transit Gateway. If the client already has an AWS footprint, EC2 joins it without a workaround.
• Systems Manager. Session Manager gives you shell access without opening port 22 to the internet, and Patch Manager gives you a defensible patching story at handover. If you would rather have a private network path to admin interfaces than an AWS-native one, something like NordLayer or a self-hosted WireGuard box fills the same slot.

Where it doesn’t

• Every component is billed and configured separately: instance, EBS volume, snapshots, egress, Elastic IP, load balancer. The bill has more surface area, and so does the misconfiguration.
• Public IPv4 addresses are billed per hour, including on running instances. On a fleet of one that is noise. Across a dozen small instances it stops being noise.
• Data transfer out to the internet is metered per GB with no bundled allowance. A media-heavy site that would sit comfortably inside a Lightsail plan can produce a surprising egress line on EC2.
• You own the operating system: patching, kernel updates, log rotation, backup verification. Billable work if you are the consultant, abandoned work if you are not.

The mitigation for the egress point is the usual one: put a CDN in front. CloudFront or Cloudflare both change the shape of that bill substantially, because most bytes stop leaving the origin at all.

Amazon ECS: where it wins and where it doesn’t

ECS is two different products wearing one name, and conflating them is where most of the confusion comes from.

• ECS on Fargate bills per vCPU-hour and GB-hour of the resources you declare in the task definition, not the resources you use. Over-provision a task and you pay for the over-provisioning at full rate.
• ECS on EC2 means you run the cluster instances and ECS schedules containers onto them. Savings Plans and Spot apply again, and you own the host OS again.

Where it wins

• The deployment story is genuinely better. Rolling updates with health checks and automatic rollback are configuration, not a script you wrote and hope still works.
• Immutable artifacts. The image that passed CI is the image that runs. No drift from someone running a package update on the box in March.
• Fargate removes host patching entirely, which for a small team is a real reduction in unowned work.
• Scaling to and from zero is straightforward for scheduled or bursty jobs. A nightly batch task on Fargate costs nothing between runs.
• If the app is already containerized and CI already builds images, you are most of the way there.

Where it doesn’t

• The supporting cast costs more than the compute on small workloads. A load balancer, a NAT gateway, CloudWatch Logs ingestion, and a registry are the floor, and none of them scale down with your one small container.
• Tasks in private subnets pull every image layer through the NAT gateway, which bills per GB processed. Frequent deploys of a large image is a cost pattern that looks like nothing on a diagram.
• Persistent local state is awkward, so stateful workloads generally mean EFS or a managed database.
• Handover is harder. A client’s in-house developer can usually SSH into a box. Far fewer can debug a task that fails its health check before it produces a log line.

The NAT gateway problem has a standard fix, worth knowing before you price the work. Put interface endpoints in the VPC for the ECR API and the ECR Docker registry, plus a gateway endpoint for S3, because ECR stores image layers in S3 and that is where the bulk of the bytes actually move. Add interface endpoints for CloudWatch Logs and Secrets Manager if your tasks use them.

# Interface endpoint for the ECR Docker registry (image layer pulls)
aws ec2 create-vpc-endpoint 
  --vpc-id "$VPC_ID" 
  --vpc-endpoint-type Interface 
  --service-name "com.amazonaws.$AWS_REGION.ecr.dkr" 
  --subnet-ids "$SUBNET_A" "$SUBNET_B" 
  --security-group-ids "$SG_ID" 
  --private-dns-enabled

# Gateway endpoint for S3: no hourly charge, and it carries most of the data
aws ec2 create-vpc-endpoint 
  --vpc-id "$VPC_ID" 
  --vpc-endpoint-type Gateway 
  --service-name "com.amazonaws.$AWS_REGION.s3" 
  --route-table-ids "$PRIVATE_RTB_ID"

Interface endpoints carry their own hourly charge per endpoint per availability zone, so this is a trade, not a free win. Below some volume of image pulls the NAT gateway is cheaper; above it, endpoints are. Work out which side you are on before you build either.

Lightsail vs EC2 vs ECS on the lines that move the bill

Compute is rarely the biggest number on a small AWS workload. These are the levers that actually decide it, and they are the ones I check first on any account I inherit.

• Egress. Lightsail bundles an allowance. EC2 and ECS meter it. This single difference can invert the comparison for a media-heavy site.
• NAT gateway. Charged per hour and per GB processed. On ECS with private subnets it is usually the largest fixed cost in the account. Lightsail has no equivalent line.
• Load balancing. Lightsail’s load balancer is a flat monthly price. An Application Load Balancer is an hourly charge plus a capacity-unit charge. AWS publishes traffic thresholds above which it recommends moving to an ALB; if you are near them, you have outgrown the simple option already.
• Public IPv4. Billed per address per hour on EC2 and on task ENIs. It is small per unit and easy to forget across an environment.
• Log ingestion. CloudWatch Logs bills on ingested volume. A chatty container at debug level can out-cost the container. Set retention on every log group at creation time, not later.
• Idle resources. Unattached static IPs and orphaned EBS volumes bill quietly forever. Reclaim them with an offboarding checklist, not a quarterly panic.

A decision procedure for Lightsail vs EC2 vs ECS

Run these in order. The first one that gives a clear answer is the answer.

1. Does this workload need to talk privately to other AWS resources? If it needs a custom VPC, a private RDS instance in a non-default VPC, cross-account access, or PrivateLink, Lightsail is out. Its peering only reaches the default VPC in the same account and region.
2. Who operates this in a year? If the answer is “the client’s office manager” or “nobody,” bias hard toward the simplest thing that works. That is usually Lightsail, or a managed platform outside AWS entirely.
3. Is the app already containerized, with CI that builds images? If yes, ECS is cheap to adopt. If no, containerizing it purely to use ECS is a project, and you should price it as one.
4. Is the load steady or spiky? Steady 24/7 favors a committed EC2 instance. Spiky or scheduled favors Fargate, because you stop paying between runs.
5. How much egress? Estimate monthly GB out. If it is large and cache-friendly, put a CDN in front and the question mostly dissolves. If it is large and not cacheable, Lightsail’s bundled allowance is a real argument.
6. What is the audit story? If the client needs detailed IAM boundaries, VPC flow logs, or GuardDuty coverage across the workload, you want a normal VPC. That means EC2 or ECS.

If you land on Lightsail and want to keep the door open, take manual snapshots on a schedule and confirm the export path works before you need it. The commands are short:

# Take a manual snapshot of the instance
aws lightsail create-instance-snapshot 
  --instance-name my-instance 
  --instance-snapshot-name my-instance-export-test

# Export it to EC2 as an AMI plus EBS snapshot, in the same region
aws lightsail export-snapshot 
  --source-snapshot-name my-instance-export-test

# Watch the export until the state reports completed
aws lightsail get-export-snapshot-records

Do this once at project start. Finding out that a Django or Ghost blueprint instance cannot be exported is a fact you want on day one, not cutover day.

If you need Lightsail to reach an RDS database in the default VPC, peering is a region-level toggle. Enable it, then confirm it rather than assuming:

aws lightsail peer-vpc --region eu-west-1
aws lightsail is-vpc-peered --region eu-west-1

You still have to allow the traffic on both sides. The security group on the AWS resource has to accept the Lightsail CIDR range, and the Lightsail instance firewall has to allow the return path. Peering enabled is not the same as traffic flowing, and that gap is where an afternoon disappears.

Whichever you pick, put monitoring on it on day one. CloudWatch covers the AWS-side metrics; Grafana Cloud or Datadog give you a better view across a mixed estate. The failure you are guarding against is not a dramatic outage, it is a slow degradation nobody notices until a client emails.

Arguments that don’t survive contact

“Lightsail is just EC2 with a nicer console”

Same infrastructure underneath, different networking model, and that is the part that bites. A Lightsail instance is not sitting in your VPC. Anything that assumes a normal VPC, from a security group reference to a VPC endpoint, needs a rethink.

“Start on Lightsail, migrate to EC2 when you outgrow it”

Half true. The instance migrates cleanly. The database, load balancer, distribution, static IP, and DNS do not. It is a real migration project, so plan for it as one rather than treating it as an upgrade button.

“Fargate is serverless, so it scales to zero and costs nothing when idle”

The tasks scale to zero. The load balancer, the NAT gateway, and the VPC endpoints do not. On a small workload the always-on infrastructure usually dominates, which is exactly backwards from the intuition the word “serverless” gives you.

“Containers are better practice, so ECS is the professional choice”

Containers are better practice for reproducibility, and that benefit is mostly delivered by the image and the CI pipeline, not by the orchestrator. A container running under systemd on one EC2 instance captures most of the win at a fraction of the operational surface. Reach for ECS when you need scheduling, rolling deploys, and health-check-driven replacement.

“Reserved Instances make EC2 cheaper, so always pick EC2”

Commitment discounts are worth real money on steady workloads. They are also a one or three year commitment on a client relationship that may not last that long. Committing on a client’s behalf is a conversation, not a default.

FAQ

Is Lightsail cheaper than EC2 for a small website?

Usually, for a steady small workload, because the bundle includes storage and a data transfer allowance you would pay for separately on EC2. The comparison flips when you can apply a Savings Plan or Reserved Instance to a long-running EC2 instance, or when you need an instance family Lightsail does not offer. Price both against your actual egress volume rather than comparing headline compute rates.

Can a Lightsail instance connect to an RDS database?

Yes, through VPC peering, with conditions. Peering is between your Lightsail VPC and the default VPC in the same account and region, a default VPC has to exist, and the CIDR blocks must not overlap. Enable it in every region where you have Lightsail resources you want connected.

Does everything migrate when I export Lightsail to EC2?

No. Instance snapshots and block storage disk snapshots export. Managed databases, container services, CDN distributions, load balancers, static IPs, and DNS records do not. Certain blueprint instances, including Django, Ghost, and cPanel & WHM, cannot be exported at all. Check your specific blueprint before you commit to a migration date.

Is ECS overkill for a single small container?

Often, yes. For one container with no scaling requirement, running it under systemd or Docker Compose on a single instance gets the same immutable-artifact benefit without a load balancer, a NAT gateway, or a cluster to reason about. ECS earns its place when you need rolling deploys with automatic rollback, or more than a couple of services.

Why is my Fargate bill higher than the vCPU-hour rate suggests?

Two reasons, usually. Fargate bills the CPU and memory you declared in the task definition, not what the container consumed, so over-provisioning is billed at full rate. And the surrounding infrastructure (load balancer, NAT gateway data processing, public IPv4 addresses, CloudWatch Logs ingestion) is charged separately and often exceeds the compute on small services.

Should I use Lightsail container service instead of ECS?

Reasonable middle option if you want containers with flat-rate billing and no VPC to design. The trade is the same as everywhere else in Lightsail: limited configuration, and container services are among the resources that do not export to EC2. Treat it as a destination, not a stepping stone.

The one thing worth remembering

Lightsail vs EC2 vs ECS is not a question about performance. All three will serve a small client workload perfectly well. It is a question about which constraints you are accepting and how expensive they are to reverse.

One site with no other AWS resources and a client-visible bill: Lightsail. Anything needing a private database, a custom VPC, or an existing AWS footprint: EC2. Already containerized, deploying weekly, with someone technical staying involved: ECS. And if nobody will operate it after handover, push back on all three and price managed hosting instead, because an unpatched instance with no owner is worse than a more expensive managed platform.

Lightsail trades networking depth and portability for a bill you can put in a proposal. EC2 trades operational work for control. ECS trades a higher fixed floor for deployment mechanics that stop being your problem. Pick based on who operates the thing in a year and how much has to be rebuilt when requirements change, not on which service sounds most professional in a kickoff call.

Need a second opinion before you commit?

Most of the cost and portability problems above are cheap to avoid at design time and expensive to unwind later. What I help with on exactly this decision:

• Sizing a Lightsail, EC2, or ECS deployment against real traffic and egress numbers instead of guesses
• Working out whether VPC endpoints or a NAT gateway is cheaper for your specific image size and deploy frequency
• Planning and executing Lightsail to EC2 migrations, including the parts that do not export
• Setting up VPC peering between Lightsail and RDS, and debugging why traffic still is not flowing after you enabled it
• Auditing an inherited AWS account for idle addresses, orphaned volumes, and log groups with no retention policy
• Writing the handover runbook so the next person can operate it without calling you

If you want a straight answer on which of the three fits, send me a month of Cost Explorer output or a task definition and I will tell you what I would change.

The post Lightsail vs EC2 vs ECS: What I Actually Pick for Small Client Workloads appeared first on John Nessime.

The host had removed it. It was on their disallowed list, a routine scan found it, and the platform did exactly what its documentation said it would do. Everyone had agreed to that when they signed up. Nobody had read it.

That incident is the whole managed WordPress hosting vs VPS argument in miniature, and it has almost nothing to do with page speed. Both models can serve a fast WordPress site. They differ on which failures land on you, which land on someone else, and which ones stay invisible until the worst possible moment.

This post compares the two the way I’d compare them for a client: an honest profile of each, the costs that never appear on the invoice, a procedure for modelling the real number, and the decision rules I actually use. No benchmark charts, because your theme and your plugin count will dominate anything the host does.

The real question: who owns the failure at 2am

Most comparisons frame this as control versus convenience. True, but useless, because it doesn’t tell you what to buy. The framing that predicts regret is: when something breaks, whose problem is it, and how fast can they fix it?

Split the failure surface into layers and the answer gets concrete:

• Hardware and hypervisor. Theirs in both models. Your recovery time is still yours.
• OS, web server, PHP, database. Theirs on managed hosting, yours on an unmanaged VPS. This is the big split.
• Backups and restores. Theirs on managed, and tested, because their business depends on it. Yours on a VPS, and almost nobody tests them.
• Core, themes, plugins. Mostly yours either way. Some hosts auto-update, but the compatibility fallout is still yours.
• Your code and your content. Always yours. No host takes this on.

The bottom two rows never move. A managed platform will not make your bloated page builder fast, and it will not stop a vulnerable plugin from being exploited. It moves the middle three rows off your plate and charges you in money and in flexibility.

Managed WordPress hosting, assessed honestly

Where it genuinely wins

The strongest argument isn’t performance. It’s that the boring, high-consequence work gets done by people whose job it is, on a schedule, whether or not you remember.

• Restores that work. One-click recovery from a backup the platform verifies. That’s the difference between a bad hour and a bad week.
• Server-level page caching, already tuned. WP Engine, Kinsta, Pressable and Flywheel run full-page caching in front of PHP. It’s why they ban plugins that try to do the same thing badly.
• Staging that isn’t a science project. Clone, test, push back. On a VPS that’s yours to build, and a half-built staging setup is worse than none.
• Support that knows WordPress. A generic VPS provider’s ticket ends at “the server is up”. A WordPress host will look at your slow query log.
• Edge protection before PHP loads. WAF and bot filtering at the infrastructure layer, the only layer where they meaningfully help. A plugin firewall runs after the request has already cost you a PHP worker.

If nobody on your team wants to own a Linux box, that list is decisive. The rest of this section is about what you’re trading away.

Visit metering is a billing model, not a traffic report

This is the cost that bites hardest, because it doesn’t look like a technical constraint until the invoice arrives.

Most managed plans meter “visits” rather than bandwidth or CPU, and the definition is narrower than it sounds. WP Engine defines a billable visit as one unique IP address logged per day, with static assets like images, CSS and JavaScript excluded, and known and suspected bot user agents filtered out. Kinsta counts the sum of unique IPs seen within each 24-hour period across the plan, and also sells bandwidth-metered plans as an alternative. Flywheel filters IPs belonging to known bots, spammers and attackers before counting.

Three consequences follow, and they’re the ones people miss:

• Your host’s number will not match Google Analytics. Analytics counts sessions from browsers that ran its JavaScript. Your host counts IPs that hit the server. Arguing about the gap is wasted effort.
• Bot filtering is best-effort. Hosts filter what they can identify. A scraper with a browser-shaped user agent and rotating IPs looks, to the meter, like a crowd of new visitors.
• Overages are charged per block of excess visits. Rates change, so check the current figure rather than trusting any article, including this one. What matters is the shape: a viral post or a bad crawl month produces a bill you didn’t budget for.

A VPS has the opposite failure mode. Bad traffic costs you CPU and RAM, not money, right up until it exhausts them and the site falls over. One model converts load into a bill, the other converts it into an outage. Pick the one you’d rather explain to whoever owns the site.

The plugin policy is a real constraint

Managed hosts publish disallowed plugin lists and they enforce them. WP Engine documents that disallowed plugins are found by periodic scans of the site’s filesystem, the owner is notified, and the plugin is removed. That’s not a threat, it’s the operating model, and it’s why the incident I opened with was nobody’s fault.

The banned categories are consistent across vendors, and the reasoning holds up in each case:

• Caching plugins. They fight the platform’s own page cache and produce stale output that support then has to debug.
• Backup plugins. They write large archives onto the same disk the site runs on, which is a useless backup if the disk is what fails.
• Database optimisation plugins. Long-running write-heavy queries on shared infrastructure affect neighbours.
• Some security plugins, or specific features within them. Filesystem-based rule storage and high-volume traffic logging are the usual triggers. Policies vary a lot here.
• Plugins that send mail directly. Platforms push you to a transactional provider instead, for deliverability reasons that are genuinely in your interest.

None of that is unreasonable. The problem is when a plugin your business depends on lands in one of those buckets, or when a host adds something to the list later. Before migrating, read the current disallowed list for that specific host and diff it against your live active plugins. Ten minutes, and it’s the highest-value thing you can do in a hosting evaluation.

You get one shape of application

A managed WordPress platform runs WordPress. If your project also needs a Node service, a Python worker, a queue, or a self-hosted analytics instance, that’s a second bill somewhere else. On a VPS those things are free in cash terms because you already own the machine. They cost you memory and attention instead. Whether that’s a good trade depends on whether you were going to need them anyway.

Running WordPress on your own VPS, assessed honestly

Where it genuinely wins

• Resources per unit of money. Hetzner, InterServer, DigitalOcean and Vultr will sell you more CPU and RAM than an entry managed plan. Whether you can use it is a separate question.
• Many sites, one bill. This is where the economics genuinely flip. Ten small sites on one adequate VPS is one server to patch. Ten managed plans is ten invoices.
• No metering surprises. Traffic spikes hit your load average, not your credit card.
• You choose the stack. Nginx or Apache, PHP-FPM pool sizing, Redis for the object cache, your own MariaDB tuning and firewall rules. If the platform’s opinions were what limited you, this is the fix.
• No lock-in. A tarball and a database dump move anywhere. Platform-specific caching behaviour, redirect rules and deployment workflows do not.

The failure that stays invisible: the backup you never restored

Here’s the one that actually ends projects. Backups on a self-managed VPS fail silently. The cron entry runs, the exit code goes nowhere, the destination bucket quietly rejects writes after a credential rotation, and nothing tells you. You find out the day you need it, which is also the day you have no other option.

The fix isn’t a better tool. Restic and BorgBackup are both excellent and neither will save you. The fix is a restore drill on a schedule, into a scratch directory, where you verify the data is actually there.

# Restore the newest snapshot into a scratch path, never over the live site
restic -r /srv/backups/wp restore latest --target /tmp/restore-drill

# Confirm the dump is real and not a zero-byte file or a truncated
# write from a run that died halfway through
ls -lh /tmp/restore-drill/db/
head -n 20 /tmp/restore-drill/db/site.sql

# Load into a throwaway database and count what came back.
# If wp_posts is empty, your backups have been failing for weeks.
mysql -u drill -p drill_db < /tmp/restore-drill/db/site.sql
mysql -u drill -p -e "SELECT COUNT(*) FROM drill_db.wp_posts;"

Adjust the repository path and database names to your own. The shape is the point: restore somewhere harmless, then check a row count that would be non-zero on a healthy site. A backup you haven’t restored is a hypothesis, not a backup. Uptime checks from something like UptimeRobot tell you the site is down; they tell you nothing about whether you can get it back.

Patching debt compounds quietly

The second invisible cost is the gap between “updates are available” and “updates are applied and the affected services have actually restarted”. Upgrading a package without restarting the process leaves the old, vulnerable code resident in memory. That’s why security scanners and package managers disagree so often.

# RHEL family (AlmaLinux, Rocky, CentOS Stream)
# What security updates are outstanding?
sudo dnf updateinfo list security

# After applying them: does anything still need a restart?
# Exit 0 means no reboot required, exit 1 means reboot required.
sudo dnf needs-restarting -r

# Debian and Ubuntu: what would unattended-upgrades actually do?
sudo unattended-upgrade --dry-run --debug

Run those on any VPS you inherited from someone else. The output is usually educational. Then there’s the WordPress layer, which stays yours regardless of hosting model:

# Do the core files match the official checksums for this version?
# A mismatch means a modified core file or an active compromise.
wp core verify-checksums

# How many plugins are behind?
wp plugin list --update=available --format=count

# Which tables are eating the disk? Usually wp_options, wp_postmeta,
# or a logging plugin nobody remembers installing.
wp db size --tables --format=table

Model the cost before you argue about it

Sticker price comparisons are how people talk themselves into the wrong answer in both directions. This procedure produces a number you can defend.

1. Count your sites. One tilts toward managed. Five or more tilts toward a VPS, because admin time is close to fixed and plan fees are per-site.
2. Estimate your metered visit count from your own logs. If you’re already on a server you control, you can approximate what a metered host would bill you before signing anything.
3. Price the VPS honestly. Instance plus block storage plus offsite backup destination plus any control panel licence. The advertised instance price is rarely the whole line.
4. Put a rate on your own hours. Whatever you’d bill a client, or pay someone else. Zero is not an honest number.
5. Add the one-off build. Standing up a hardened WordPress VPS with TLS, firewall, object cache, tested backups and log rotation is a solid chunk of focused work the first time. Amortise it over twelve months.
6. Add your recovery cost. Hours to rebuild from scratch, times your rate, times how often you honestly think it’ll happen. This term is what makes managed hosting look cheap for a single revenue-generating site.

Step two is worth doing properly, because it’s the number nobody has. On Nginx with the standard combined log format, this gets you close:

# Unique client IPs in the log. A rough upper bound on metered "visits".
awk '{print $1}' /var/log/nginx/access.log | sort -u | wc -l

# Closer to how hosts count: ignore static assets, since most platforms
# exclude images, CSS and JS from billable visits.
awk '$7 !~ /.(css|js|png|jpg|jpeg|gif|svg|webp|woff2?|ico)$/ {print $1}' 
  /var/log/nginx/access.log | sort -u | wc -l

# What is actually hitting you? User agents by request count.
# If the top entries are crawlers, that is your overage risk.
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Field positions assume the combined log format; adjust the column numbers if you’ve customised log_format. The third command is the interesting one. If crawlers dominate your traffic, visit-metered hosting will charge you for whatever the host’s filtering misses, and that’s a risk you can quantify before signing up rather than after.

The middle ground worth looking at first

This gets presented as two options. There are four, and the middle two get skipped far too often.

• Managed VPS. InterServer, Liquid Web and others sell VPS plans where the provider handles OS patching, firewall and backups while you keep root. Read the scope: “managed” often stops at the operating system and leaves the WordPress stack to you.
• Control panel on your own VPS. DirectAdmin, cPanel or CyberPanel gives you WordPress-aware tooling, staging and one-click TLS on infrastructure you still own. You pay a licence and give up some configuration purity.
• Server management platforms. Cloudways, RunCloud, GridPane and SpinupWP provision and manage a stack on a VPS you rent from a provider of your choice. Managed-style workflows without the per-visit meter.
• A CDN in front of anything. Putting Cloudflare or a similar edge ahead of a modest VPS absorbs a large share of the traffic that would otherwise push you onto a bigger plan. Cheapest performance win available to either model, and frequently the actual answer to “we need better hosting”.

If you’re leaning toward a VPS mainly because managed pricing looks steep, look at options two and three before committing to a bare Linux box.

How I’d decide between managed WordPress hosting vs VPS

These are the rules I apply, in order. The first match usually settles it.

• Nobody on the team can or wants to run Linux. Managed, and it isn’t close. An unpatched VPS is worse than the most restrictive managed plan.
• One site, and it generates revenue. Managed. The recovery term dominates everything else in the cost model.
• Five or more sites and someone competent to run them. VPS, or a management platform on top of one.
• You need services WordPress isn’t. VPS. Don’t pay for two platforms to avoid learning one.
• A plugin you can’t remove is on the host’s disallowed list. VPS, or a different managed host. Do not migrate hoping for an exception.
• Traffic is spiky and crawler-heavy. Lean VPS, or pick a bandwidth-metered plan over a visit-metered one. Metering punishes exactly this traffic shape.
• You’re mostly annoyed at the current bill. Neither, yet. Put a CDN in front, cut the plugin count, fix the object cache. Hosting is often not the bottleneck.

Arguments that don’t survive contact

• “A VPS is faster because you get dedicated resources.” Only if it’s configured well. A default LEMP install with no object cache and an untuned PHP-FPM pool loses to a managed platform’s edge cache every time.
• “Managed hosting handles security, so I’m covered.” It handles infrastructure security. The most common route into a WordPress site is a vulnerable plugin, and that’s yours in both models.
• “I’ll just move if I outgrow it.” Migration cost is real and grows with the site. Redirect rules, caching behaviour, deployment workflow and email configuration all need rebuilding.
• “The VPS is only a few dollars a month.” The instance is. Offsite backup storage, monitoring and your own hours are not, and they’re most of the number.
• “Managed hosts back everything up, so I don’t need my own backups.” Retention windows are finite and account access can be lost. Keep an independent copy the host doesn’t control. This applies to both models.

Frequently asked questions

Is a VPS actually cheaper than managed WordPress hosting?

For one site, usually not once you price your own time honestly. For several sites, usually yes, and the gap widens with each site you add. The crossover sits somewhere around three to five sites for most people, depending on what your hours are worth and how much the sites change.

Why does my managed host report more visitors than Google Analytics?

They measure different things. Analytics counts browser sessions that executed its JavaScript, so it misses anything blocking scripts and misses non-browser clients entirely. Your host counts requests reaching the server, deduplicated by IP per day. Bot filtering closes some of the gap but never all of it. The two numbers are not supposed to match.

Can I run other applications alongside WordPress on managed hosting?

Generally no. Managed WordPress platforms run WordPress and nothing else. A background worker, a separate API, a queue or a self-hosted analytics instance needs a VPS or a second platform. Factor that second bill into the comparison.

What happens if I install a disallowed plugin?

It depends on the host, but the documented pattern at WP Engine is that periodic filesystem scans detect it, you get notified, and the plugin is removed. Check the specific host’s current policy and enforcement mechanism before migrating, and check it against your live plugin list rather than what you assume is installed.

Do I still need a caching plugin on a VPS?

You need caching. Whether it’s a plugin is a design choice. The strongest setup is full-page caching at the web server or CDN layer plus a persistent object cache in Redis or Memcached, which handles the repeated database queries page caching can’t touch. A page cache alone leaves logged-in traffic and admin requests hitting the database on every load.

Is managed VPS hosting a real middle ground or just marketing?

It’s real, but the scope varies enormously and the word isn’t standardised. Ask specifically: who applies OS security patches, who restarts services afterwards, who owns backups and where they live, whether restores are tested, and whether the WordPress stack is in scope or the coverage stops at the operating system. Get the answers in writing before comparing prices.

How hard is migrating from managed hosting to a VPS?

Moving files and the database is the easy part. The work is everything the platform did invisibly: redirect rules living in the host’s dashboard, cache purging behaviour, transactional email, TLS renewal, and any deployment workflow tied to the platform. Plan a parallel run with low DNS TTLs rather than a cutover, and keep the old plan alive until the new one has survived a full traffic cycle.

The one thing worth remembering

Managed WordPress hosting vs VPS isn’t a performance question, and it isn’t really a price question either. It’s a question about which failures you’re equipped to own.

Managed hosting converts operational risk into a predictable bill and a set of constraints you have to live inside. A VPS converts that bill into flexibility plus a standing obligation to do the boring work: patch, restart, and prove your restores actually restore. Both are defensible. What isn’t defensible is buying a VPS because it looked cheap and then skipping the work, which is the most common failure in this whole category and the one that ends with a rebuild from a backup nobody ever tested.

Run the restore drill. Whatever you choose.

Need a second opinion on your hosting decision?

Most of the hosting work I get asked for is one of these. If it looks like your situation, I can help:

• Cost modelling before you commit. Working out from your own access logs what a visit-metered plan would actually bill you, against a realistically priced VPS including backup storage and hours.
• Migration in either direction. Managed to VPS or VPS to managed, planned as a parallel run with DNS TTL staging so there’s no blind cutover.
• Building the VPS properly the first time. Nginx or Apache with PHP-FPM sized to the actual RAM, Redis object cache, TLS with automated renewal, firewall and Fail2ban, log rotation that doesn’t fill the disk.
• Backups you’ve actually restored. Offsite destination, retention policy, and a scheduled restore drill that fails loudly instead of silently.
• Plugin policy audits. Checking your live plugin list against a specific host’s disallowed list before migration, and finding replacements for anything that fails.
• Monitoring that answers the right question. Grafana and Prometheus dashboards covering PHP-FPM saturation, database load and cache hit ratio, not just whether the site returns 200.

Send me something concrete and I’ll tell you what I see: an access log sample, your current plan and traffic numbers, your active plugin list, or the output of the commands above. That’s usually enough for a straight answer before either of us talks about scope.

The post Managed WordPress Hosting vs VPS: Who Owns the Failure? appeared first on John Nessime.

A successful WordPress migration is not just a matter of copying files from one server to another. It is a controlled infrastructure change involving the website files, database, domain records, SSL certificate, email configuration, caching layers, scheduled tasks, security settings, and third-party integrations.

When the process is planned correctly, visitors may never notice that the website has moved. When it is rushed, the result can include broken pages, missing images, database errors, lost form submissions, email disruption, redirect loops, certificate warnings, or several hours of downtime.

This guide explains how to migrate a WordPress website safely, how to reduce downtime, what can go wrong, and what should be verified before the old hosting environment is finally switched off.

What Is a WordPress Migration?

A WordPress migration is the process of moving a WordPress website from one environment to another. The destination might be a new hosting provider, a cloud server, a virtual private server, a staging environment, a new domain, or a different server configuration.

The website may look like a single application from the visitor’s perspective, but several separate components normally need to be transferred:

• WordPress core files
• Theme files
• Plugin files
• Uploaded media
• The MySQL or MariaDB database
• Configuration files
• Custom code and server rules
• DNS records
• SSL certificates
• Email-related DNS records
• Cron jobs and scheduled tasks
• CDN and caching configuration
• Analytics and tracking scripts
• External API integrations

A complete migration must preserve both the visible website and the underlying functionality. Copying the homepage successfully is not enough if contact forms stop sending, checkout sessions fail, redirects break, or administrators can no longer log in.

Common Reasons for Migrating a WordPress Website

Website owners migrate WordPress installations for many different reasons. In most cases, the decision is connected to performance, reliability, cost, control, or security.

Slow Hosting Performance

A website may outgrow its original shared hosting plan. Pages become slow, the WordPress dashboard takes longer to load, and traffic spikes begin causing resource-limit errors. Moving to a better-managed host, VPS, or cloud server can provide more CPU, memory, storage performance, and configuration flexibility.

Frequent Downtime

Unreliable infrastructure can damage customer trust and search visibility. If the current host experiences repeated outages or provides weak technical support, migration may be the most practical long-term solution.

Security Concerns

Outdated server software, poor account isolation, weak backup systems, or limited firewall controls can expose a WordPress website to unnecessary risk. A migration can be used as an opportunity to rebuild the site on a cleaner and more secure environment.

Hosting Cost Optimization

Some hosting plans become expensive as traffic grows, especially when backups, staging, CDN access, email, malware scanning, or additional storage are charged separately. Migrating to a more suitable platform can reduce costs without sacrificing performance.

Business Growth

A small brochure website may eventually become a membership platform, online store, booking portal, or content-heavy publication. The original environment may no longer support the website’s operational requirements.

Domain or Branding Changes

Some migrations involve changing the domain name as well as the server. This requires additional planning because internal URLs, redirects, analytics properties, search-engine records, cookies, and third-party callbacks may all depend on the original domain.

The Difference Between a Simple Migration and a Production Migration

A small personal blog with few updates can often be moved using a migration plugin. A production website requires more care.

Production websites may receive new orders, registrations, comments, bookings, support requests, or form submissions while the migration is taking place. If the database is copied too early and DNS is updated hours later, any data created during that gap may remain only on the old server.

That is why a production migration should be treated as a controlled cutover rather than a one-click file transfer. The objective is to minimize the period during which the old and new environments contain different information.

What Can Go Wrong During a WordPress Migration?

Most migration problems fall into a predictable set of categories. Knowing them in advance makes the process easier to plan and troubleshoot.

Database Connection Errors

The WordPress configuration file may contain the wrong database name, username, password, or database host. The user may also lack the necessary permissions on the destination database.

Broken Internal URLs

WordPress stores URLs in the database. If the domain, protocol, folder path, or staging address changes, old references can remain inside posts, menus, widgets, page-builder content, serialized options, and plugin settings.

Missing Images or Media Files

The uploads directory may be incomplete, excluded from the transfer, or copied with incorrect ownership and permissions. A site may appear functional while older images silently return 404 errors.

PHP Compatibility Problems

The destination server may use a newer PHP version than the original host. An outdated theme or plugin can then generate warnings, fatal errors, blank pages, or broken administrative screens.

Redirect Loops

Conflicting HTTPS, proxy, CDN, and WordPress redirect rules can cause the browser to repeatedly redirect between two versions of the same URL.

Email Delivery Failure

A migration may affect outgoing form emails, SMTP authentication, domain verification, or mailbox routing. DNS changes can also unintentionally overwrite MX, SPF, DKIM, or DMARC records.

SSL Certificate Warnings

The destination server may not yet have a valid certificate, or the certificate may not cover every hostname used by the website. Mixed-content warnings can also appear when pages load images, scripts, or stylesheets through HTTP.

Lost Transactions or Form Submissions

This is one of the most serious risks. If visitors continue using the old website after the final database backup, their activity may not exist on the new server.

Phase One: Audit the Existing Website

Before copying anything, document the current environment. A migration is much safer when the source system is fully understood.

The audit should include:

• Current WordPress version
• PHP version and PHP extensions
• Database engine and version
• Active theme and child theme
• Active and inactive plugins
• Disk usage
• Database size
• Upload directory size
• Web server type
• Caching configuration
• Scheduled cron tasks
• CDN or reverse proxy usage
• External SMTP provider
• Payment and booking integrations
• DNS provider
• SSL configuration
• Backup availability

This audit often reveals problems that already existed before the migration. For example, a plugin may be abandoned, the database may contain excessive transient records, or the site may still rely on an unsupported PHP version.

A migration should not automatically copy every old problem into the new environment. It is often the right time to clean up unused plugins, remove abandoned themes, review administrator accounts, and confirm that all essential components remain supported.

Phase Two: Prepare the Destination Server

The destination environment should be ready before the website is transferred. This reduces last-minute troubleshooting during the cutover.

The server preparation usually includes:

• Creating the hosting account or virtual host
• Installing the correct PHP version
• Enabling required PHP extensions
• Creating the database and database user
• Configuring file permissions
• Setting PHP memory and upload limits
• Configuring the web server
• Preparing SSL issuance
• Configuring backups
• Installing monitoring or logging tools
• Preparing caching and performance settings

The destination should ideally match the source environment closely during the first transfer. Major software upgrades can be performed later, after the website is stable. Combining a hosting migration, PHP upgrade, plugin cleanup, theme redesign, and domain change into one maintenance window increases the number of possible failure points.

Phase Three: Create Verified Backups

A migration should never begin without a complete backup. More importantly, the backup should be verified rather than merely assumed to be usable.

At minimum, create separate copies of:

• The entire WordPress file system
• The website database
• The WordPress configuration file
• Web server rules
• DNS records
• SSL-related information
• Custom cron jobs
• Email routing records

A backup is only valuable if it can be restored. Confirm that the archive opens correctly, the database export is not empty or truncated, and the files include the full uploads directory.

For business-critical websites, keeping more than one backup copy is sensible. One copy may remain on the source server, while another is stored externally.

Phase Four: Copy the WordPress Files

The files can be transferred using several methods, including a migration plugin, hosting control panel, SFTP, SCP, rsync, or a compressed archive.

For small websites, a plugin may be sufficient. Larger websites often benefit from server-level transfer tools because they handle large file sets more efficiently and provide better visibility into transfer errors.

During the transfer, confirm that hidden files are included. Files such as .htaccess may contain essential rewrite, security, redirect, or caching rules.

After copying, verify ownership and permissions. Incorrect permissions can prevent uploads, plugin updates, cache creation, or WordPress core operations.

Phase Five: Export and Import the Database

The database contains the website’s posts, pages, users, settings, menus, plugin data, WooCommerce orders, form entries, and most application-level configuration.

It can be exported using tools such as phpMyAdmin, WP-CLI, a migration plugin, or the database command line. Large databases are generally more reliable to move through command-line tools because browser-based imports may fail due to upload or execution limits.

Once imported, update the destination wp-config.php file with the correct database details:

define('DB_NAME', 'destination_database');
define('DB_USER', 'destination_user');
define('DB_PASSWORD', 'strong_password');
define('DB_HOST', 'localhost');

The exact database host depends on the hosting environment. Some providers use a remote database hostname instead of localhost.

Phase Six: Handle URL Changes Correctly

If the website keeps the same domain, fewer URL changes may be required. However, staging URLs, temporary hostnames, HTTP-to-HTTPS changes, subdirectory changes, or domain changes require a controlled search-and-replace operation.

A plain text replacement inside a database export can damage serialized WordPress data. WordPress plugins and page builders often store structured values where string lengths matter.

Use a WordPress-aware tool such as WP-CLI:

wp search-replace 'https://old-domain.example' 'https://new-domain.example' --all-tables --precise --dry-run

The dry run displays the expected replacements without modifying the database. Once reviewed, the operation can be repeated without the --dry-run flag.

After the replacement, check:

• Page and post links
• Navigation menus
• Image URLs
• Page-builder templates
• Widgets
• Logo and favicon paths
• Canonical tags
• Open Graph images
• Plugin callback URLs
• Webhook endpoints

Phase Seven: Test the Website Before Changing DNS

The destination website should be tested before public traffic is sent to it. This is one of the most important steps in a low-downtime migration.

A local hosts-file override can map the production domain to the new server only on your own computer. This allows the website to be tested under its real domain while the rest of the internet continues reaching the old server.

Testing should cover more than the homepage.

Front-End Testing

• Homepage
• Posts and pages
• Category and archive pages
• Search functionality
• Navigation menus
• Images and downloads
• Responsive layout
• 404 page
• Redirects

Administrative Testing

• WordPress login
• Post editing
• Media uploads
• Plugin settings
• Theme customization
• User management
• Scheduled tasks

Business Function Testing

• Contact forms
• Newsletter subscriptions
• Account registration
• Password reset emails
• Checkout and payment flow
• Booking forms
• Customer dashboards
• API integrations
• Webhook delivery

Check the browser console, server logs, WordPress debug logs, and network requests. A page can appear normal while scripts, API calls, or background processes are failing silently.

How to Reduce WordPress Migration Downtime

Zero downtime is difficult to guarantee for every website, but downtime can often be reduced to a very small window.

Lower the DNS TTL in Advance

DNS Time to Live determines how long resolvers may cache a record. Lowering the TTL before migration can help changes propagate more quickly.

This should be done before the migration window, not at the exact moment of cutover. Existing cached records will continue using the previous TTL until they expire.

Perform an Initial Copy Before Cutover

Copy the website files and database to the destination in advance. This gives enough time to test the environment and resolve compatibility problems before the final switch.

Freeze Content Changes Briefly

For dynamic websites, a short maintenance or content-freeze window may be necessary. During this period, editors should stop publishing and customers may need to be temporarily prevented from submitting transactions.

Perform a Final Database Synchronization

After the initial copy and testing, export the latest database immediately before the DNS or proxy cutover. This minimizes the chance of losing recent activity.

Keep the Old Server Available

Do not cancel the original hosting account as soon as DNS is changed. Some visitors may still reach the old server due to DNS caching. The source environment should remain available until propagation is complete and the new website has been monitored.

DNS Migration: More Than Changing One Record

DNS errors are responsible for many migration failures. A domain may have records for the website, email, verification services, subdomains, APIs, and third-party platforms.

Before making changes, export or document the complete DNS zone. Important records may include:

• A records
• AAAA records
• CNAME records
• MX records
• TXT records
• SPF records
• DKIM records
• DMARC records
• Domain verification records
• Service-specific subdomains

If only the web server is changing, there may be no reason to modify email records. Accidentally replacing the entire DNS zone with a simplified version can interrupt business email even when the website itself works correctly.

SSL and HTTPS After Migration

The destination server must have a valid SSL certificate for the production domain. The certificate should cover all required hostnames, such as the root domain and the www version.

After enabling HTTPS, verify that:

• The certificate is valid and not expired
• The certificate matches the domain
• HTTP redirects to HTTPS correctly
• The root and www versions behave consistently
• No redirect loop exists
• Images and scripts load through HTTPS
• CDN resources use secure URLs

Mixed-content errors should be corrected rather than hidden. They usually indicate that some database values, theme settings, CSS files, or external resources still reference HTTP URLs.

Email and Contact Form Verification

A website migration is not complete until email functionality is tested.

WordPress may rely on the local server mail function, SMTP authentication, a transactional email provider, or an external mailbox service. Each method has different requirements.

Test at least the following:

• Contact form delivery
• Administrator notifications
• Password reset emails
• WooCommerce order emails
• Registration emails
• Newsletter confirmation messages
• SMTP authentication

Also confirm that SPF, DKIM, and DMARC records remain valid. Successful message submission does not always mean successful inbox delivery.

Migrating a WooCommerce Website

WooCommerce migrations require additional care because the database may change continuously. Orders, inventory, customer records, carts, subscriptions, refunds, and payment events can be created during the migration window.

A WooCommerce migration plan should include:

• A clearly defined cutover time
• A short checkout freeze if required
• A final database synchronization
• Payment gateway testing
• Webhook testing
• Order email verification
• Inventory validation
• Subscription and scheduled-payment checks
• Customer login testing
• Transaction log review

For high-traffic stores, a simple export-and-import workflow may not be sufficient. More advanced database synchronization or application-level migration techniques may be needed.

Migrating WordPress to a New Domain

Changing the domain adds an SEO and application layer to the migration.

In addition to moving the website, the process should include:

• Updating WordPress URLs
• Replacing old domain references
• Creating page-to-page 301 redirects
• Updating canonical URLs
• Updating XML sitemaps
• Updating analytics properties
• Updating Search Console records
• Updating social profiles
• Updating payment callbacks
• Updating API allowlists
• Updating email addresses where required

A blanket redirect from every old URL to the new homepage is not a good migration strategy. Each important old URL should redirect to its closest equivalent on the new domain.

Protecting SEO During WordPress Migration

A hosting migration that keeps the same domain should normally have limited SEO impact when implemented correctly. A domain change or large structural change requires more planning.

Important SEO checks include:

• Preserving existing URL structures
• Maintaining page titles and metadata
• Keeping canonical tags correct
• Preserving structured data
• Checking robots.txt
• Checking XML sitemaps
• Verifying redirects
• Removing accidental noindex directives
• Checking HTTP status codes
• Monitoring crawl errors
• Monitoring organic traffic after launch

Staging environments are often configured with noindex rules to prevent search engines from indexing them. That setting must not be carried into production accidentally.

It is also important to remove temporary password protection, development redirects, and staging-specific canonical URLs before launch.

Performance Optimization After Migration

A migration provides a good opportunity to improve performance, but optimization should be performed methodically.

Start by confirming that the website is stable. Then review:

• Page caching
• Object caching
• PHP OPcache
• Database performance
• Image compression
• WebP or AVIF delivery
• CDN integration
• Browser caching
• Gzip or Brotli compression
• Slow plugins
• Unused scripts and styles
• External API delays

Do not enable several caching systems at the same time without understanding how they interact. Duplicate caching layers can create stale pages, login problems, checkout issues, and difficult-to-diagnose behavior.

Security Checks After Migration

The new environment should be reviewed before the migration is considered complete.

Post-migration security checks should include:

• Removing temporary migration files
• Removing exported database archives
• Deleting unused administrator accounts
• Changing temporary credentials
• Confirming file ownership and permissions
• Disabling directory listing
• Reviewing firewall rules
• Enabling brute-force protection
• Updating WordPress, themes, and plugins
• Reviewing backup access
• Protecting configuration files
• Confirming malware scanning

Database exports and full-site archives often contain sensitive information. They should not remain publicly accessible inside the website directory after migration.

WordPress Migration Plugins vs Manual Migration

Both methods are valid. The right choice depends on the website.

Migration Plugins

Migration plugins are convenient for small and medium-sized websites. They can package files and databases, update URLs, and simplify restoration.

However, they may encounter:

• File size limits
• PHP execution time limits
• Memory limits
• Hosting restrictions
• Archive extraction failures
• Large database timeouts
• Limited visibility into errors

Manual or Server-Level Migration

Manual migration provides more control and is often more reliable for large, customized, or business-critical websites.

It also allows the migration specialist to inspect logs, control database operations, preserve permissions, perform incremental transfers, and troubleshoot individual layers separately.

The tradeoff is that server-level migration requires stronger knowledge of Linux, databases, DNS, web servers, PHP, SSL, and WordPress internals.

A Practical WordPress Migration Checklist

Before Migration

• Audit the current website
• Record PHP and database versions
• List active integrations
• Export DNS records
• Lower DNS TTL if needed
• Create and verify backups
• Prepare the destination server
• Install required PHP extensions
• Create the destination database
• Plan the maintenance window

During Migration

• Copy WordPress files
• Export and import the database
• Update wp-config.php
• Perform safe URL replacement
• Verify permissions
• Test using a hosts-file override
• Check logs and browser errors
• Test forms, logins, and transactions
• Perform the final database sync
• Update DNS

After Migration

• Verify SSL
• Test email delivery
• Check redirects
• Check sitemap and robots.txt
• Clear all cache layers
• Review application logs
• Monitor uptime
• Monitor search and analytics data
• Keep the old server available temporarily
• Remove migration archives
• Confirm backup schedules

When Should You Hire a WordPress Migration Specialist?

A simple personal website may be moved successfully with a migration plugin. Professional assistance becomes more valuable when the website has operational or commercial importance.

Consider hiring a specialist when:

• The website generates sales or leads
• Downtime has a direct business cost
• The database changes frequently
• The site uses WooCommerce or memberships
• The migration includes a domain change
• Email services share the same DNS zone
• The site contains custom plugins or code
• The destination server requires manual configuration
• The site has a large media library or database
• You need SSL, DNS, redirects, and testing handled together

A professional migration should provide more than a copied website. It should include preparation, backups, testing, DNS coordination, SSL validation, post-migration verification, and a rollback plan.

Final Thoughts

WordPress migration is a technical process, but the real objective is business continuity. Visitors should continue reaching the website, customers should continue completing transactions, administrators should retain access, and search engines should continue finding the same content.

The safest migrations are rarely the fastest-looking ones. They are the migrations where the destination is prepared in advance, backups are verified, the website is tested before cutover, DNS is handled carefully, and the old environment remains available until the transition is confirmed.

Whether the website is moving to a new hosting company, a VPS, a cloud server, or a new domain, a structured migration plan dramatically reduces the risk of downtime, missing data, and unexpected failures.

The post WordPress Migration Without Downtime: A Practical Guide to Moving Your Website Safely appeared first on John Nessime.