Refactor or Rebuild a Legacy WordPress Site? How to Decide

Refactor your legacy WordPress site when the foundation is sound and the problems are specific: a few abandoned plugins, slow templates, untested custom code. Rebuild when the foundation itself is the problem: an abandoned theme or page builder, code nobody can safely change, or a content structure that no longer fits the business. Most sites fall in between, and the honest answer often turns out to be “refactor most of it, rebuild one part.”

This guide explains how to tell the difference, using measurements instead of gut feeling.

What “refactor” and “rebuild” actually mean

The two words get used loosely, so here is how we use them.

Refactoring means improving the existing site without changing what it does for visitors. You replace an abandoned plugin with a maintained one, move theme edits into a child theme, rewrite a slow query, or add tests to custom code. The site stays live the whole time, and changes ship in small pieces.

Rebuilding means building a new site, usually on a fresh theme or block-based setup, then moving the content across and switching over at launch. The old site keeps running until the new one is ready.

There is also a middle path: a partial rebuild. You keep the WordPress install, content and most plugins, but rebuild one layer, most often the theme. This is common when a site is stuck on an old page builder but the content and back-end logic are fine.

Start by measuring, not by guessing

“The site feels old” can lead to an expensive rebuild that was not needed. “The site is fine” can lead to years of patching something that should have been replaced. Neither feeling is a good basis for the decision.

We start with a technical debt measurement across six areas: plugins and themes, server versions, custom code, speed, accessibility and security. Our guide on how to measure WordPress technical debt explains the scoring. The technical debt audit checklist lists what to check in each area.

The scores tell you where the debt is. That matters more than the total. Debt in plugins and server versions is usually easy to refactor. Debt in the theme’s core structure often is not.

Signs refactoring is the right call

Refactoring usually wins when most of these are true:

• The theme is maintained, or it is a custom theme built in a reasonably clean way.
• The content model fits. Your post types, categories and fields still match how the business works.
• Problems are local. You can point to specific plugins, templates or features that cause trouble.
• Custom code is understandable. Someone can read it and explain what it does, even if it has no tests yet.
• The design still works for the brand, perhaps with some updates.
• The site has a lot of history: years of content, integrations, SEO rankings and user data that would be risky to move.

In that situation, a rebuild throws away working parts along with broken ones. Refactoring keeps the value and removes the debt piece by piece.

Signs a rebuild is worth considering

A rebuild starts to make sense when the problems are structural:

• The theme or page builder is abandoned, or so outdated that updating it breaks the layout.
• Content is locked inside a builder’s shortcodes and cannot be moved or edited cleanly.
• Custom code is unreadable or undocumented, and every change causes surprises somewhere else.
• Parent themes or third-party plugins were edited directly, so nothing can be updated without losing changes.
• The content model no longer fits. The business now sells different things, in different ways, and the site structure fights you.
• Accessibility and speed problems are built into the templates, not added on top, so fixing them means rewriting the templates anyway.

If only one of these is true, a partial rebuild may be enough. If several are true, price a full rebuild alongside a refactor and compare.

A simple decision table

This table is not a formula, but it helps structure the conversation.

Questions to answer before you decide

Before you get quotes, answer these with your team. They often settle the question on their own:

• What has to change in the next two years? New products, new markets or a new brand push toward a rebuild. “Keep doing what we do, but faster and safer” points toward refactoring.
• What breaks most often today? If the answer is one plugin or one integration, fix that first and see how much of the pain goes away.
• Who edits the site, and how? If editors avoid certain pages because the builder is painful, that is a real cost, even if it never shows up in an error log.
• What would hurt most if it stopped working? Your forms, checkout or member area should drive the plan, not the home page design.
• How much risk can the business accept this year? A gradual refactor spreads risk over many small releases. A rebuild concentrates it into one launch.

Compare the full cost, not the first invoice

A rebuild often looks expensive up front and cheap afterward. A refactor often looks cheap up front and stays moderate. To compare fairly, estimate the cost over two or three years:

• Upfront work: design, development, content migration, testing.
• Running cost: how many hours each update, change or new feature will take on each version of the site.
• Risk cost: the chance of an outage, a security incident or lost rankings, and what that would cost the business.
• Opportunity cost: what your team cannot do while the project is running.

Be honest about the risk side. A rebuild has its own risks: missed features, broken integrations and SEO losses if URLs change without redirects. Our WordPress migration SEO checklist covers how to protect rankings during a rebuild or move.

How to refactor safely

If you choose to refactor, the approach matters as much as the decision.

1. Put the code in version control. If there is no Git repository, create one before changing anything.
2. Set up a staging site that matches production, including the PHP version.
3. Add tests for the key tasks first. End-to-end tests that fill in your forms, place an order or log in will catch regressions while you work. Our article on automated testing with Playwright and PHPUnit shows how.
4. Work in small pieces. Replace one plugin, rewrite one template, upgrade one component at a time. Ship each change on its own.
5. Measure again. Re-score the six areas after each phase so you can see the debt going down.

Database cleanup is often a quick early win in a refactor. See our guide to cleaning up a bloated WordPress database.

How to rebuild without losing what works

If you choose to rebuild, protect the value the old site has built up:

1. Inventory everything the current site does. Forms, integrations, scheduled emails, user roles, redirects, tracking. Hidden features are the most common reason rebuilds go over budget.
2. Crawl the current site and save every URL, title and meta description.
3. Plan the content migration early. Content trapped in page builder shortcodes may need scripts or manual work.
4. Keep URLs where possible and map every changed URL to a 301 redirect.
5. Build accessibility in from the start. Test against WCAG 2.2 AA during development, not after launch.
6. Launch with tests and monitoring in place, so problems show up in hours, not weeks.

The answer is often “both”

In our experience, the most common result is a mix. Clean up plugins, upgrade PHP and add tests now, because those pay off right away. Then rebuild the theme later, on a stable base, when the budget allows. This spreads the cost, lowers the risk and means the rebuild starts from a site that is already healthier.

Get help with the decision

If you are stuck between the two options, our technical debt audit gives you scored evidence and a recommendation for your specific site. If you decide to rebuild or move, we also handle WordPress migrations of any size. Contact us and tell us what the site does and what is holding it back.