You decided to leave WordPress. Good. Now the hard part starts: keeping content, SEO, auth, and media intact while you rebuild.
This WordPress to Laravel migration checklist walks through those four workstreams in order. You get a practical sequence, not a rewrite manifesto. If you still need the “why move” framing, read why developers are moving from WordPress to Laravel first.
Use this as a living document during discovery, parallel run, and cutover. Check items only when you have evidence, not when someone says “done.”
What this checklist covers (and skips)
This guide focuses on content, SEO, authentication, and media. Those four areas cause most cutover failures we see in migration notes and support tickets.
It does not cover ecommerce inventory, payment provider remaps, or full plugin feature parity. Drop unused features on purpose. Clone only what the business still needs.
For a product-level Laravel vs WordPress comparison, keep Laravel vs WordPress for 2026 open as a companion. This post is the migration ops checklist that sits next to that piece.
Before you touch code: freeze and inventory
Start with a freeze window for noncritical WordPress edits. Parallel content changes during export create painful merges.
Build an inventory sheet with these columns: post type, count, custom fields, taxonomies, public URL pattern, owner, and keep/drop decision. Include forms, cron jobs, and webhooks in a second sheet.
Export a full database dump and a media archive before any script runs. Store both with a dated label. You need a rollback path even if you plan a clean cutover.
Capture Search Console and analytics baselines now. Note top landing URLs, crawl errors, and indexed page counts. You will compare them after launch.
Content migration checklist
Content is more than posts and pages. Treat every content type as a contract between WordPress and your new Laravel models.
Map post types to models
List every custom post type and its meta keys. Decide which become Eloquent models, which become a generic Post type, and which you delete.
Write the target schema before you write importers. Columns, foreign keys, and indexes should exist in migrations first. Importers should fill known shapes, not invent them at runtime.
For taxonomies, map categories and tags to your new taxonomy tables or relations. Preserve slugs where public URLs depend on them.
Export without losing structure
Do not rely on a single XML export for complex sites. Use WP-CLI, a custom export script, or direct SQL for posts, postmeta, terms, and term relationships.
Preserve Gutenberg or classic HTML as an intermediate format. Then convert blocks into your Laravel content format in a second pass. One-pass “magic” converters hide edge cases.
Keep WordPress IDs in a mapping table on the Laravel side. You will need them for redirects, media attachments, and parent-child pages.
Validate content after import
Spot-check at least twenty high-traffic pages and twenty random pages. Compare title, body, featured image, and publish date against WordPress.
Search for broken shortcodes, empty ACF fields, and orphaned parents. Fix the importer, then re-run for that type. Manual one-off edits do not scale.
Editors should review a staging build with real content before cutover. They catch formatting issues engineers miss.
SEO migration checklist
SEO work is a mapping problem plus a measurement problem. Treat both as first-class tasks.
Build the URL and redirect map
Export every public URL from WordPress. Include posts, pages, archives, attachments you still need, and important query-string landing pages.
Prefer keeping the same path when the content still exists. When the path must change, add a 301 from old to new. Store redirects in a table you can audit.
Test redirect chains. A chain of three hops is a bug. Flatten to one hop before launch.
Carry meta and structured data
Export title tags, meta descriptions, canonicals, robots directives, and Open Graph fields from Yoast, Rank Math, or your custom fields. Map them to your Laravel SEO layer.
Rebuild XML sitemaps on Laravel. Submit the new sitemap in Search Console after cutover. Keep the old sitemap redirecting if it had inbound links.
Preserve structured data types you already use (Article, Organization, BreadcrumbList). Validate a sample with Google’s rich results tools after go-live.
Protect crawl health at cutover
Confirm robots.txt allows the paths you want indexed. Confirm noindex does not stay on staging headers after DNS flips.
Watch Core Web Vitals and server response times on day one. A slow Laravel deploy can cost rankings even when redirects are perfect.
Schedule Search Console reviews for two weeks, then again at thirty days. Log soft 404s and unexpected drops by template type.
Auth migration checklist
Auth is where user trust breaks. Plan passwords, roles, sessions, and third-party logins as separate work items.
Users and password hashes
WordPress uses phpass-style hashes by default. Laravel’s default is bcrypt (or Argon2). You have three common options.
Option A: force a password reset for every user at cutover. Simple and secure. Poor UX for large member bases.
Option B: import hashes and verify with a dual hasher on login. On success, rehash with Laravel’s hasher and store the new value. Users keep their passwords.
Option C: migrate only staff accounts and rebuild member auth from scratch. Use this when the old membership plugin is untrusted or incomplete.
Whatever you pick, document it for support. Ticket volume spikes when login fails after launch.
Roles and capabilities
WordPress roles and capabilities rarely map 1:1 to Laravel policies. Build a mapping table: old role, new role, permissions granted, and exceptions.
Test each role against real screens: edit post, publish, manage users, view private content. Automated tests help, but a human pass per role still matters.
If you use Spatie Permission or a similar package inside a Laravel admin, keep role names stable for editors where you can. Training cost is part of migration cost. For deeper RBAC patterns, see our RBAC guide with LaraDashboard.
Sessions, cookies, and SSO
WordPress cookies will not authenticate Laravel sessions. Plan a clean logout of old sessions at cutover, or accept that users must sign in again.
If you keep WordPress for marketing and Laravel for the app, decide which system owns login. Shared SSO is possible. It is also easy to get wrong across domains and cookie scopes.
Re-register OAuth apps (Google, GitHub, and others) with the new callback URLs. Update webhook secrets the same day. Stale callbacks are a common day-one outage.
Media migration checklist
Media breaks quietly. Pages look fine until an editor opens an old post and finds missing images.
Files, paths, and CDN
Copy the uploads directory (or your object storage bucket) in full. Preserve year/month paths if public URLs still use them. Changing media URLs without redirects hurts SEO and email archives.
If you move to S3 or similar, update the CDN origin and cache rules before cutover. Purge CDN caches after DNS flips for hot assets.
Record old attachment IDs to new media IDs. Featured images and gallery shortcodes depend on that map.
Rewrite references in content
After bodies import, run a URL rewrite pass for /wp-content/uploads and absolute domain links. Do it in the database or during import, then sample-check rendered HTML.
Handle srcset and resized variants. WordPress creates many sizes. Your Laravel stack may use fewer. Decide whether to regenerate or keep legacy files.
Scan for hotlinked internal media used in CSS, email templates, and PDF downloads. Those paths often sit outside the post table.
Permissions and private files
Private downloads and membership files need auth-aware routes in Laravel. A public bucket with old WordPress paths is a data leak waiting to happen.
Test a private file as an anonymous user and as an entitled user. Confirm 403 vs 200 behavior before launch.
Cutover day runbook (short version)
Put WordPress in read-only or maintenance mode if you can. Run the final content and media delta sync. Flip DNS or load balancer rules. Warm caches. Watch error rates and queues for at least an hour.
Keep a rollback window documented. If you must roll back, you need the old host, the old DNS TTL plan, and a message for editors.
After cutover, freeze new WordPress writes. Treat the old site as an archive, not a second CMS.
Where LaraDashboard helps on the Laravel side
Disclosure: LaraDashboard is our open-source Laravel admin and CMS. We recommend it when you need a structured back office for content, roles, and media after you leave WordPress.
It gives you posts and pages with a block editor, media library hooks, Spatie-based roles, and Sanctum APIs. Modules keep features isolated with their own migrations. That layout matches how many teams want to own the schema after a WordPress exit.
It is not a one-click WordPress importer. You still run this checklist. You still design models and redirects. For a product overview, see what Lara Dashboard is. For modular app structure, read building modular Laravel applications with Lara Dashboard.
Checklist summary table
| Area | Must finish before cutover | Common failure |
|---|---|---|
| Content | Schema map, ID map, sample QA | Lost custom fields |
| SEO | Redirects, meta parity, sitemap | Soft 404s after path changes |
| Auth | Hash plan, role map, OAuth callbacks | Login failures for members |
| Media | File copy, URL rewrite, private file tests | Broken images in old posts |
FAQ
How long does a WordPress to Laravel migration take?
Small brochure sites can move in a few weeks. Product sites with custom fields, memberships, and many URLs often take months. Content volume and integration count drive the calendar more than page count alone.
Can I keep WordPress URLs on Laravel?
Yes, and you should when the content still exists. Matching paths reduce redirect risk. Use 301s only when the path must change.
Do users need new passwords?
Not always. Dual verification with rehash on login lets users keep passwords. Forced reset is simpler for small staff teams. Pick one approach and tell users before cutover.
What about Yoast or Rank Math data?
Export the meta fields those plugins store, then map them into your Laravel SEO tables or package. Do not assume theme code will read WordPress meta after the move.
Should I migrate every media file?
Migrate everything still referenced by content, emails, or downloads. You can archive unused orphans separately. Deleting hot assets during cutover creates silent breakage.
Ending note
A WordPress to Laravel migration succeeds when content, SEO, auth, and media each have an owner, a map, and a test. Skip any of those and cutover day gets loud.
Work the checklist in phases. Freeze edits, import with ID maps, protect redirects and meta, plan password and role behavior, then move media with URL rewrites. Measure after launch.
If you want a Laravel-native admin and CMS starting point for the rebuild, try the LaraDashboard demo. Tell us in the comments which checklist item slowed your last migration the most.
