The client

One of the largest media networks in North America runs local and regional news titles, their websites, and magazines across hundreds of communities. It grew title by title, each newspaper arriving with its website built on its own terms. The network wanted to run them via one platform it could maintain, secure, and improve in a single place, with a fix reaching every title at once.

One part of the network sat furthest from that goal: 32 independent WordPress sites on another host, sharing an owner and little else. Maintenance and deployments happened 32 times over, and the codebases had drifted so far that a fix for one rarely carried to another.

The unification ran on WordPress VIP, with rtCamp delivering the migration as a WordPress VIP partner. rtCamp scoped it as a lift-and-shift onto one platform that met WordPress VIP guidelines, on three conditions: lose no data, break nothing readers relied on, and keep publishing throughout.

At a glance

ChallengeSolutionOutcome32 sites on outdated, drifted codebasesAudited 100+ plugins against VIP guidelines, retired 10+, standardized the restOne vetted VIP-compliant baseline across all 32Single-site code broke nav, archives, scripts, and images on multisiteRefactored themes, swapped custom SQL for native multisite functions, added must-use pluginsReader-facing features work on every subsite1.6TB of media, millions of files5GB batches with retry and checkpointsFull migration in 10 to 12 days, no data loss32 overlapping user basesScripted export/import plus a custom user-mapping stepUnified users, authorship intactNewsrooms could not pause publishing8 phased launches, 12-hour freezes, table-selective deltasNo downtime, no lost changes

Auditing 32 sites that had drifted apart

Running 32 titles as a multisite meant the codebases had to agree first. They fell into two style families, each on a parent theme, its child themes, and its own plugin stack, so sites in a family looked alike on the surface. Underneath, they diverged:

• Both families ran outdated WordPress versions.
• Shared plugins ran at different versions, often with no two sites matching.
• A subscription and payment plugin existed as a separate variant on all 32 sites.
• Custom plugins had no release history, so each one’s version only became clear once an engineer read the code.

The VIP compatibility filter

The team cataloged more than 100 plugins and checked each against WordPress VIP guidelines. More than 10 plugins were redundant. Some were importer and exporter tools; others were security plugins that duplicate what VIP already runs. These were offboarded first.

Where the same plugin ran at different versions across sites, the team standardized on the latest and ran QA on every site that had been on an older one. That gave the network one vetted baseline up front, instead of version conflicts surfacing site by site through later phases. Without that shared baseline, no single fix could ever reach all 32 titles at once; the whole reason the network wanted one platform.

The themes posed a hurdle because both families assumed a single site throughout, hardcoding values and queries that only ever held on a standalone WordPress install, and both still ran on outdated WordPress. No version bump would carry that onto multisite. The themes needed a full refactor due to the single site , the heaviest engineering of the migration, which the audit scoped, and the team carried out later as part of the build.

With the plugin baseline set and the theme work mapped, the next action was moving the 32 sites into the multisite.

Bringing each site in

Each of the network’s sites had to arrive whole. rtCamp migrated them with a scripted export-and-import pipeline to move them: it pulled a standalone site, its content, users, and roles intact, and loaded it into the multisite as a subsite under a new blog ID. 

To ensure the migration tooling remained centralized and the process consistent, rtCamp distributed the 32 sites among its development team based on traffic volume and technical complexity. This end-to-end ownership model allowed individual developers to manage their assigned subsets without fragmenting the overall project.

Optimizing workflows with a shared database handoff

All 32 sites had to live inside one shared database, so the team could not build them independently. Each site brought its pages and user accounts into that one database, so the sites had to be added one at a time, each on top of the work the previous developer had just finished. 

Two weeks in, that sequence turned into a bottleneck: each developer pushed the database up to VIP, and the next waited to pull it back down before starting. At this scale, that wait cost hours.

The developers cut out the round trip and passed the database file straight to one another. One migrated a site into the shared database, handed the file to the next, who added theirs to the same structure, while VIP processed those uploads in parallel. The team improvised the handoff under deadline pressure, kept it for the rest of the project, and cut hours of idle time.

Reconciling users without misattributing authors

The migration pipeline carried each site’s users and roles in, but overlapping identities across 32 sites still needed reconciling. 

The team handled this in code such that when the same email appeared on several sites with different roles, a custom mapping step weighed role hierarchy and site permissions to pick the canonical record. Then remapped post authorship so each article stayed tied to the right person. 

This carried the newsroom’s authorship history onto the new platform intact, so every story still credited the author who wrote it.

Fixing single-site code on multisite

Each site arrived with years of custom code, all of it written for a single site. On multisite, some of it failed in staging, and some held until production.

Themes carried the heaviest refactor

The original developers had hardcoded values throughout:

• Direct URLs wherehome_url() or get_site_url() belonged.
• Queries that assumed the default wp_ table prefix.
• Image functions that assumed a single site.

Each parent theme fed a set of child themes, so a fix to a parent flowed down to all of them, and so did any regression. That made the parent themes the most delicate part of the job. 

The team moved the theme code onto dynamic WordPress functions, corrected the prefix assumptions, and rebuilt the image handling for multisite.

At the frontend, outdated theme JavaScript broke subscription, payment, and sign-in flows across the network. rtCamp shipped a custom plugin that patched the affected scripts to current versions and restored the functionality.

Navigation and archives that queried the wrong tables

A staging crawl of one subsite turned up missing “Next Post” and “Previous Post” links. They worked on the primary domain but acted as if no adjacent posts existed on the subsite. The cause was custom SQL that queried wp_posts directly. In multisite, each subsite gets its own prefixed tables, like wp_2_posts and wp_2_term_relationships, so the old queries hit the wrong tables and found nothing. 

The same cause broke category archives. That code read categories from each site’s old permalink URLs, and it stopped matching once the URLs moved to the multisite subdirectory format.

The team fixed both with WordPress’s native multisite functions, and navigation and archives worked again on each subsite.

Image cropping that only broke in production

One break survived staging and showed up in production. A custom crop-thumbnails plugin saved each crop as its image file, the way a standard WordPress host stores intermediate image sizes. VIP keeps only the original upload and generates every other size, crops included, on the fly when a reader requests an image.

Therefore, images rendered at full size and broke page layouts. rtCamp wrote a must-use plugin that routed the crop tool’s output through VIP’s image transformation, so the images would render as intended.

By launch, readers on all 32 titles saw the sites they were used to.

Migrating 1.6TB of media without data loss

The media moved in parallel with the code work, and it was the bigger job. Most of the 1.6TB lived in the network’s AWS S3 buckets rather than the hosting backups, and the largest single title held more than 300GB on its own. A single bulk transfer would not work because a one percent failure rate would have left thousands of files missing, with no clean way to tell which failed.

Batch sizing and retry

The team split the media into 5GB archives and built the pipeline on one assumption: something would fail.

• 5GB batches, small enough to re-run a failure in minutes. A failed 50GB import would cost hours and block everything behind it.
• Retry logic from day one — days of unattended transfer always throw the occasional dropped connection, so the pipeline caught and retried them itself.
• Validation after each batch, so a batch counted only once its files were confirmed intact.
• Checkpoints, so a crash could resume instead of restart.

Midway through, the design proved itself: the processing server went down. Because the work was already split into validated, checkpointed batches, the crash cost one batch, not the migration. The team stood up a fresh server and the pipeline resumed where it left off.

The migration ran 10 to 12 days end to end, crash included, and the network’s media library came across whole.

Launching in phases without stopping the presses

Across 32 active sites, the newsrooms could not stop publishing for weeks, so the launch had to fit around them. The network set the order; grouping the 32 titles into 8 launch batches by its own editorial priorities, and rtCamp layered in the technical factors, pulling the largest, highest-traffic titles into their windows. 

Each launch ran on a few rules:

• A 12-hour content freeze per batch, agreed with editorial teams in advance.
• A one-day buffer between batches, to clear any issue before the next went live.
• A rollback plan for every phase.

A call with the client teams and VIP’s teams each launch day kept everyone current on what was going live and what to watch. The network revised the scope twice mid-project, from 26 sites to 32, and the pipeline absorbed the additions without a redesign.

Strategic Delta migration that kept publishing on

The network maintained active publishing and configuration updates across both legacy systems and the new VIP production environment during the launch. A typical delta migration involves a full re-import of the source database, which overrides any recent changes on the target system. This process inadvertently deleted theme and configuration adjustments the network had implemented directly in production during one cycle.

Rather than a rollback, the team ran a corrective import: it pulled in only the tables for sites still waiting to launch, preserved the production state of sites already live, and reverted any overwritten tables. Every delta after that used table-selective imports because a broad overwrite stays safe only until the first batch goes live. 

This ensured the editorial teams of the network could keep publishing continuously throughout the phased transition.

Dramatically reduced TCO + better, faster stack

The network set out to run 32 titles as one platform, and that is what it now does. Maintenance, security patching, and deployments that once ran 32 times now run once, and a fix built once reaches every title in one deploy.

That shift rests on a single vetted, VIP-compliant codebase in place of 32 divergent ones, after rtCamp retired 10+ redundant plugins and standardized the rest against VIP guidelines. Two more outcomes followed from it:

• One codebase to secure and govern: a single standard narrows the security and maintenance surface and gives the network one place to govern every title.
• No interruption to publishing: the phased launch, coordinated with the network’s editors, kept the newsrooms publishing and subscriber features working, and the media migration finished with no data loss across 1.6TB.

The network no longer pays for 32 independent deployments, 32 rounds of security patches, or the same fix built 32 times.

Related case studies

• 

  Scaling multi-brand publishing: Private Media’s WordPress VIP multisite transformation

  Solution

  WordPress Development

  Industry

  Publication and Media

• 

  Multisite VIP Migration and Codebase Audit for KHM Travel Group

  Solution

  Hosting Migration

  Industry

  Tourism and Hospitality