How can a single migration step trigger outages across hundreds of franchise locations? Moving a large multisite often touches DNS, payment endpoints, and data residency needs. Without orchestration, small errors amplify into multi-site downtime and SLA penalties.
Migrate large-scale WordPress multisite for franchised businesses: a turnkey playbook with infrastructure patterns, zero‑downtime tactics, automation scripts, domain and TLS mapping, rollback plans, compliance checks, and realistic timelines. Use the benchmarks and ready-to-run automation to validate vendors and timelines before executing.
Process summary
- Inventory and baseline: collect sites, domains, plugins, and traffic metrics.
- Architect and compare hosts: pick managed, cloud, or hybrid with DB patterns.
- Build staging parity: replica DB, object storage, and sync pipelines.
- Pilot wave: migrate 5–20 representative sites and validate tests.
- Bulk automation: run rsync, WP-CLI tasks, and ACME provisioning in waves.
- Cutover with LB weight or DNS low-TTL and monitor for regressions.
- Rollback if errors exceed thresholds; preserve snapshots and binlogs.
Reproducible automation
For large franchise networks use repeatable CI jobs and idempotent wrappers that run in waves. A practical pipeline has stages: prepare, initial sync, incremental sync, serialized DB dry-run, final cutover, and validation. Implement per-site locks in object storage or a DB flag to avoid concurrent workers touching the same site.
Record checkpoints to S3 and use exit codes with retry backoff for network failures. A Bash wrapper can run wp db export to a time-stamped file, and then run rsync with a consistent include/exclude list. A matching GitLab or GitHub Actions job can orchestrate N parallel workers that queue jobs from a CSV.
Include health-check hooks that call smoke tests and fail the pipeline when thresholds are exceeded. Make every step observable and rerunnable safely without corrupting site state.
Step 1: prepare inventory and baseline
Gather a complete inventory and produce a baseline report for every subsite. The inventory must include domains, blog IDs, plugins, themes, traffic, and last modified dates. Export a CSV with blog_id, domain, admin_email, wp_version, and object_storage_flag.
Plugin and code audit
List plugins and note premium licenses and known conflicts. Flag plugins that write to the filesystem or call external APIs. A common error is assuming all plugins behave the same across sites.
Measure the 95th percentile response time per site and peak concurrent users. Run synthetic tests from US East and US West. Record CDN cache hit ratios and monthly egress.
Inventory export commands
Use WP-CLI and SQL to export site lists and active plugin lists. Example: wp site list --format=csv > sites.csv. Example: wp plugin list --format=json > plugins.json.
Step 2: compare hosting architectures and vendors
Choose an architecture that fits throughput, compliance, and ops skill. Collect measurable benchmarks and vendor answers to RFP fields. Use the table and checklist to score vendors for SLA, TLS automation, and DB support.
Vendor RFP fields to request
Request SLA uptime percent, RTO and RPO, managed DB options, and DNS API limits. Ask for sample TTFB measured under 50 concurrent users and for 95th percentile response times. Demand explicit answers on cert automation and rate-limit handling.
Hosting patterns and tradeoffs
Managed WordPress cuts ops work but may restrict plugins and costs rise at scale. Cloud VMs or containers give full control and suit teams with SRE skills. VPS is low cost but needs full ops for high availability and backups.
DB and storage patterns to require
Request managed RDS or Aurora with read replicas and ProxySQL for pooling. Demand S3, GCS, or Blob object storage for media with CDN fronting. Ask vendors about physical snapshots and point-in-time recovery support.
| Provider |
SLA |
Managed DB |
TLS automation |
Estimated monthly cost |
| AWS (custom) |
99.95% |
RDS/Aurora, replicas |
ACM, Cert Manager |
$2k–$20k+ |
| WP Engine |
99.95% |
Managed |
Built-in |
$1k–$10k+ |
| DigitalOcean |
99.99% |
Managed DB optional |
ACME via API |
$500–$5k+ |
Estimated cost bands include compute, managed DB, CDN, and object storage. Actual costs vary by traffic and data egress.
Step 3: build staging parity and replication
Create a staging environment that matches production architecture. Enable continuous DB replication and incremental file sync for media. Use this environment to validate plugins and theme behavior at scale.
DB replication and snapshots
Set up a managed replica and configure ProxySQL or RDS Proxy for pooling. Use physical snapshots for fast restore during cutover. Percona pt-table-checksum helps detect divergent rows across replicas.
Offload media to object storage and serve via CDN to cut origin load. Sync initial media with aws s3 sync and then use the app offloader. Check object counts and file checksums between source and target.
Staging validation tests
Run API smoke tests for login, search, and checkout flows. Run SEO checks for canonical tags and redirects. Automate screenshot-based UI checks for representative sites.
A simple visual shows the main flow.
Inventory
→
Staging parity
→
Pilot wave
→
Bulk automation
→
Cutover
Step 4: pilot migration wave and validation
Run a pilot on representative subsites to validate process and timing. Measure real cutover times, DB lag, and failure modes during the pilot. Use pilot results to tune scripts and resource sizing.
Selecting pilot sites
Pick 5–20 sites that cover low, medium, and high traffic. Include sites with payment flows and custom plugins. Include custom domains and subdomain patterns.
Pilot execution checklist
Run initial DB export and initial rsync for wp-content. Enable binlog replication and run incremental rsync for 24 to 72 hours. Perform WP-CLI search-replace dry runs and serialized checks.
Pilot validation commands
DB export example: mysqldump --single-transaction --routines --triggers --events --hex-blob --databases wp_multisite_db | gzip > dump.sql.gz. Safe search-replace example: wp search-replace 'old.example.com' 'new.example.com' --network --skip-columns=guid --recurse-objects --report-changed-only.
Stop and review pilot outputs.
Step 5: automate bulk migration and domain/TLS
Scale pilot scripts into repeatable CI jobs. Automate domain mapping and certificate issuance in controlled batches. Use queueing to avoid hitting CA and DNS provider rate limits.
Automation scripts and CI stages
Pipeline stages: build, deploy staging, run DB export, run rsync, run WP-CLI updates, run smoke tests. Example rsync: rsync -azP --delete --exclude='cache/' /srv/www/site/wp-content/ user@newhost:/srv/www/site/wp-content/. For object storage: aws s3 sync /srv/www/site/wp-content s3://brand-bucket/wp-content --storage-class STANDARD.
Mass domain provisioning
Prepare a mapping CSV with blog_id, old_domain, new_domain, canonical. Run a batch script to wp site update and flush rewrite rules for each row. Throttle ACME issuance and use DNS-01 with provider API for scale.
TLS patterns and rate limits
Let's Encrypt limit: 50 certificates per registered domain per week (2024). Use CDN edge TLS to offload certificate work where possible.
Project playbook
Translate high-level estimates into a repeatable playbook with named roles and a sample calendar. For a 100-site wave use Week 0–1 discovery, Week 2 staging parity, Week 3 pilot, Weeks 4–5 bulk waves, and a cutover week with on-call coverage. Use role-hour buckets to price vendor labor and run multiple waves in parallel.
Example role-hour summary per 100 sites: PM 40–80h, SRE/Infra 120–300h, Dev/Migrations 80–220h, QA/Automation 40–120h, Legal/Compliance 8–24h, TLS/DNS 16–40h.
Use pilot waves to validate assumptions and shrink per-site effort for later waves. The playbook should include wave cadence, gating criteria, and explicit handoffs for licensing and vendor procurement.
Step 6: cutover with zero‑downtime orchestration
Execute a controlled cutover using LB weights or DNS low TTL. Monitor errors and DB replica lag during the weight shift. Keep rollback plans ready and validated with runbooks and snapshots.
Load balancer weight shift
Add green servers with a 1 percent weight and increase slowly while watching errors. Move to 100 percent over 15 to 60 minutes when metrics stay low. If errors spike, revert weights to blue immediately.
DNS low‑TTL switchover
Set TTL to 60 seconds 48 hours before cutover. Make final incremental syncs and update A and CNAME records at cutover time. Expect some CDN caching delays and plan cache purge workflows.
Session and cache handling
Use a shared Redis session store to avoid login issues during cutover. Purge CDN caches after final sync and before final promotion. Watch 500 responses, login failures, and payment errors closely.
Automated zero‑downtime orchestration
At franchise scale, manual shifts and ad-hoc rollbacks carry high risk. Implement an orchestrator that automates canaries, health checks, and rollback actions. The orchestrator should deploy green nodes, route a 1 to 5 percent canary, run smoke tests, and monitor SLO signals.
Define concrete thresholds to auto-trigger rollback APIs. Example thresholds: error rate greater than 2 percent absolute or 200 percent relative, 5xx spike over 0.5 percent of requests, DB replica lag over 5 seconds. Auto-trigger rollback APIs that revert LB weights, re-enable source writes, and mark the wave failed.
For write consistency, use a short dual-write window or route writes through a write-forwarding proxy that can replay or drain later. Automate rollback validation: after a revert, run integrity checks and only clear incidents when checks pass.
Automation turns human judgement into rules and reduces mean time to repair across hundreds of sites.
Step 7: validate, monitor, and roll back if needed
Run automated integrity checks and smoke tests immediately after cutover. If errors exceed thresholds, run the rollback runbook within the planned window. Keep all artifacts and logs for post-mortem and fixes.
Automated integrity checks
Run row counts, checksums, and Percona checksums to confirm DB parity. Compare media counts and checksums between source and object storage. Run functional smoke tests for auth, checkout, and search.
Rollback runbook
Fast rollback via LB weight revert takes under five minutes. Full rollback using snapshots and binlogs takes thirty to one hundred eighty minutes depending on DB size. Always validate post-rollback with the same integrity checks.
Example rollback commands
Revert LB weights via API or CLI to the original pool and drain new nodes. If reverting a DB, restore a snapshot and apply binlogs for point-in-time recovery. After rollback, purge CDN caches and clear session stores.
Errors that ruin a franchise migration
Treating a multisite as a single site leads to underestimated effort. Ignoring domain and TLS orchestration causes prolonged HTTPS outages. Skipping automated validation and rollback leads to hidden data loss.
Common DB mistakes
Assuming logical dumps scale well and using them alone causes long cutovers. Not using connection pooling leads to exhausted connections and outages. A common mistake is relying on single-threaded imports for large databases.
Domain and TLS mistakes
Issuing thousands of certificates at once triggers CA rate limits. Not validating DNS API quotas causes partial failures and stalled mapping. A case often seen: mass DNS changes to a low API limit provider that stall the migration for hours.
Operational mistakes
Running manual checks at scale misses permission and serialized data issues. Not staging the exact stack causes missing edge cases under load. Automation and testing catch the real problems weeks before cutover.
When this method does not apply
This playbook is not appropriate for single-site moves or very small multisite installs under ~20 subsites. Do not apply it when the chosen vendor provides a fully managed, SLA-backed franchise migration that includes automated testing and rollback. Also avoid this approach when legal or data residency rules force per-location single-site isolation instead of centralized multisite.
Request formal vendor migration estimates, timelines, and a written runbook before final vendor selection to validate capacity and costs, and ask for responses to this playbook and the RFP fields above to produce comparable timelines and cost estimates for your franchise migration.
Frequently asked questions
What are realistic hours and costs per 100 or 1,000 subsites?
Expect between 100 and 220 engineering hours per 100 subsites. Expect calendar time of two to six weeks for an experienced migration team with vendor APIs. For heavy custom code or strict compliance increase estimates by 1.5x to 3x and extend the calendar window. For 1,000 subsites expect 400 to 1,200 hours and six to sixteen weeks.
The estimated contracted cost for a 100-site wave is about $9k to $33k at typical hourly rates. For 1,000 sites estimate $36k to $180k depending on complexity and compliance.
How should TLS be provisioned for thousands of domains?
Use per-domain ACME with DNS-01 validation and batch issuance to respect rate limits. Offload TLS to a CDN or edge provider when possible. Wildcards fit only subdomain fleets, not custom franchise domains.
Use provider APIs for DNS automation and caching strategies to avoid rate limits. Maintain a certificate cache and reuse certs for renewals.
When is DB sharding needed for multisite?
Consider sharding when sustained writes exceed 100 to 200 transactions per second or when DB size passes 1 to 2 terabytes. Sharding reduces single-node write hotspots and improves parallel work. If write throughput stays moderate, managed RDS with read replicas and ProxySQL is usually sufficient and simpler to run.
How to validate serialized data and search-replace operations?
Run WP-CLI search-replace with serialized data support and run dry runs first. Compare reports and sample serialized objects for integrity before final replacements. Keep a full DB export and test restores in staging to ensure deserialization does not corrupt widgets or options.
How long do rollbacks take and what are the steps?
Fast rollback via load balancer weight revert takes less than five minutes. Full rollback using snapshots and binlogs can take thirty to one hundred eighty minutes depending on DB size. Always snapshot DB and files right before cutover and retain binlogs for point-in-time recovery.
How to handle SEO and redirects during migration?
Validate canonical URLs, hreflang, and redirect maps in staging and pilot waves. Preserve permalink structures and map old paths to new ones with 301 redirects. Use sampling checks and full sitemap comparisons to confirm no-index or canonical issues.
Closing notes and references
The data points and runbooks here aim to make vendor selection measurable and repeatable. Let's Encrypt rate limits and Percona tools referenced above give practical limits and checks for high-scale migrations. The legal and compliance checklist should be reviewed with legal counsel and the brand compliance officer.
For visual evidence of the flow and checklist, the infographic above shows the recommended step sequence.
Estimated staffing and hours are baseline scenarios for 2026 planning: pilot and automation cut 30 to 60 percent of per-site manual work for subsequent waves.
Which hosting architecture is best for franchise migrations?
Choose managed WordPress if the vendor supports mass domain mapping and has the required features and SLAs.
