My hosting bill was about to rise roughly tenfold. The site held 348 published posts, 15 pages and just over 2,000 images, and two migration tools had already given me trouble. So I handed the job to Claude, an AI assistant connected to both sites, and kept the decisions for myself.
By the end of the second day the site was live on the new host, the number of active plugins had dropped from 40 to 11, and a new home page was running on it. It wasn’t smooth. That’s the useful part, so this post covers the detours, the tools, the limits and where things stand.
Why move, and why not just use a migration plugin
The cost increase was reason enough. The DreamHost migration app and the All-in-One WP Migration plugin had both failed on this site, so I chose a different route: a clean new WordPress install, the Astra Pro theme, as few plugins as possible, and a copy of the content. Fewer plugins means fewer security holes to patch, and it was a chance to make the design more modern.
The estimate, and why it was wrong
My first estimate was 4 to 6 hours of my own time over a week or two. It assumed that WordPress’s standard export and import could carry about 2GB of images in one pass. It can’t. The new host cuts each request off at 120 seconds, and importing 2,000 images means downloading every one and rebuilding its thumbnails.
The audit: what 40 plugins actually do
Claude read both sites and counted what depended on each plugin. The findings:
- About 72 table embeds from TablePress, across 57 stored tables.
- 27 posts with
[expired_link]tags, left behind by Broken Link Checker. They only display properly while that plugin is active. - Three pages that relied on plugins I had already removed, so they were showing raw tags.
I decided to drop TablePress and convert the tables to native WordPress table blocks, and to sell books through Stripe invoices instead of the old payment plugin.
Fixing the content before the move
It made sense to fix plugin-bound content on the old site first, so the export would carry finished content. Claude built a converter that rebuilt each table as a native block, keeping headers, footers, captions and links. It also rewrote the broken-link tags back into normal links. Every permanent change waited for my approval in a browser.
One honest miss: the first scan overlooked three table IDs. A leftover check at the end caught them.
The import: where it fell over
- The first full import brought in 1,664 images and no posts. It ran out of time on the media before it reached the posts.
- A small test with one category worked, which showed the process was sound and the size was the problem.
- Importing posts a year at a time worked, but re-running a batch created 330 duplicates: 33 posts and 297 images. The importer rewrites image addresses inside posts, so on a re-run it no longer recognises its own work.
- Claude spotted the duplicates by their pattern (an unbroken run of new ID numbers,
-1on filenames and-2on web addresses) and removed them through approval-gated deletes. - About 163 images from 2024 to 2026 were still missing, so a media-only export with a date range filled the gap.
Rebuilding what didn’t copy
Menus don’t travel in a posts export, so Claude rebuilt the 26-item main menu, plus a footer menu and the mobile menu. Three pages that depended on missing plugins (the list of articles, the all-posts archive and the buy page) were rebuilt with native blocks. The contact form was the one thing the AI couldn’t create, because the form plugin wouldn’t allow it, so I imported it myself and Claude pointed the Contact page at it.
Switching the live site, twice
The switch was the scariest part, and I did it twice. The first time, I pointed the domain at the new host and tested straight away. A scan of every image used by the 360 posts and pages found 371 files missing out of 4,662, many of them caused by my own duplicate clean-up, so I switched back the same morning.
I then copied the whole uploads folder across by SFTP, about 76,000 files. Raising the number of simultaneous transfers made it several times faster. A second scan found 39 images missing. Twenty-seven of those were already broken on the old live site, so only 12 were genuinely the migration’s doing, all of them wrong file names that can be corrected. To test the new host without sending visitors there, I added a line to my own computer’s hosts file, so my browser saw the new site while everyone else still saw the old one. Then I switched for good.
The new design
I pointed Claude at a site whose layout I liked and asked for the same structure, with my three book parts in place of its list of priorities. The result is a storm-blue and amber home page built entirely from standard WordPress blocks and the Astra theme: a hero with three calls to action, three part cards, a block for each part, a short bio, three questions I use to test every technology, and a closing call to action. It was built as a hidden draft first, so nothing changed for visitors until I approved it.
The tools and connectors
| Tool | What it did |
|---|---|
| Claude | The AI assistant that planned, audited, converted, cleaned, rebuilt and drafted. |
| WPVibe (WordPress connector) | Runs WordPress commands, database queries, REST calls and bulk jobs on a site. Permanent changes pause for my approval in a browser. The free plan has a daily limit of 100 calls. |
| WSP MCP (second connector plugin) | Reads and edits posts, pages, menus, media and SEO fields, and is not tied to the WPVibe daily allowance. |
| Cloudflare connector | Read and changed DNS records, SSL settings and redirect rules, with each change confirmed with me first. |
| A browser connector | Opened pages in my own browser to check images, forms and redirects as a visitor would see them. |
| WordPress Importer | The standard WordPress export and import, removed once the move was done. |
| FileZilla | My own tool for the SFTP upload of the images. |
| Astra and Astra Pro | The theme for both sites. |
| Yoast SEO, WPForms Lite, WP Super Cache, WPConsent, WP Mail SMTP | The plugins kept on the new site. |
| Web page fetching | Reading a reference site and checking how rendered pages looked as text. |
| All-in-One WP Migration | Used for backups only, not for the move, and kept for taking site snapshots. |
The limitations
- The AI can’t upload or download files in wp-admin. I ran every export and import myself.
- The host’s 120-second limit shaped everything about the import.
- The new host’s firewall returned server errors for some database queries. I don’t yet know exactly what it was blocking, and I’m checking with DreamHost.
- The form plugin wouldn’t let the connector create forms.
- The connector’s daily allowance ran short on both days, so some jobs had to wait for it to refill.
- Approval links expired once, which stalled a step until they were re-issued.
- The AI can’t see a page the way you do. It checked structure, colours and text, but I still had to look at the result on a phone and a laptop.
- Some things didn’t carry over: two Markdown working files (WordPress rejects that file type) and one draft post.
The end result
| Old site | New site | |
|---|---|---|
| Published posts | 348 | 348 |
| Pages | 15 | 12 (four retired on purpose, new home page added) |
| Images and files | 2,061 importable | 2,055 |
| Images the posts use that were missing | 0 expected | 371 at first, 39 after the upload (27 already broken on the old site) |
| Active plugins | 40 | 11 once the last temporary tool is removed |
| Table embeds from a plugin | about 72 | 0, now native blocks |
| Posts with broken-link tags | 27 | 0 |
| Main menu items | 26 | 26, rebuilt |
The site went live on DreamHost on Friday 6 November: the domain points at the new host through Cloudflare, www redirects to the bare address, the certificates are in place, the contact form is back and the new home page is live. Every category’s post count matches the old site exactly. Still to do: correct 12 image references, scan the external links for dead ones (I can say what was fixed, but not yet how many dead external links remain), remove the last temporary plugin, and cancel the old host after a few days.
What I’d tell you if you’re doing this
- Audit what depends on each plugin before you delete any of them.
- Fix plugin-bound content on the old site first.
- Never re-run an import once images have been fetched. Split it into smaller pieces instead.
- Check your host’s request time limit before you start.
- Compare counts at every stage: posts, pages, images and category totals.
- Scan every image your posts use before and after the switch, not just a sample.
- Test the new host with your computer’s hosts file before you point the real domain at it.
- Make destructive steps ask for approval, and read the list before you approve.
- Keep the old host until the new site is checked, and be ready to switch back.
If you’re planning a move like this and want to know whether something I hit applies to your site, ask me in the comments or get in touch.