“Rebuild” and “migration” are often used as if they describe the same WordPress project. They do not. A migration may preserve the application, content and URL model while moving hosting, domain or environment. A rebuild usually creates a new theme, plugin set, information architecture or data model and then decides what to carry forward. The distinction matters because the failure modes are different.
1. Name the change precisely
Write the current state and desired state in one page. Include domain, hosting, WordPress version, database, theme, plugins, custom code, content types, media, forms, analytics, redirects and integrations. Then label each item as preserve, transform, replace, retire or unknown.
If only the host changes and the application remains materially the same, a migration may be the smaller route. If the site needs a new content model, template system, checkout or CRM contract, call it a rebuild even if the files are copied. A truthful label prevents a “simple move” from hiding product and SEO work.
2. Map the assets and the system of record
Inventory database tables, uploads, theme files, plugins, mu-plugins, configuration, scheduled jobs, caches, search indexes, forms, comments, user accounts and external storage. Record the authoritative source for each asset. A media library may be in the database and filesystem; a form submission may live in a CRM rather than WordPress.
The WordPress upgrade guidance emphasizes backing up the database and all files, verifying that the backups are usable, and retaining critical configuration. Use that discipline for a migration or rebuild. A copied directory is not a verified recovery point.
3. Compare URL and search risk
A migration can still change URLs through domain, protocol, path, trailing-slash, language or permalink differences. A rebuild can also change titles, headings, canonicals, internal links, structured data and indexability. Make a URL inventory with current URL, proposed URL, status, canonical, redirect, owner and test evidence.
For a URL-changing project, plan redirects before content import. Check image URLs, feeds, sitemaps, robots rules, pagination, attachment paths and API endpoints. Google’s site-move guidance is a useful reminder to treat URL changes, redirects and verification as a controlled search transition. Do not assume that a 200 response means the right page survived. Compare purpose, content, metadata, conversion path and analytics event on representative samples.
4. Test backups and staging before touching production
Create a backup that can be restored in an isolated environment. Verify database integrity, file completeness, permissions, configuration secrets handling and media rendering. Record the restore time and the person who performed it. If the team cannot restore the backup, it is an archive, not a rollback plan.
Use a private development copy with synthetic form submissions and no accidental outbound email. WordPress documents a development copy workflow as a way to update and modify a site without interrupting the live version. Keep the staging domain blocked from indexing and production webhooks, then verify that those blocks are removed only in the approved release.
5. Identify plugin, theme and code dependencies
List every active plugin, its purpose, version, owner, data tables, scheduled events and replacement decision. Search custom code for shortcodes, hooks, template overrides, hard-coded URLs, cron jobs, REST routes, rewrite rules and environment assumptions. A rebuild that removes a plugin may also remove a form endpoint, redirect, custom field or reporting event.
Test combinations rather than only isolated components. A theme may render a page correctly while a cache, security rule or form plugin changes the response. Keep a compatibility matrix and decide who accepts a known limitation. Do not carry old custom code into a new architecture merely because it is familiar.
6. Plan tracking, forms and ownership handoffs
Trace one conversion from browser to form provider, CRM, analytics, ad platform and reporting dashboard. Preserve campaign parameters, consent behavior, event names, transaction IDs and ownership rules. Test success, validation error, spam rejection, duplicate submit and delayed response.
Record every external credential and integration owner without copying secrets into the project notes. Confirm domain verification, email sending, webhooks, payment callbacks, search console ownership and phone or call tracking. A launch is not complete when the page loads; it is complete when the commercial path remains traceable.
7. Estimate effort by failure surface
| Surface | Migration risk | Rebuild risk | Evidence needed | | — | — | — | — | | Files and database | incomplete copy or permissions | selective import loss | restore test | | URLs | host or protocol drift | new architecture and redirects | URL sample and crawl | | Content | encoding or media mismatch | rewritten or omitted content | content diff | | Theme and plugins | version or environment conflict | replacement behavior gaps | compatibility matrix | | Forms and CRM | endpoint or webhook break | new contract and field map | trace audit | | SEO | robots, canonicals or sitemap drift | intent and internal-link changes | pre/post QA | | Operations | unclear rollback | new release ownership | runbook and sign-off |
Price the unknowns explicitly. A large content volume, multilingual URLs, custom post types, e-commerce orders, memberships and long-lived integrations usually matter more than the number of templates.
8. Rehearse the handoff and acceptance
Run a rehearsal with a copy of the real data or a sanitized representative set. Measure restore, import, redirect, cache warm-up, form delivery and rollback time. Ask an independent reviewer to follow a page, a form and an admin task without the implementer’s help.
Create acceptance gates for public status, URL behavior, indexability, mobile layout, performance, analytics, forms, email, permissions and backup. Keep screenshots or logs tied to the release version. A staging green check proves only that the tested staging state passed; it does not prove that DNS, cache or production configuration persisted.
9. Choose the route with a decision table
Choose migration when content and behavior are stable, the hosting or domain move is the main change, and the current system can be supported. Choose a rebuild when the present architecture prevents required journeys, ownership is unclear, or the new content and integration model has been designed and tested.
Pause either route when there is no verified backup, no URL inventory, no owner for integrations, no private test environment, or no rollback window. Keep both routes available until the evidence closes the critical unknowns. A smaller project that cannot be reversed is not necessarily the safer project.
The practical comparison is not “old site versus new site.” It is “which state must remain trustworthy, which state may change, and how will we prove the handoff?” Make that contract explicit before moving files, importing content or changing DNS.
How did this article land?
Choose one reaction. You can change it anytime.
