Moving from WordPress to a Laravel CMS: A Developer's Migration Guide (2026)

Export, map fields, move media, and keep every URL redirected

July 27, 2026 · 10 min read
Moving from WordPress to a Laravel CMS: A Developer's Migration Guide (2026)

WordPress powers around 43% of the web, and that scale comes with a target on its back. In 2024, security firm Patchstack logged over 7,900 new vulnerabilities in the WordPress ecosystem — and 97% of them lived in plugins and themes, not the core. If you're a Laravel developer maintaining a WordPress site, you already feel this: every plugin you add is another dependency you didn't write, can't fully audit, and have to patch on someone else's schedule.

This guide walks through moving from WordPress to a Laravel CMS — why developers make the jump, what you gain, the actual migration steps, and the traps that catch people. It's written for people who already know PHP and want their content stack to feel like the rest of their codebase.

TL;DR

Moving from WordPress to a Laravel CMS trades a plugin-driven black box for code you control. You get real MVC, Eloquent ORM, Composer dependency management, and Blade or React views instead of the WordPress template hierarchy. The migration is scripted, not one-click — there's no magic importer button. You export WordPress content (via the WP REST API or a WXR/SQL dump), map each field to your new post model, move media, set up 301 redirects for any URL that changes, rebuild the theme, and verify SEO. Budget a weekend for a small blog, a few weeks for a large site with custom fields and shortcodes. The payoff: a CMS that reads like Laravel because it is Laravel. For a side-by-side breakdown, see our Laravel CMS vs WordPress comparison.

Why move from WordPress to Laravel?

Three reasons: security, developer experience, and plugin bloat. WordPress security holes almost always come through third-party plugins you can't audit. The developer experience fights modern PHP — no first-class dependency injection, no Composer-native workflow, hooks and filters instead of clean service classes. And a typical site drags 20-30 plugins just to reach feature parity with what a framework gives you out of the box.

If you've already decided the framework is right for you, our Laravel CMS landing page covers what a purpose-built option looks like. Someone who made this exact move wrote up their reasoning in this migration story.

What does a Laravel CMS actually give you?

Real MVC structure, Eloquent models for your content, Composer for dependencies, and your choice of Blade or React for views. Instead of functions.php growing to 2,000 lines, you get controllers, services, and jobs. Instead of wp_query and the loop, you write Post::published()->latest()->paginate(). Content becomes an Eloquent model you can query, cast, and relate like any other table.

Here's the concrete difference:

// WordPress: the loop, global state, string-keyed meta
if (have_posts()) {
    while (have_posts()) {
        the_post();
        $price = get_post_meta(get_the_ID(), 'price', true);
    }
}

// Laravel CMS: an Eloquent model, typed, testable
$posts = Post::published()
    ->with('category')
    ->latest('published_at')
    ->paginate(12);

The second version is testable, IDE-friendly, and reads like the rest of your app. No global $post, no guessing whether a meta key returns a string or an array.

WordPress vs Laravel CMS: the honest comparison

Both host content. They diverge hard on how you build and maintain. Here's where each lands on the things a developer actually cares about day to day.

Concern WordPress Laravel CMS
Language patterns Hooks, filters, globals MVC, DI, service classes
Data access WP_Query, get_post_meta Eloquent ORM, query builder
Dependencies Plugins (mixed quality) Composer packages, versioned
Templating Template hierarchy, PHP Blade / React (Inertia)
Custom content ACF plugin + meta tables Migrations + model fields
Testing Awkward, rarely done PHPUnit / Pest, first-class
Security surface Large (plugin CVEs) Smaller (code you own)
Version control DB-heavy, hard to diff Code + migrations, git-native

The trade-off is real: WordPress hands you a click-to-install plugin for almost anything. A Laravel CMS asks you to write (or find a package for) some of that. What you buy back is a codebase you can read, test, and version.

How do you migrate the content?

Export from WordPress, map fields to your new post model, then import. The cleanest source is the WordPress REST API (/wp-json/wp/v2/posts) — it returns JSON with title, slug, content, excerpt, dates, and categories already structured. Alternatives are a WXR export (Tools → Export) or a direct SQL dump of wp_posts. There's no one-click importer; you write a script.

A REST-API pull looks like this:

$response = Http::get('https://old-site.com/wp-json/wp/v2/posts', [
    'per_page' => 100,
    'page' => $page,
]);

foreach ($response->json() as $wp) {
    Post::create([
        'title'        => $wp['title']['rendered'],
        'slug'         => $wp['slug'],           // keep the slug — SEO depends on it
        'body'         => $wp['content']['rendered'],
        'excerpt'      => $wp['excerpt']['rendered'],
        'published_at' => $wp['date'],
        'status'       => $wp['status'] === 'publish' ? 'published' : 'draft',
    ]);
}

Keep the original slug. That one field decides whether your existing Google rankings survive the move.

The migration checklist

Run these in order. Each step de-risks the next.

  1. Audit the source. Count posts, pages, media, custom post types, and plugins in active use. Note every plugin that injects content (shortcodes, forms, galleries).
  2. Export content. Pull via the WP REST API (/wp-json/wp/v2/posts and /pages), or take a WXR export, or dump wp_posts and wp_postmeta directly.
  3. Map fields to your post model. WordPress post_titletitle, post_nameslug, post_contentbody, post_datepublished_at. Decide what to do with custom fields now, not later.
  4. Write the import script. A Laravel command that reads the export and creates Post / Page records. Idempotent, so you can re-run it.
  5. Migrate media. Download /wp-content/uploads/, re-upload into your CMS's media store, and rewrite <img> URLs in post bodies to the new paths.
  6. Set up 301 redirects. Any URL that changes needs a permanent redirect. UnfoldCMS ships an admin Redirects module with slug history so old WordPress URLs keep resolving to the moved content.
  7. Rebuild the theme. Port your design to Blade or React components. This is real work — budget for it.
  8. Verify SEO. Regenerate the sitemap, check robots.txt, fill in meta titles and descriptions, and confirm canonical tags. Crawl the new site and diff URLs against the old one.
  9. Cut over. Point DNS, watch your logs for 404s, and fix broken redirects as they surface.

If you want a guided version of this flow, we've collected it on our migrate from WordPress page.

Handling media and URLs without losing rankings

Media and URLs are where migrations quietly break SEO. WordPress stores uploads under /wp-content/uploads/YYYY/MM/, and those paths are baked into every post body as absolute or relative <img src>. If the new paths differ, images 404 and body links rot.

Two fixes. First, pull every file from /wp-content/uploads/, import it into your CMS media library, and run a search-replace over post bodies to swap old image URLs for new ones. Second, for every URL that changes — permalink structure, category bases, dated archives — add a 301 redirect. A CMS with a redirects module and slug history makes this a data task, not an Nginx-config task, so editors can add redirects without a deploy.

What breaks during a WordPress migration?

Three things bite people: shortcodes, custom fields, and comments. WordPress shortcodes like [gallery] or [contact-form-7] are plugin-specific and mean nothing outside WordPress — they'll show as literal text unless you replace them. ACF and custom meta live in wp_postmeta and need explicit mapping. Comments are a separate table entirely.

Here's how to handle each:

  • Shortcodes. Grep your exported content for [ patterns. Each shortcode needs a decision: render it as static HTML, rebuild the feature natively, or drop it. [caption], [gallery], and form shortcodes are the usual suspects.
  • Custom fields / ACF. Query wp_postmeta for the keys you actually use (ignore the _transient and internal _edit_* noise). Map each to a real column, a JSON field, or a related model. Don't blindly copy every meta row — most are junk.
  • Comments. They live in wp_comments. If you're keeping them, migrate to your CMS's comment system or a hosted service. If you're not, export them as a backup before you drop the old database.

Test the import on a staging copy first. You'll find shortcode and meta surprises there instead of in production.

Is a Laravel CMS the right move for your project?

If you're a PHP developer who already works in Laravel, yes — the CMS stops fighting the rest of your stack. If your team is non-technical and relies on WordPress's plugin marketplace for everything, weigh the trade carefully. The framework gives you control and a smaller security surface; it asks you to write or source features that WordPress hands over as plugins.

For most Laravel developers maintaining a content site, the maintenance and security wins pay for the migration within the first year. We compared the main options in best Laravel CMS options for 2026.

FAQ

Is there a one-click WordPress-to-Laravel importer? No, and anyone claiming otherwise is overselling. Migration is scripted: export via the WP REST API or SQL, map fields to your post model, and run an import command. UnfoldCMS gives you the target model, a redirects module, and SEO fields — you write the mapping script for your specific content.

Will I lose my Google rankings? Not if you keep your slugs and set up 301 redirects for every URL that changes. Rankings follow the redirect. The danger is silent 404s, so crawl the new site and diff its URLs against the old sitemap before cutover.

What happens to my ACF custom fields? They live in wp_postmeta and need manual mapping. Query for the meta keys you actually use, then map each to a column, a JSON field, or a related Eloquent model. Skip the internal _edit_* and transient rows.

How long does a migration take? A small blog with clean content: a weekend. A large site with custom post types, ACF, shortcodes, and thousands of media files: a few weeks. The theme rebuild and shortcode replacement usually dominate the timeline, not the content export.

Do I have to rebuild my theme from scratch? Yes — WordPress themes are PHP tied to the WordPress template hierarchy and don't port directly. You rebuild the design as Blade or React components. It's real work, but you end up with a component-based frontend instead of header.php, footer.php, and single.php.

Where to go next

If Laravel is already your stack, a CMS built on Laravel 12 + React 19 + Inertia + shadcn/ui means your content layer speaks the same language as your app. UnfoldCMS is self-hosted, ships posts/pages/categories, a REST /api/v1/*, sitemap and robots generation, SEO fields, and the admin Redirects module with slug history that makes preserving WordPress URLs a form field instead of a config file. Start with the migrate from WordPress guide and map your first ten posts as a proof of concept before committing to the full move.


Sources: WordPress market share and CVE figures from W3Techs and Patchstack's annual State of WordPress Security report (2024). Field-mapping and REST API details reference the official WordPress REST API handbook. All code samples are illustrative — adapt them to your content shape.

Free & Open Source

Own your CMS. No subscriptions.

Unfold CMS is free to download and self-host. Built on Laravel + React, full source code included.

Share this post:

Discussion

Comments (0)

Leave a Comment

Please log in to leave a comment.

Don't have an account? Register here

No comments yet. Be the first to share your thoughts!

Keep Reading

Related Posts

Back to all posts