You run a small WordPress site. It has five or six pages, a contact form, and a blog with a few dozen posts. You want to move it to a Laravel CMS, and you want proof that the move went well. That proof is what a case study gives you.
This post is a case study template for migrating a brochure and blog to LaraDashboard. You get the steps in order, the numbers to record before and after, and a write-up structure you can fill in. The short answer: inventory first, freeze content, move pages and posts, map every old URL to a new one, then measure for 30 days.
Why use a template for a small migration
Small sites feel easy to move. That is exactly why teams skip the boring parts. Then a month later, search traffic dips and nobody knows why.
A template forces you to write things down before you touch anything. You record the old URLs, the old page speed, and the old form submissions. After the move, you compare like with like.
It also gives you a story you can share. A client, a manager, or your future self can read it and see what changed. You don't need big numbers. You need honest before and after numbers.
Who this template fits
The template assumes a site with these traits:
- A handful of static pages, such as Home, About, Services, and Contact.
- A blog with posts, categories, tags, and featured images.
- One or two forms that send email or store entries.
- No shop, no membership area, and no heavy custom plugins.
If your site has WooCommerce or a members area, the same steps apply. You will need extra sections for orders, accounts, and payments, though. Treat those as a separate project.
Step 1: Take a baseline before you change anything
Your case study is only as good as your starting numbers. Collect them a week before the move. Save them in one spreadsheet.
Write down the date of each number. Search data changes week to week, so dates keep the comparison fair.
Step 2: Build a full content inventory
An inventory is a list of every piece of content and every URL. It sounds dull. It saves you from broken links later.
WordPress has a built-in export under Tools then Export. It gives you an XML file (called WXR) with posts, pages, categories, and tags. The WordPress export screen docs explain each option.
You can also read content through the WordPress REST API posts endpoint. A REST API is a URL that returns your data as JSON. For example,
/wp-json/wp/v2/posts lists your posts. Many teams find the API easier to script than the XML file.Your inventory sheet should have these columns:
- Old URL
- Content type (page or post)
- Title
- Category and tags
- Featured image file
- New URL
- Status (moved, merged, or dropped)
Fill the "New URL" column now, before you build anything. It becomes your redirect map in Step 6.
Step 3: Freeze content and set up the new site
Pick a freeze date. After that date, editors stop publishing on WordPress until the move is done. Without a freeze, you chase new posts during the migration.
Set up LaraDashboard on staging first. Staging is a private copy of the site where you can test safely. Our guide to staging, tests, and CI for Laravel CMS work covers this setup.
Pick your hosting at the same time. A brochure site has small needs, so don't overbuy. See hosting and deploy paths for LaraDashboard for the common options.
Before you import anything, create the same categories and tags you use today. Matching names keeps your archive pages and internal links simple.
Step 4: Move pages by hand, move posts with a script
Brochure pages are few and often built with a page builder. Page builder markup rarely moves cleanly. Rebuilding five pages by hand is usually faster than cleaning exported shortcodes.
Blog posts are different. You might have 40 or 400 of them. A script that reads the WordPress export and creates posts in the new CMS saves real time.
Here is the order that works on small sites:
- Rebuild the Home, About, Services, and Contact pages in the new editor.
- Upload featured images and inline images to the media library.
- Import posts with title, body, excerpt, date, category, and tags.
- Keep the original publish date on every post.
- Spot check ten posts against the old site.
Watch for shortcodes in post bodies. A shortcode looks like
[gallery ids="1,2,3"]. It only works inside WordPress. Replace each one with plain HTML or a block before launch.Check the current LaraDashboard docs for import options before you write your own script. Features change between releases, and a built-in path beats a custom one.
Step 5: Rebuild forms and test delivery
Forms are the part people forget to test. A brochure site lives on its contact form. If it stops sending, you lose leads quietly.
Recreate each form in the new site. Then send a test entry from a phone and a laptop. Confirm the email arrives, and confirm the entry is stored if you store entries.
Check spam protection too. A form that works but floods your inbox with spam is still a broken form.
Step 6: Map every old URL to a new URL
This step protects your search traffic. Every old URL in your inventory needs a working new URL. If the path changes, add a permanent redirect.
A permanent redirect is called a 301. It tells browsers and search engines that a page has moved for good. Google explains how it treats them in its redirects and Google Search guide.
Common path changes on a WordPress move include:
- Date-based post URLs, such as /2024/05/my-post/, moving to /blog/my-post.
- Category archives moving from /category/news/ to a new path.
- Trailing slashes added or removed.
- Attachment pages that no longer exist.
Redirect old posts to their exact new posts, not to the home page. Sending everything to the home page looks like a broken link to users and search engines.
After launch, crawl the old URL list and confirm each one returns a 301 then a 200. A small script with
curl handles this in a few minutes.Step 7: Launch and watch for 30 days
Launch on a quiet weekday morning. Avoid Fridays, so you have working days to fix problems.
On launch day, submit your new XML sitemap in Search Console. Then use the URL Inspection tool on your top five pages. Keep the old hosting account live for a week in case you need to compare.
Over the next 30 days, check these signals every week:
- Search Console coverage errors and "not found" pages.
- Clicks and impressions on your top landing pages.
- Form entries per week.
- Any 404 errors in your server logs.
A short dip in search clicks after a URL change is common. A steady fall after three or four weeks usually points to missing redirects. Go back to your inventory and check the rows marked "dropped".
The case study write-up template
Once the 30 days pass, write the case study. Keep each section short. Use real numbers from your spreadsheet, and label any estimate as an estimate.
- The site before: page count, post count, plugin count, hosting, and who edited it.
- Why you moved: one or two real reasons, such as plugin updates or editor pain.
- What you moved: pages, posts, images, forms, and what you dropped.
- How you moved it: freeze date, import method, and redirect count.
- What went wrong: at least one problem and how you fixed it.
- Results after 30 days: the baseline table with a new "after" column.
- What you would do differently: one honest lesson.
The "what went wrong" section matters most. Readers trust a case study that admits a broken image or a missed redirect. A story with no problems reads like an advert.
Failure cases to plan for
Most small migrations fail in the same few ways. Plan for them up front.
- Missing images: inline images still point to /wp-content/uploads/. Search post bodies for that path before launch.
- Lost SEO titles: custom titles and meta descriptions from an SEO plugin don't come with a basic export. Pull them into your inventory sheet separately.
- Broken embeds: shortcodes and page builder blocks show as raw text.
- Silent forms: email delivery fails because the new server has no mail setup.
- Editor confusion: the team doesn't know the new admin. Book a 30 minute walkthrough on launch week.
The SEO title problem catches many teams. Plugins like Yoast store those values as post meta. If you skip them, every post falls back to its plain title.
When you should not migrate
Be honest with yourself here. A brochure site that rarely changes and runs well on WordPress may not need a move. Moving costs time, and the visitor may see no difference.
A move makes more sense when you plan to add logins, roles, custom data, or app features. It also makes sense when plugin upkeep eats your editor's week. Our Laravel vs WordPress comparison walks through that choice in more detail.
Where LaraDashboard fits
Disclosure: we build LaraDashboard, so weigh this section with that in mind. LaraDashboard is a Laravel CMS with posts, pages, media, categories, and role-based access in one admin. You can read the overview in what is LaraDashboard.
For a brochure and blog move, the parts that matter are the post editor, the media library, and categories. Those cover most of what a small site needs on day one. You still need a developer for hosting, redirects, and any import script.
One judgment from our own work on this blog: plan redirects before you plan design. Our published slugs come from post titles. When those differ from a planned slug, the redirect map needs the real live slug, not the planned one. Check the live URL after publishing, then update your map.
Ending note
A small migration is mostly careful bookkeeping. Take a baseline, list every URL, freeze content, move posts with a script, and redirect every old path to its new home. Then measure for 30 days and write up what really happened, problems included.
If you want a Laravel base that already handles posts, pages, media, and roles, try LaraDashboard on a staging copy of your site first.
FAQ
How long does it take to migrate a small WordPress site to Laravel?
It depends on post count and how custom the pages are. Rebuilding a few pages and importing a few dozen posts can fit in a short project. Redirect testing and the 30 day watch add time after launch.
Will I lose SEO rankings when I migrate from WordPress?
You can keep most of them if every old URL redirects to a matching new page. Keep titles, meta descriptions, and content the same at first. Change one thing at a time after the move.
How do I export posts from WordPress?
Use Tools then Export to download an XML file. You can also read posts as JSON from the REST API at
/wp-json/wp/v2/posts.Do I need 301 redirects after changing URLs?
Yes, for every URL that changes path. A 301 tells search engines the move is permanent. Point each old URL to its exact new page.
What should a website migration case study include?
Include the site before, the reason for moving, the method, what went wrong, and before and after numbers. Label estimates clearly. One honest lesson makes it far more useful.
