Content, Workflows, and Complex Migrations: A Media Publisher’s Guide to Getting It Right

The organizations that get the most out of a platform migration understand that it is an opportunity to rethink how their publishing operation actually works. They use it to free content from the constraints of a legacy system, to rebuild editorial workflows around how their teams actually work, and to lay a foundation capable of scaling with them. Organizations that struggle often focus on the technical destination without clearly defining what they need the migration to accomplish.

For media publishers, where content volume and editorial complexity often magnify migration challenges, success is determined long before the migration begins.

We’ve worked with media organizations through migrations of varying scale and complexity, from high-volume editorial sites to major rebrands involving hundreds of thousands of pieces of content, and the patterns are consistent. Here’s what we’ve learned.

Getting More From Your Content

Most media organizations have built extensive archives inside a content management system (CMS) shaped by years of platform-specific decisions. Taxonomies that don’t translate cleanly to other systems. Custom fields that only make sense within that platform’s schema. URL structures that were never designed with SEO longevity in mind. Content relationships that exist as platform-specific associations rather than portable data.

The practical effect is that content technically exists but isn’t being used to its fullest potential. Syndication is inefficient. Restructuring is complex. Migrating it means first untangling it from the system that was supposed to be serving it.

It’s a pattern we’ve encountered across platforms and content types. Hemmings, the world’s largest collector car marketplace, came to us with over 20,000 articles on RebelMouse. Its rigid information matrix couldn’t support nested taxonomies, and its proprietary data fields had no native home in a modern CMS. Years of authoritative, high-value editorial content, structured in ways that limited how the team could use it.

Related: From Inefficiency to Scalability: Migrating Hemmings Stories to WordPress

We mapped their proprietary data fields to custom fields and WordPress taxonomies, built a custom migration testing tool to ensure content integrity, and preserved URL structures throughout. The new architecture gave the Hemmings team more flexibility and control than they’d had before. It also introduced enhanced analytics through Parse.ly and a design system that let editors create rich content layouts without depending on development resources.

Before any technical decisions get made, it helps to step back and ask: what do you actually have, how is it structured, and what does it need to become?

Editorial Workflow as a Design Priority

Getting your content to a new platform is one thing. Making sure your team can do their best work in the new environment is another, and it deserves the same level of planning.

Editorial workflow is often treated as something to sort out after launch. It’s seen as a post-migration configuration task rather than a design priority. In practice, however, the editorial experience is what your team interacts with every day, and it should be part of the plan from the start.

A genuinely improved editorial workflow delivers a few things consistently: content creation that doesn’t require workarounds, publishing processes that match how editors actually think, governance tools that give managers visibility without creating bottlenecks, and a platform built to scale as team size and content volume grow.

We’ve built editorial systems for Atlassian across two generations of their blog platform. The first, the Work Life blog, established the foundation: custom Gutenberg blocks that let a team of around 60 contributors assemble visually rich content without needing development support for every new layout. As Atlassian’s Natalie Mendes put it: “When sharing our ideas or designs, [Reaktiv] never said, ‘That’s not possible.’ Instead, they always asked questions to understand our intentions, advised us on potential risk, talked through possible options, and shared creative solutions.“

Related: Using bespoke Gutenberg blocks to migrate custom meta fields into the block editor

Building on the Foundation

The more recent Inside Atlassian redesign built on that foundation and pushed it further. Atlassian’s audience spans developers, team leads, and executives across the world. It’s an audience that arrives with different needs and different ways of looking for content. A fragmented discovery experience means the right content doesn’t reach the right reader, regardless of how good the writing is. To address this, we developed custom post types and an intuitive information architecture system, along with a reimagined search and filtering interface that unifies post types, taxonomies, and freeform search terms into a single, cohesive experience. Together, these systems make it as easy to find the right piece of content as it is to publish one.

That’s the standard worth holding a migration to: not just moving the editorial team to a new system, but leaving them with something that actively improves how they work.

Making a Complex Migration Seamless

When large media migrations run into obstacles, it’s rarely for a single reason. There’s scale, proprietary source systems, and limited export options. There’s also the need to keep live traffic uninterrupted, maintain advertising and analytics integrations, coordinate across distributed stakeholder teams, and work within fixed launch dates. Any one of these factors adds friction. In combination, they can introduce significant complexity.

MS NOW (formerly MSNBC) brought all of it. Rebranding, separating from NBC, and rebuilding their digital presence simultaneously, they needed to migrate approximately 350,000 videos, articles, and other content types off a deeply custom proprietary CMS, with only API access to the source system. No direct database exports. No file transfers. Just an API and a fixed deadline.

We built an automated migration pipeline that pulled every piece of content via API, transformed it, and loaded it into the new platform. A live sync ensured the team never had to double-publish during the transition. Coordinating across 20 teams, we managed over 150 meetings and more than a dozen integrations, APIs, and systems — all while their rebrand was still evolving around us. We shipped their custom theme quickly, incorporating editorial requirements and design direction in parallel, without slipping the timeline or cutting a single feature. Pre-launch, we stress-tested the platform against anticipated traffic volumes, which meant that when the moment arrived, there was nothing unexpected. The switch flipped, and everything just worked.

What made that possible wasn’t any single technical decision. It was the combination of automated systems, rigorous preparation, and a coordination discipline that kept every workstream moving in the same direction at the same time.

Principles That Hold Across Complex Migrations

A few principles that have held up across migrations of this kind:

• Start with content architecture. Success is built on understanding how your content needs to be structured, used, and reused. The right architecture decision at the start prevents a wide range of problems downstream.
• Build the migration as a repeatable process. Automated pipelines with built-in validation and testing are more reliable than manual processes at any meaningful scale, and they create an auditable record of what moved and how.
• Plan for the live environment from day one. For news publishers, there’s no acceptable downtime window. Live sync, phased transition planning, and solid rollback preparation need to be part of the design, not an afterthought.
• Keep editorial and engineering in the same room. The smoothest migrations are the ones where editors and engineers are making decisions together from the beginning, not handing requirements back and forth.

What a Migration Can Actually Unlock

The migrations worth doing unlock new ways for teams to work and deliver value.

When Baylor Scott & White Health Foundation came to us, they were sitting on a wealth of storytelling potential. Powerful accounts of patients, caregivers, and community impact existed throughout the organization. But they lived in static PDF newsletters, making them difficult to share, inaccessible through modern distribution channels, and disconnected from any direct path to donor action.

Related: Transforming Baylor Scott & White Health Foundation’s Digital Presence

At the same time, those stories were fragmented across a network of foundations that had each developed their own digital presence independently. The result was duplicated effort, inconsistent experiences, and limited opportunities to share content across the organization.

The redesign addressed both challenges. We created a shared information architecture that gave each foundation room to express its own identity while creating a more consistent experience across the network. A digital-first newsletter replaced the PDF archive. Using custom post types and reusable block patterns, we made content shareable, updatable, and easier to consume across devices. It also brought their stories into search. Content that had lived in PDF archives, invisible to search engines, became indexed, discoverable, and shareable for the first time. To extend those benefits among the foundations, we introduced a content sharing system on WordPress multisite. It lets larger, better-resourced editorial teams distribute high-quality stories to smaller foundations across the network, increasing the organization’s storytelling capacity without proportionally increasing the burden on smaller teams.

Tools Built for the Organization

We then developed tools that matched how the foundations actually worked: a timeline feature for long-form narrative stories, a custom CTA system that connected content directly to giving opportunities, and personalized link sharing that let development officers add context when sharing stories with donors. What began as a modernization effort became a platform that gave the organization genuinely new capabilities for advancing its mission.

That’s the possibility a well-executed migration opens up: not just a better version of what you had, but tools and infrastructure that give your content the reach it’s capable of, while freeing your team to focus on the stories worth telling.

Questions Worth Asking Before You Migrate

If a migration is on your horizon, here are a few questions worth considering:

What the Best Migrations Have in Common

Across the projects we’ve worked on, one thing has remained consistently true: the decisions that shape a migration’s outcome are made early. Content strategy, information architecture, editorial workflows, and implementation planning establish the foundation the rest of the migration is built on. By the time development begins, many of the conditions for a smooth migration are already in place.

The organizations that come out ahead treat the migration as an editorial project as much as a technical one. They bring the people who will use the platform into the conversation before the build begins. They think about what their content needs to do, and they plan for the publishing operation they want to build.

When the technical work and the editorial vision move together, the result is a platform that supports the way teams actually work, instead of one they’ve learned to work around.

For media organizations on legacy platforms, a well-executed migration is a rare opportunity to work better, publish smarter, and build a platform that grows with you.