I've helped three Vancouver businesses migrate their WordPress content this year — two rebrands, one platform consolidation — and the difference between doing it manually and using Claude Code for WordPress content migration is the difference between a three-week nightmare and a two-day project. If you're staring down hundreds of blog posts, custom taxonomies, and embedded media that need to move from one WordPress install to another, this is how I'd recommend doing it in 2026.
The traditional approach to WordPress migration involves export/import plugins that work 70% of the time, leave broken image paths, drop custom fields, and require hours of manual QA. The Claude Code approach treats migration as a data transformation problem — extract structured content, map it to the new schema, and rebuild it programmatically. It's faster, more reliable, and leaves you with a clear audit trail of what moved where.
What Makes WordPress Content Migration Hard
WordPress stores content across multiple database tables. A single blog post might have its main content in wp_posts, its featured image reference in wp_postmeta, its category assignments in wp_term_relationships, and its author info in wp_users. Moving that post to a new site means reconstructing all those relationships in the new database without breaking anything.
The built-in WordPress export tool gives you an XML file. It's better than nothing, but it doesn't handle custom post types well, it skips most custom fields, and it often mangles media URLs during import. If your site has any customization beyond the default setup — and most business sites do — the XML export will leave gaps.
The other common approach is using a migration plugin like All-in-One WP Migration or Duplicator. These work well for cloning an entire site, but they're overkill if you just want to move content. And they don't help if you're merging two sites, or if the new site has a different permalink structure, or if you need to transform the data during migration.
How I Use Claude Code for WordPress Content Migration
My approach breaks migration into three phases: audit, extract, and rebuild. Each phase is its own Claude Code script, and each one solves a specific problem that used to take hours of manual work.
Phase 1: Pre-Migration Audit
Before touching anything, I run an audit script that crawls the source WordPress database and generates a migration plan. The script identifies:
- How many posts, pages, and custom post types exist
- Which taxonomies are in use (categories, tags, custom taxonomies)
- What custom fields are attached to each post type
- How many media files are referenced and where they're hosted
- Which posts have broken internal links or missing featured images
This audit usually surfaces issues you didn't know existed. On a recent client project, we discovered that 40% of the blog posts had broken featured images because the previous developer had hard-coded image URLs that pointed to a staging server. Catching that before migration saved hours of cleanup later.
Phase 2: Content Extraction and Transformation
The extraction script connects to the WordPress database (read-only), pulls all post data, and outputs it as structured JSON. Each post becomes a JSON object with normalized fields: title, slug, content, excerpt, author, publish date, taxonomies, custom fields, and media references.
The transformation happens here. If the new site uses different taxonomy names — for example, the old site used "News" as a category and the new site calls it "Blog" — I map that in the extraction script. Same with custom field names, author IDs, or post status changes.
The key advantage of this approach: you get to review the transformed data before it touches the new database. I export the JSON, spot-check a sample of posts, and make adjustments to the script if needed. Then I run the full extraction once and trust that the output is clean.
Phase 3: Programmatic Rebuild in the New Site
The final script reads the JSON and uses the WordPress REST API to create posts in the new site. It handles:
- Creating posts with correct post type, status, and publish date
- Assigning taxonomies (creating new terms if they don't exist)
- Uploading media files to the new media library and updating references
- Setting custom field values via the post meta endpoint
- Preserving the original post slug for SEO continuity
For a site with 300 posts, this rebuild takes about 45 minutes to run. Compare that to manually copy-pasting 300 posts, re-uploading images, and reassigning categories — which would take days.
Handling Media Files During Migration
Media is always the hardest part of any WordPress migration. Images, PDFs, and video embeds are scattered across posts, and WordPress stores multiple sizes of each image. If you just copy the database without the media files, every image path breaks.
My script handles this by downloading each media file from the source site, uploading it to the new site's media library via the REST API, and then replacing the old image URL with the new one in the post content. It's automated, but it's also the slowest part of the process because it's network-bound.
One optimization: if both sites are on the same server or if you have direct filesystem access, you can skip the download/upload step and just copy the files directly. The script updates the database references either way.
What About SEO and Redirects?
If the new site has the same permalink structure as the old one, you're fine — the URLs won't change. But if you're changing domains, switching from /blog/post-name/ to /post-name/, or consolidating multiple sites, you need redirects.
I generate a redirect map as part of the extraction phase. The script outputs a CSV with two columns: old URL, new URL. You can feed that directly into a redirect plugin like Redirection, or if you're on a managed host like WP Engine, you can upload it as a bulk redirect rule.
This is another area where Claude Code's SEO automation capabilities come in handy — the same script that generates redirects can also update internal links within the migrated content so they point to the new URLs. That prevents a cascade of 301 redirects that slow down page load times.
Custom Post Types and Advanced Custom Fields
If your site uses custom post types — say, a "Team Members" post type or a "Case Studies" post type — the migration script needs to know about those. Same with Advanced Custom Fields (ACF) or any other custom field plugin.
The extraction script detects custom post types automatically by querying the database. For custom fields, I usually generate a field map manually by exporting the ACF configuration from the old site and comparing it to the new one. Then I tell the script which fields to migrate and how to map them.
This is tedious if done by hand, but once the mapping is defined, the script can migrate thousands of custom field values without errors.
Testing the Migration Before Going Live
I never run a migration script directly on a production site. The workflow is always: run the migration on a staging copy of the new site, QA a sample of posts, fix any issues in the script, wipe the staging database, and run it again clean. Once the staging migration is perfect, I run the same script on production.
Claude Code makes this iterative process fast because you're working with code, not clicking through a UI. If you find an issue — say, excerpt text is getting truncated — you adjust one line in the script and re-run it. No need to manually edit 300 posts.
When Claude Code Migration Makes Sense
This approach works best if:
- You have more than 50 posts to migrate (below that, manual copy-paste might be faster)
- The content has custom fields, custom taxonomies, or non-standard structure
- You're merging two sites and need to transform data during migration
- You want a reproducible process in case you need to migrate again later
It's overkill if you're just moving five blog posts or cloning an entire site with no changes. For simple migrations, the standard WordPress export/import tool is fine. But for anything complex, the upfront time investment in writing migration scripts pays off immediately.
Common Mistakes to Avoid
The biggest mistake I see: running the migration without a backup. Even with a well-tested script, always have a full database backup of both the source and destination sites before starting. WordPress databases are easy to break and hard to fix manually.
Second mistake: not testing the migration on a representative sample first. If you have 1,000 posts, test the script on 50 posts before running the full batch. You'll catch edge cases — posts with unusual formatting, missing authors, embedded iframes that break — that don't show up in the first few posts.
Third mistake: ignoring the media library size. If you have 10 GB of images, the migration will take hours just to transfer files. Plan accordingly and don't run it during peak traffic hours.
Getting Started with Your Own Migration
If you want to try this approach for your own WordPress site, here's where I'd start:
- Set up a staging copy of your destination site and get database credentials
- Run a pre-migration audit to map out what you're moving
- Write a minimal extraction script for 10 posts and see what the JSON looks like
- Build the import script and test it on those 10 posts
- Expand to the full dataset once the process is working
If you'd rather have someone handle this for you, I do WordPress content migrations as part of my AI implementation consulting. The typical project takes 2–3 days and costs less than hiring a developer to do it manually. You can see more examples of automation workflows I've built in my post on WordPress automation with Claude Code.
And if you're wondering whether this approach works for other CMS platforms — yes, the same principles apply to Webflow, Shopify, or any system with an API. The scripts change, but the audit-extract-rebuild workflow stays the same.
For questions about whether this makes sense for your specific migration project, check the FAQ page — I've covered most of the common scenarios there.