Migrate WordPress

Shared hosting — cPanel, a "unlimited" plan, a control panel you log into twice a year — was the default way to run WordPress for a decade. It's cheap until it isn't: a noisy neighbor on the same box slows your site, backups are something you keep meaning to set up, and "managed" means you're the one managing it. American Cloud managed WordPress gives you the other side of that trade — resource isolation, Redis object caching, AccelerateWP, SSL/TLS by default, automated backups, staging and cloning, and proactive monitoring — without you becoming a sysadmin.

This recipe moves an existing WordPress site there. Everything comes with it: themes, plugins, media, and the database. Your AI assistant — connected to the American Cloud MCP server — takes inventory of your current site, helps you stand up the destination, walks you through the documented migration method one step at a time, and handles the DNS cutover so traffic moves cleanly with your old host as a safety net until you're sure.

What this looks like

The move runs as a guided conversation in five phases. The first two are read-only — your assistant inspects, plans, and prices, and nothing is created or billed. The last three do the actual migration.

1. Inventory — take stock of what's on your current site so nothing gets left behind.
2. Set up the destination — create the managed WordPress instance and pick the right plan.
3. Migrate — move themes, plugins, media, and the database using the documented migration method.
4. Cut over DNS — point your domain at American Cloud with short TTLs and your old host still live.
5. Verify and decommission — confirm everything renders, then cancel the old hosting.

Phase 1: inventory your current site (read-only)

Before moving anything, get an honest picture of what your shared host is actually running. The goal is a checklist you can verify against after the move — so a missing plugin or a broken form shows up on a list, not as a surprise from a visitor.

Your assistant can't log into your cPanel account, so this phase is a structured interview plus whatever it can read from the live site. Open a chat and paste this.

I'm migrating a WordPress site off shared/cPanel hosting to American Cloud
managed WordPress. Don't change anything — help me take inventory first.
 
Build me a migration checklist by asking me for, and recording:
 
1. The site's current domain(s), and where DNS is managed today (the shared
   host, a registrar like GoDaddy/Namecheap, or Cloudflare).
2. The active theme and any child theme.
3. The full plugin list, and which plugins are licensed/premium (those may need
   a license re-activation after the move).
4. Roughly how big the site is: total disk used, database size, and the size of
   the uploads/media library. (I can read these from cPanel's file manager or
   the WordPress dashboard.)
5. Anything stateful I might forget: contact-form recipients, transactional or
   SMTP email settings, scheduled posts, custom .htaccess rules, and the
   permalink structure.
6. The list of pages and key URLs I'll want to spot-check after the move.
 
Then fetch my public homepage and a couple of inner pages and note what loads,
so we have a "before" reference to compare against later.

What your assistant will do

This phase touches nothing you're billed for and changes nothing on either host.

• Interviews you for the things only you can see — the cPanel disk usage, the premium plugin licenses, the SMTP credentials — and writes them into one checklist.
• Reads the live site where it can, capturing a "before" picture of the homepage and a few inner pages so you have something concrete to compare against post-migration.
• Flags the easy-to-forget items: form recipients, scheduled posts, the permalink structure, and any custom .htaccess behavior — the parts that look fine until someone fills in a form or hits a deep link.

The output is a plain-language inventory you'll check off in Phase 5.

Phase 2: set up the destination

Now create the managed WordPress instance your site will live on. American Cloud managed WordPress includes its own database and the full performance and security stack — caching, SSL, automated backups, staging — so the destination is a complete home, not a bare server you have to assemble.

There are two honest paths here, and your assistant can guide either:

• The dashboard is the documented walkthrough. WordPress hosting takes you click by click through choosing a plan, optionally entering a custom domain, reviewing the cost estimate, and creating the instance. If you'd rather see the screens and the cost panel before committing, do it here.
• The MCP server can do the same provisioning from the conversation. Your assistant can list the available plans, price your choice before anything is billed, and create the instance — then read back its nameservers, quota, and websites.

Either way, the plan menu and pricing are whatever the dashboard and the plans show — don't take a price from this page. Use the cost-estimate step (the assistant's preview, or the cost panel in the dashboard) for the real number.

Help me set up the American Cloud managed WordPress destination. Show me the
cost before creating anything.
 
1. List the available WordPress packages and summarize each one's disk,
   bandwidth, site count, and visit allowance so I can match it to the inventory
   from Phase 1.
2. Recommend the smallest package that comfortably fits my site's disk and
   media size, my expected traffic, and the number of sites I need to host.
3. Show me the cost estimate for that package — monthly and prorated — and wait
   for me to confirm.
4. Once I confirm, create the managed WordPress site on that package. Then read
   back its details: status, the temporary site address, the nameservers, and
   the quota.

What your assistant will do

• Lists and explains the plans. It calls list_wordpress_packages and lays each tier's disk, bandwidth, site limit, and visit allowance next to your Phase 1 numbers so the choice is grounded in your actual site, not a guess. For agency-scale or custom needs, it can point you to Enterprise WordPress plans.
• Prices before provisioning. get_cost_estimate_wordpress previews the monthly and prorated cost for the package you're leaning toward. Nothing is billed until you say go.
• Creates the instance with create_wordpress on the confirmed package, then reads it back with get_wordpress, get_wordpress_nameservers, and get_wordpress_quota — so you immediately have the temporary *.wpsquared.site address to migrate into and the nameservers you'll need in Phase 4.

Phase 3: migrate the site

This is where the content moves. American Cloud's documented self-service migration method uses the All-in-One WP Migration plugin: you install it on your existing site, generate a full-site export (themes, plugins, media, and the database in one file), and upload that export into your new American Cloud WordPress environment. Once it's imported, the site is verified, caching and performance features are enabled, and SSL is applied.

These steps happen inside WordPress itself, in the wp-admin of each site — not through MCP tools. That's the honest division of labor: the assistant is your patient guide through the documented method, and the MCP server gets you signed in and confirms the destination is healthy, but the export and import are clicks in the WordPress admin.

Walk me through migrating my site using American Cloud's documented method (the
All-in-One WP Migration plugin), one step at a time. Wait for me to confirm each
step before moving on.
 
Source side (my old shared/cPanel site):
1. Tell me how to install the All-in-One WP Migration plugin from the WordPress
   plugin directory.
2. Walk me through running a full-site export and downloading the export file.
   Tell me what should be included.
 
Destination side (my new American Cloud site):
3. Create a one-time admin login session for my American Cloud WordPress site
   and give me the link, so I can reach wp-admin without hunting for a password.
4. Walk me through installing All-in-One WP Migration on the new site and
   importing the export file I downloaded.
5. After import, tell me exactly what to check before I touch DNS: that the
   theme and child theme are active, the plugins are present (I'll re-activate
   any premium licenses), the media library loaded, and the permalink structure
   matches. Then read back the new site's quota and website list so I can
   confirm the database and files arrived at the size I expected.

What your assistant will do

• Guides the documented method, step by step. It points you at WordPress migrations and the All-in-One WP Migration plugin — install on the old site, export, import on the new site — and recommends only that method. (For very large media libraries, it'll suggest checking the export size against your new plan's quota first, so the import doesn't bump a limit.)
• Gets you into wp-admin without a password hunt. create_wordpress_session mints a short-lived, one-time URL that opens your American Cloud WordPress dashboard already signed in — handy for the destination side of the import. If you'd rather set a known password, your assistant can use update_wordpress_password (or you can update it from the dashboard).
• Confirms the destination is healthy. After the import, it reads list_wordpress_websites and get_wordpress_quota so you can see the migrated site listed and check that the database and files landed at roughly the size your inventory predicted — a quick sanity check that the whole site actually came across.

Phase 4: cut over DNS

With the migrated site verified on its temporary address, point your domain at American Cloud. The principle is the same as any careful cutover: lower your TTL first, switch second — so traffic moves fast and a rollback is just as quick.

Lower the TTL where your domain's DNS lives today. That's whatever host currently serves your domain — often the old shared host itself, or your registrar (GoDaddy, Namecheap), or Cloudflare if you put it in front. Drop the records' TTL to something short (for example 60 seconds) a day or two ahead of the switch. A high TTL means resolvers cache the old answer for hours; a low one means your cutover — and any rollback — takes effect in seconds.

Then make the change using the documented DNS setup. There are two supported ways to do it:

• Point your registrar's nameservers at American Cloud. Copy the nameserver values from the instance (your assistant reads them with get_wordpress_nameservers; they're also on the instance detail page), set them as your domain's nameservers at the registrar, and American Cloud automatically creates the A and CNAME records for your site.
• Keep your current DNS provider and create the records yourself — an A record for the apex and a CNAME for www, exactly as shown in WordPress hosting. If that domain's DNS is hosted on American Cloud, your assistant can create those records directly with create_dns_zone and create_dns_record (and set the short TTL on them); if it's hosted elsewhere, the assistant tells you the exact records to add at your provider.

Help me cut DNS over to the American Cloud site.
 
1. Read back the nameservers for my American Cloud WordPress instance.
2. My domain's DNS is currently at <where DNS lives — e.g. the old host, my
   registrar, or Cloudflare>. First, walk me through lowering the TTL on the
   relevant records there to 60 seconds, and let me do that a day before we
   switch.
3. When I'm ready, guide me through the cutover using the documented method:
   either repointing my registrar's nameservers at American Cloud, or creating
   the A and CNAME records per the WordPress hosting doc — at a short TTL.
4. If this domain's DNS zone is hosted on American Cloud, create those records
   for me directly with a 60-second TTL; otherwise tell me exactly what to enter
   at my current provider.
5. Then watch resolution until my domain resolves to the new site, and tell me
   when it's fully propagated.

What your assistant will do

• Reads the destination nameservers with get_wordpress_nameservers so you have the exact values to set at your registrar — no copying from a screenshot.
• Tells you where to lower the TTL. It won't assume your DNS lives on the old host; it asks, then guides you to drop the TTL at whichever provider actually serves your domain today, ahead of the switch.
• Follows the documented DNS setup. It guides the nameserver-repoint path, or the keep-your-provider A + CNAME path, per WordPress hosting. When the zone is on American Cloud, it creates the records itself with a short TTL (create_dns_record); otherwise it hands you the exact values for your provider.
• Watches propagation and confirms when your domain resolves to the new site — the moment the migration is "live."

Phase 5: verify, then cancel the old hosting

Don't cancel anything yet. Bring the migrated site fully into production behind your real domain, prove it works, and keep the old shared hosting paid up a little longer as your rollback. Walk the checklist from Phase 1.

The domain now points at the American Cloud site. Walk me through verifying it
against the Phase 1 inventory before I cancel my old hosting:
 
1. Load the homepage and each key page over HTTPS on my real domain and confirm
   they render — compare against the "before" reference we captured.
2. Confirm I can log into wp-admin on the live domain.
3. Test a contact form / transactional email so I know mail is sending.
4. Click through deep links and a few permalinks to confirm the permalink
   structure carried over (no 404s).
5. Confirm SSL is valid and the site loads without mixed-content warnings.
6. Read back the new site's bandwidth and quota usage so I have a baseline.
 
Give me a go/no-go summary. Only once everything passes, remind me what to do to
safely cancel the old shared hosting — and confirm I should NOT cancel the
American Cloud site.

What your assistant will do

• Verifies against the inventory, not from memory. It loads the homepage and every key page on your real domain over HTTPS and compares them to the Phase 1 "before" capture, confirms wp-admin login, exercises a form so you know mail flows, and clicks deep links to catch permalink 404s.
• Checks the baseline. get_wordpress_bandwidth and get_wordpress_quota give you a starting read on usage now that real traffic is arriving.
• Holds the rollback open. Because you lowered the TTL in Phase 4 and the old host is still up, reverting is just pointing DNS back — fast and complete. The assistant won't suggest decommissioning until you confirm everything passes.

Cancel the old shared hosting — when you're sure

Give it a few days. Watch the new site, confirm forms and email keep working, and make sure nothing still points at the old host. Then cancel the shared hosting account — at your old provider's control panel — and leave the American Cloud site running.

If you later need more room — more sites, more bandwidth — you don't migrate again: change the plan in place. Your assistant can list the upgrade options (list_wordpress_upgrade_packages) and move you with change_wordpress_package, or do it from the dashboard per WordPress hosting; existing sites and data are preserved.

Next steps

• WordPress hosting — the full lifecycle: creating a site, custom domains and DNS, changing plans, and adding sites
• WordPress migrations — the documented migration method, and the complimentary white-glove option
• Enterprise WordPress plans — reseller and custom plans for agencies and higher-capacity sites
• Write an AGENTS.md for your project — capture your conventions so future sessions repeat them
• Things to try with the MCP server — more prompt ideas across compute, storage, networking, DNS, and WordPress