What this prompt does
This prompt positions the model as a WordPress cloud migration specialist moving a [site_type] site from [current_hosting] to [target_cloud] with zero downtime. It runs six stages: auditing the current install, designing the cloud architecture, provisioning, migrating data, testing, and a DNS cutover.
The audit captures the facts that derail migrations — PHP version ([current_php]), [plugin_count] plugins, [upload_size] of media, [database_size], cron jobs, and server-specific config. The architecture maps onto [target_cloud] services: [compute_service] with PHP [target_php] and [web_server], [managed_database], [object_storage] behind [cdn_service], and [cache_service]. Provisioning via [iac_tool] makes it reproducible, and lowering DNS TTL to [low_ttl] before cutover with an [overlap_period] overlap is what keeps the move seamless.
The sequencing is deliberately conservative because cutover, not new infrastructure, is where migrations fail. Data moves in two passes: an initial copy of the [database_size] database and [upload_size] of media to [object_storage], then a final delta sync on cutover day so nothing posted in between is lost. Before DNS flips, the whole site is validated on a temporary domain against a checklist of [page_count] pages and a [target_ttfb] performance target. Keeping the old server live through the [overlap_period] gives a fallback while DNS propagates, which is what makes the move genuinely zero-downtime.
When to use it
- You are moving a WordPress site onto cloud infrastructure on
[target_cloud]. - The site is large enough (
[upload_size]media,[database_size]database) that a sloppy migration risks downtime. - You want media on
[object_storage]behind[cdn_service]instead of local disk. - You need reproducible provisioning via
[iac_tool]. - You want a tested rehearsal on a temporary domain before flipping DNS.
- You need a zero-downtime cutover with a rollback window.
Example output
Expect a phased migration plan: an audit checklist of the current install, an architecture diagram for [target_cloud] showing user to [cdn_service] to [compute_service] to [managed_database], provisioning steps in [iac_tool] with tuned PHP settings ([php_memory_limit], [max_upload_size]), a data-migration sequence using [sync_tool] and [s3_plugin] with search-replace, a pre-cutover test checklist hitting [page_count] pages against a [target_ttfb] target, and a DNS cutover runbook on [dns_provider] with an [overlap_period] overlap.
Pro tips
- Do the audit honestly; an undocumented cron job or
.htaccessrule is what breaks the cutover. - Provision with
[iac_tool]so you can rebuild the environment if the first attempt is wrong. - Lower the TTL on
[dns_provider]to[low_ttl]a day or two before cutover, not the morning of. - Do a final delta database sync on cutover day so nothing posted after the initial copy is lost.
- Keep the old server live for the
[overlap_period]to serve clients still holding cached DNS. - Validate
[target_ttfb]on the temporary domain before flipping, since fixing performance is easier pre-cutover.
