@awesomate/hosting-mcp/skill/awesomate-app-builder/references/wp-migrate.md

Awesomate MCP server — lets Claude manage your Awesomate WordPress hosting, plan, limits, n8n automations, and build Node/static apps + databases

# Moving an existing WordPress site to Awesomate (and WP ↔ app coexistence)

When the stack decision lands on WordPress **and the user already has a WP
site elsewhere**, don't rebuild it — migrate it. Plain-language framing:
*"We'll make an exact copy of your current site on your Awesomate hosting,
check it works, then point your domain at it. Your old site stays untouched
until you're happy."*

## The migration path

1. **Provision WP on Awesomate first** — the awesomate-hosting skill's
   normal WP install (their plan's site limit applies; check
   `awesomate_get_limits`). This gives a working target with SSL.
2. **Export from the old host.** Preference order:
   - **A full-copy plugin** (Duplicator / All-in-One WP Migration): the user
     installs it on their OLD site and downloads the archive — the only step
     that happens outside Awesomate, so give them click-by-click guidance.
   - **Host export**: many hosts offer a backup download (files + a `.sql`).
   - **WP admin export (XML)**: last resort — content only (posts/pages/
     media), loses theme/plugins/settings; expect to reassemble the look.
3. **Import on Awesomate.** With shell access (Support Plus+) prefer
   `wp-cli` over the target install: unpack files into the docroot, import
   the DB, then `wp search-replace 'https://old-domain.com'
   'https://new-domain.com' --all-tables` (serialized-data-safe — never do
   this with raw SQL). Plugin archives restore through the same plugin
   installed on the new site.
4. **Verify before DNS.** Browse the copy on its Awesomate URL: pages,
   images, forms, admin login, HTTPS. Run **awesomate-seo** (sitemap,
   robots, meta). A migrated site brings its old plugins with it and stale
   plugins are the top WP risk, so check for outdated ones
   (`awesomate_run_wp_cli ['plugin','list']`), update what's safe to update,
   and flag anything abandoned to the user.
5. **Cut over DNS** — point the domain at Awesomate (add it as a custom
   domain first; plan limits apply). Old site stays live as the fallback
   until the user confirms; propagation can take up to a day and both
   copies serve during it (avoid content edits that day).
6. **After cutover:** confirm SSL issued for the domain, re-run the SEO
   check on the final URL, and remind them to cancel the old hosting only
   once everything's verified.

## WP ↔ app coexistence (they want both)

The platform already separates them cleanly — **WordPress owns the main
domain; every app lives on its own subdomain** (`app.domain.com`,
`dev-app.domain.com`, …). No conflict: Apache routes the main site to WP's
docroot and each subdomain to its app.

- Marketing/blog/shop stays in WP; the tool their customers log into is the
  Node app on a subdomain. Link between them with plain links.
- Don't try to serve an app *under a WP path* (`domain.com/app`) — that
  fights WP's rewrites. A subdomain is the supported shape.
- Shared look: reuse the WP site's colors/logo in the app's UI rather than
  loading WP themes into the app.
- Shared backend jobs (a form on either side emailing/CRM-ing): both can
  call the same n8n webhook — one workflow, two callers.

## When NOT to migrate

If the old "WP site" is really one landing page and they don't blog or
sell: recommend rebuilding it as a **static site** on Awesomate instead
(faster, nothing to update) — see stack-decision.md. Migration is for sites
with real content, plugins, or a shop.