Migrating a WordPress site from AWS to Azure App Service isn’t fundamentally different from any WordPress host-to-host migration — copy the files, migrate the database, reconfigure WordPress to talk to the new environment, verify everything works, and only then point DNS at the new server. Where it gets AWS-to-Azure specific is in a couple of Azure App Service configuration details that trip people up if you don’t know to look for them.
The Core Migration Sequence
- Copy your WordPress files, particularly the
wp-contentfolder (themes, plugins, uploads) — an FTP client like FileZilla works fine for this against your existing AWS instance. - Export the database from your AWS-side MySQL/MariaDB instance into a SQL file, using phpMyAdmin, MySQL Workbench, HeidiSQL, or the command line.
- Set up the new Azure environment — Azure App Service for WordPress plus Azure Database for MySQL Flexible Server.
- Import the database into the new Azure MySQL instance, and update
wp-config.phpto point at the new database host, name, user, and password. - Verify on a test/staging slot before touching production — validate the full site, not just the homepage, before any DNS change.
- Cut over DNS last, only once everything on the Azure side is confirmed working.
Plugin-Based vs. Manual Migration
For sites under roughly 256MB, a plugin like All-in-One WP Migration handles the file-and-database export/import as a single zip package, which sidesteps a lot of manual error surface. For larger sites, the manual file-copy-plus-SQL-export process (above) is more reliable, since large all-in-one migration exports are more prone to timeouts. Either way, avoid hand-editing a raw SQL export — WordPress stores a fair amount of serialized PHP data, and a manual find-and-replace on URLs inside a raw SQL file can silently corrupt that data in ways that only surface later as broken widgets or missing settings.
Azure-Specific Gotchas
A few configuration issues show up specifically when moving WordPress onto Azure App Service that don’t come up on a typical AWS-to-AWS or AWS-to-shared-hosting move:
- Container port alignment — Azure App Service (Linux containers) expects your app on a specific port; you generally need to set the
WEBSITES_PORTapplication setting to match (commonly 8080), or requests won’t route correctly. - HTTPS detection behind Azure’s proxy — Azure terminates SSL at its own layer and forwards requests to your app over HTTP internally, so WordPress needs to read the
HTTP_X_FORWARDED_PROTOheader to know the original request was HTTPS. Without this, you can get redirect loops or WordPress serving mixed content. - Database connection conflicts — double-check
wp-config.phpreflects Azure Database for MySQL’s actual host/port/SSL requirements, which differ from a typical AWS RDS or Lightsail-local MySQL connection string.
Keeping Downtime Under 15 Minutes
| Step | Why it matters |
|---|---|
| Lower DNS TTL to 300 seconds at least 24 hours before cutover | Speeds up DNS propagation when you actually make the switch |
| Test via your local hosts file before changing DNS | Lets you view the site exactly as it will appear post-migration, without affecting live traffic |
| Keep the old AWS instance running for at least 7 days after cutover | Gives you a rollback path, and covers any DNS caches still pointing to the old server during propagation |
| Use WP-CLI chunked export for databases over 1GB | Avoids timeouts that a single large SQL export or plugin-based migration can hit |
What About Much Larger Sites? (20GB+ Database, 100GB+ Files)
Everything above still applies in sequence — files, then database, then DNS cutover last — but at 20GB of database and 100GB+ of files, the specific tools change. A single-threaded mysqldump and a plain FTP file copy, which work fine for smaller sites, become genuinely impractical: dump/restore time balloons, connections time out, and the migration window stretches from minutes into hours or longer.
Moving 100GB+ of Files
Manual FTP isn’t realistic at this size. Two better options:
- AzCopy for a direct transfer — if your AWS-side media is already in S3 (common for larger sites using an offload plugin), AzCopy can copy directly from S3 to Azure Blob Storage server-side, with transfers in the same region reaching roughly 50 Gbps since the data moves between AWS and Azure’s own servers rather than through the machine running the command.
- rsync or AzCopy from the source VM — if your files live on the AWS instance’s local disk (typical for a Lightsail/EC2-hosted WordPress install) rather than S3, rsync to a staging location or AzCopy directly to Azure Storage is the standard route, run from the source server itself.
Budget for AWS’s cross-cloud egress fee if your files are leaving S3 — around $0.09/GB as of early 2026, so roughly $9 for 100GB. Azure doesn’t charge for the inbound side.
Moving a 20GB Database
A plain mysqldump is single-threaded and becomes the real bottleneck at this size. Two approaches that actually scale:
| Method | How it works | Best for |
|---|---|---|
| mydumper / myloader | Multi-threaded dump and restore — splits large tables into chunks by primary key range and exports/imports each chunk in parallel, rather than one single sequential SQL file | Databases over 10GB where dump/restore speed is the priority and some downtime during the window is acceptable |
| Azure Database Migration Service (online/minimal-downtime) | Sets the Azure database up as a live replica of your AWS source (via Data-in Replication or a Percona XtraBackup-based physical migration), continuously syncing new transactions until you’re ready to cut over — at which point you stop the app briefly, let the last batch catch up, and switch the connection string | Production databases where minimizing actual downtime matters more than migration simplicity |
One caveat worth checking before you commit to a plan: the newer az mysql flexible-server import CLI path (a more direct physical-backup import) has had periods where it was disabled due to known issues — verify its current status before relying on it, and treat mydumper/myloader or Azure DMS as the more dependable options at this scale.
Realistic Expectations at This Scale
A straight dump-and-restore of a 20GB database, even with mydumper’s parallelism, typically means a migration window measured in hours rather than minutes once you account for index rebuilding on the restore side — plan the cutover for a low-traffic window regardless of which tool you use. Azure DMS’s online/continuous-replication approach is the way to bring actual customer-facing downtime down to minutes even at this size, at the cost of more setup complexity and a longer overall project timeline to configure and validate the replication first.
Pre-Cutover Checklist
- Confirm the Azure site loads correctly via hosts-file testing, checking real pages, not just the homepage — forms, checkout flows (if WooCommerce), and media all need to actually work.
- Check for hardcoded AWS URLs or IPs anywhere in theme/plugin custom code, not just the database, since a database-only URL replace can miss these.
- Verify SSL is actually serving correctly on the Azure side, including the forwarded-proto header handling above.
- Have a rollback plan — specifically, don’t decommission the AWS instance until you’ve confirmed the Azure site is stable under real traffic for at least a few days.
If you’re still deciding whether Azure is the right destination in the first place, see AWS Bitnami vs Azure for WordPress in 2026: What to Actually Choose. Want help planning or executing a migration like this? Get in touch.
Frequently Asked Questions
Can I migrate a WordPress site from AWS to Azure with zero downtime?
Realistically, downtime under 15 minutes is achievable with careful DNS TTL management and pre-cutover testing, but true zero downtime typically requires more advanced techniques (like a load-balanced dual-running setup) beyond what a standard migration needs.
Should I use a migration plugin or do it manually?
Plugin-based migration (like All-in-One WP Migration) works well for smaller sites (roughly under 256MB) and reduces manual error. Larger sites are generally more reliable with a manual file-copy-plus-SQL-export approach to avoid timeouts.
What’s the most common mistake in an AWS-to-Azure WordPress migration?
Missing the Azure-specific configuration details — particularly the WEBSITES_PORT setting and forwarded-proto HTTPS header handling — which don’t come up on other migration paths and can cause confusing redirect loops or 404s if overlooked.
Featured image: original illustration.