The Great Divide: Making a WordPress Platform Portable

The hidden cost of leaving

Imagine investing thousands of dollars in a website, only to discover that leaving your agency means rebuilding it somewhere else.

That was a limitation of the WordPress platform I worked on at PracticeMadePerfect (PMP).

The agency managed multiple client websites through a shared WordPress multisite network. Its proprietary theme and plugin made development and maintenance efficient, but they also created a dependency.

Clients owned their content. They didn't own the software that made their websites work.

Ending the relationship could mean losing the functional website they'd invested in.

I saw an opportunity to rethink that arrangement.

What if clients could leave with their working websites while the agency retained ownership of its proprietary software?

That question became the foundation of an architectural transformation I called The Great Divide.

Client website connected to an agency-controlled platform.

Three websites changed the equation

The problem became concrete when a new client arrived with three websites that needed redesigning.

The project required a dedicated WordPress multisite network, but it also needed to reuse the agency's existing theme and plugin.

There was a catch.

Our software lived inside a monorepo alongside the existing network's configuration and deployment infrastructure.

We could duplicate the code, but that would create two implementations to maintain. Every improvement, bug fix, or feature would eventually need to be synchronized.

The more networks we added, the more complicated that relationship would become.

We needed to share the software without forcing every network to share the same development and deployment lifecycle.

What started as a three-website project became an opportunity to redesign how the agency delivered software.

Breaking apart to work together

I proposed splitting the platform into four repositories.

Two would manage the WordPress networks. The other two would contain the shared theme and plugin.

Instead of embedding the software directly inside each network, both networks would consume independently versioned packages through Composer.

Before: One monorepo containing the agency network and shared software.

After: Two independent WordPress networks consuming a shared theme and plugin through Composer.

This introduced three important capabilities:

• One source of truth: Shared functionality could evolve without duplicating code.
• Independent deployments: Networks could adopt software updates on their own schedules.
• Client portability: A dedicated network could be handed over without exposing the agency's broader infrastructure.

It was a cleaner architecture on paper.

Making it work without breaking existing websites was another story.

The moment of truth

The theme and plugin depended on build processes, installation paths, and runtime dependencies inherited from the monorepo.

I extracted them into standalone packages and established a release workflow using GitHub Actions, compiled assets, and version tags.

Each network could now install a complete, versioned package without rebuilding the software during deployment.

Source code → Build → Versioned package → Composer → WordPress networks

But the migration carried a serious risk.

Our existing deployment process used rsync --delete, meaning an incorrectly placed package could remove a working theme or plugin from production.

I treated the transition as a controlled migration rather than a routine refactor.

I preserved package histories, established a validated baseline, temporarily disabled production deployment triggers, and introduced checks for installation paths, compiled assets, and runtime dependencies.

Dry runs exposed potentially destructive changes before they reached production.

Validation compared a 198-file theme build tree, confirmed byte-identical CSS and JSON output, and checked critical website functionality across development and staging.

Only after those safeguards were validated did I re-enable production deployments.

The platform could now evolve independently without requiring existing client websites to change alongside it.

One foundation, different paths

The benefit became clear during subsequent development.

The new client needed hierarchical locations to support its website structure.

With the new architecture, I could develop that functionality in the shared plugin, publish a new version, and adopt it in the client's network while the agency's existing network remained on its validated release.

Both networks still shared the same software.

They simply didn't have to move at the same pace.

Two WordPress networks consuming different versions of the same shared packages.

Later enhancements introduced reusable content components, compatibility checks, and per-site feature controls, extending the shared platform without duplicating implementations.

The architecture also addressed the original ownership problem.

Clients could retain their working websites and installed software packages when their agency relationship ended. Future proprietary updates remained under the agency's control.

Hosting, maintenance, and external integrations still required separate arrangements, but the technical foundation for a practical handover was now in place.

Client continuity and proprietary software ownership no longer had to be mutually exclusive.

The cost of independence

Moving from one repository to four introduced new responsibilities: package releases, compatibility management, dependency updates, and coordination between environments.

But that complexity gave us something more valuable: control.

Shared software could evolve centrally, individual networks could adopt changes independently, and clients had a practical path to retaining the websites they'd invested in.

The biggest lesson wasn't that a monorepo needed to become multiple repositories.

It was that technical architecture can influence business relationships.

By considering ownership, portability, and continuity as engineering requirements, I helped turn a tightly connected platform into a more flexible foundation for both the agency and its clients.