What this prompt does
This prompt frames the model as a senior WordPress and hosting engineer and asks for a zero-downtime migration plan specified tightly enough to execute — concrete steps and commands, not generalities. It is shaped by four placeholders: [new_host] (the destination), [site_size] (which dictates the database and media strategy), [current_host] (what you are moving off), and [maintenance_window] (the window the final cutover must fit inside).
The structure works because migration failures are almost always in the unglamorous parts — a missed search-replace, email that silently stops, a media folder that did not sync. By demanding an ordered runbook with a go/no-go checklist, the prompt turns the move into a repeatable procedure rather than a panic. Tying the database search-replace and media sync to [site_size] matters because a 4 GB WooCommerce site needs timeout-safe upload handling that a tiny blog does not. Naming [new_host] and [current_host] keeps the compatibility check and cutover commands grounded in the actual stacks involved, and bounding the final switch to [maintenance_window] forces the plan to be realistic about how long each step takes.
When to use it
- You are moving a client site to managed hosting and cannot afford visible downtime.
- You want a staging clone verified before any DNS change.
- You need a database migration with correct domain search-replace for
[site_size]. - You are migrating a large media library and keep hitting upload timeouts.
- You need a DNS cutover plan that fits inside a specific
[maintenance_window]. - You want post-cutover verification of forms, email, SSL, and SEO plus a tested rollback.
Example output
Expect an ordered runbook with real commands and a go/no-go checklist. It walks from cloning to a staging environment on [new_host] and confirming it loads identically, through a plugin/theme compatibility check, a database migration with search-replace sized for [site_size], a timeout-safe media sync, lowering DNS TTL ahead of a final sync and cutover inside [maintenance_window] from [current_host], and closing with verification of forms, email, SSL, and SEO plus a tested rollback plan.
Pro tips
- Set
[site_size]honestly (e.g. a 4 GB WooCommerce site) — it determines whether the media sync needs chunked or rsync-style handling to avoid timeouts. - Lower the DNS TTL well before the cutover so the actual switch inside
[maintenance_window]propagates quickly. - Never skip deliverable six: a homepage looking fine is not the same as forms and transactional email still working after the move.
- Confirm the staging clone on
[new_host]matches before touching DNS; catching plugin incompatibilities there is far cheaper than after cutover. - Keep the old
[current_host]live until verification passes so the tested rollback is real, not theoretical. - Run the search-replace with a dry run first so you can see what it would change before it rewrites the database for
[site_size]. - Walk the go/no-go checklist out loud before flipping DNS; a single unchecked item is usually what causes a midnight rollback.
