Migrating WordPress off Bedrock and other custom frameworks: when re-standardization is the win.

Bedrock and similar custom frameworks (Sage, Roots, certain agency-specific scaffolds) emerged a decade ago to bring modern development practices into WordPress: environment-aware config, Composer-managed dependencies, separate web roots. They were defensible at the time, and on the right team they still are. On most teams, in 2026, the framework is creating more friction than it removes — every hosting provider has to be specifically compatible with the layout, every plugin update has to be tested against the abstraction, and the people who originally chose Bedrock have usually moved on. The realistic answer for most sites is re-standardization back to a normal WordPress build. Here's when that's the right call and what the migration actually involves.

Custom WordPress frameworks were a reasonable answer to a real problem. Vanilla WordPress, circa 2015, didn’t have built-in environment management, didn’t compose well with Composer, didn’t separate config from code cleanly. Teams building serious WordPress applications hit those limits and reached for alternative scaffolds. Bedrock by Roots was the most-adopted; Sage was the parallel theme-side scaffold; smaller agencies built their own. The frameworks brought 12-factor-ish thinking to WordPress: environment-based config, dependency lockfiles, a separate web root from the application code, the basic disciplines other web stacks had taken for granted.

Then WordPress itself caught up partially, hosting providers standardized around expected layouts, and the framework choice that was once an advantage became friction. The Bedrock-shaped site:

• Doesn’t deploy to most managed WordPress hosts without configuration overrides.
• Can’t use most one-click-install plugins without manual Composer additions.
• Requires the team to understand both WordPress conventions AND Bedrock’s overlay of those conventions.
• Locks the site to whoever still knows the framework. When that person leaves, the next developer hits a wall of “why is this structured this way.”

For some teams (large engineering orgs with strong WordPress + Composer + ops culture), the framework still earns its keep. For most teams, and most sites, the framework is now a tax on every change, and the right call is to re-standardize.

What re-standardization actually means.

Re-standardization converts the site back to a normal WordPress layout:

• wp-content/themes/ and wp-content/plugins/ in their standard locations.
• wp-config.php in the project root, using straightforward define() statements (with secrets managed by the host’s environment-variable injection if needed).
• Plugins installed via the WordPress admin or WP-CLI, not via Composer.
• No separate “app” directory, no web/ subdirectory, no dotenv files. Just the layout every WordPress host expects.

The site looks and behaves identically from the outside. The internal change is that the codebase now fits the conventions of every standard hosting provider, every standard plugin installer, every developer who’s worked on WordPress.

What you stop having to do.

The friction that goes away when the framework comes out:

• Plugin installation becomes one-click again. Adding a plugin from the WordPress repo doesn’t require editing composer.json and running a dependency update.
• Hosting moves become trivial. Every WordPress host on the market deploys a standard layout. The Bedrock-shaped site is a special case for every provider’s onboarding.
• The dev environment is the same as everyone else’s. A new developer can clone the repo, run wp serve or fire up Local, and the site works. No setup ritual specific to the framework.
• Plugin updates stop breaking the abstraction. When a plugin author adds a new initialization pattern, vanilla WordPress just works; Bedrock often needs an adjustment layer.
• Documentation matches what’s online. Every WordPress tutorial, every Stack Overflow answer, every developer doc assumes the standard layout. The framework site lives in a parallel documentation universe.

For a site that’s not actively benefiting from the framework’s specific features, all of this friction is pure operational tax with no offsetting value.

What you do give up.

Honest accounting of what re-standardization costs:

• Composer-managed plugin versions. Bedrock’s Composer setup pins plugin versions in a lockfile. Standard WordPress relies on the wp-content directory state. The reproducibility is different. For most sites this doesn’t matter; for sites with strict reproducibility requirements (rare on WordPress), it does.
• Environment-isolated config. Bedrock encourages a .env file with environment-specific values. Standard WordPress puts config in wp-config.php with define() statements that often need conditional logic for env-specific values. Most modern hosts (Pressable, WP Engine, Kinsta, others) inject environment variables that achieve the same separation; the standard-WP equivalent is straightforward but uses a different pattern.
• The separation of secrets from code. Bedrock’s .env pattern keeps secrets out of the repo by default. Standard WordPress requires the team to set up the same discipline (typically via environment variables, sometimes via host-managed secrets) without the framework forcing it.

These are all addressable. The right hosting provider plus modest dev-process discipline gives you everything the framework was providing, without the framework.

What the migration actually involves.

The realistic project arc for a typical Bedrock-to-standard migration:

1. Inventory. What’s in composer.json? Which dependencies are real WordPress plugins (will become wp-content/plugins) vs PHP libraries the theme uses (will become composer dependencies of the theme, if needed)?
2. Build the standard scaffold. A fresh WordPress install at the target host, target version of PHP and MySQL.
3. Migrate the theme. Sage-based themes need conversion to standard WordPress theme structure (most of the SCSS/JS/templates transfer; the framework-specific bootstrap goes away).
4. Migrate plugins. Each Composer-installed plugin gets installed normally; configurations carry over from the database.
5. Migrate content and uploads. Standard database export + uploads directory copy.
6. Update wp-config.php. Standard structure with environment-aware values where the host supports them.
7. Edge-level redirect mapping. Because Bedrock changes the default asset paths (e.g., /app/uploads/), stripping the framework requires mapping the old paths back to standard WordPress routes. Pushing 100+ wildcard and hardcoded redirects to the edge via Cloudflare ensures you don’t hemorrhage SEO equity or break cached assets during the move.
8. DNS cutover. Once the standard install and redirects are verified, swap DNS.

For a moderately complex site (one theme, twenty-ish plugins), this is typically two to four weeks of work depending on how deeply the theme was coupled to the framework’s specific bootstrap.

When to keep the framework.

The migration isn’t always the right call. Keep Bedrock (or whichever framework you’re on) when:

• The engineering team is genuinely fluent in it and uses its features actively.
• The site has complex multi-environment workflows that the framework’s conventions support cleanly (staging, QA, demo, prod with distinct configs).
• The hosting provider is set up specifically for the framework and the host’s support understands it.
• The team has the bandwidth to maintain the framework’s specific updates alongside WordPress’s.

For everyone else — sites that inherited the framework from a previous engagement, sites where the original framework advocate has moved on, sites where every plugin update requires reading framework-specific docs — the standardization is a one-time investment that pays back continuously.

See legacy modernization for what this looks like as part of a broader practice.