The Monolithic CMS Growth Trap
Whether you're running WordPress, Craft CMS, or Webflow, the story is remarkably similar. These platforms make perfect sense early on—they're accessible, fast to deploy, and don't require significant development investment. But as your content scales and your team grows, the cracks start to show. At Monogram, we've migrated dozens of companies from each of these platforms to headless solutions, and while the technical details differ, the core issue remains the same. What worked for 50 pages starts to fall apart when you scale to hundreds or even thousands of pages.
Why Companies Start with WordPress. And When It Breaks Down
WordPress is the most common starting point we see, and it makes perfect sense when you're just starting out. Before you have revenue to invest in custom development, it's accessible and cost-effective. You can get a site up quickly and start moving. But here's what we see at Monogram time and time again: as companies grow, WordPress begins to fail them. Without an engineer setting up your data structure from the beginning, you develop holes in your content model, and those holes only grow larger over time. Scalability becomes the real problem.
When companies come to us to migrate to headless CMS platforms like Sanity, Contentful, DatoCMS, Payload CMS, or Prismic, they're not just switching tools, they're gaining back their scalability. They're investing in a foundation that supports growth rather than fighting against their CMS. That shift from monolithic to composable architecture is what allows businesses to evolve without constantly rebuilding from scratch.
The Reality of Content Migration
The Biggest Misconception
Here's what almost every client believes when they first approach us: data is just data, so migration should be straightforward. They assume moving content, especially free-form content, will be simple given how dynamic it is. The reality? Most CMS platforms have bespoke data structures, which means conversion is never 1-to-1. There will be trade-offs.
The key to successful migration isn't avoiding those trade-offs, it's knowing how to navigate them strategically. That's where our experience across dozens of migrations becomes invaluable. We've seen the patterns, encountered the edge cases, and developed solutions that make these transitions smooth even when the underlying data is messy.
Our Migration Methodology
Step 1: Diagram and Optimize
We start by mapping out the current content structure and designing what the new structure should be. This isn't just direct translation, we're often making optimizations, fixing data modeling mistakes that naturally occur when structure isn't your primary expertise. Common issues we address include repeated data structures, compression levels that are either too tight or too loose, and simple data modeling mistakes that made sense at the time but don't scale well. This diagramming phase is crucial because it forces conversations about what the content model should be, not just what it currently is.
This discovery phase looks different depending on the source platform. For Craft sites, we're often documenting Matrix block structures that exist nowhere else—reverse-engineering the content model from the database itself. For Webflow, we're consolidating collections, identifying which variations can be unified and which truly need to remain distinct. But regardless of platform, we're always asking: what should this content structure be in a system designed for scale?
Step 2: Extract Source Data
We download all content from the source platform, capturing everything needed for transformation. This seems straightforward, but it's where we start to uncover the real complexity, custom fields, plugin-generated content, and media associations that aren't always cleanly structured in the database.
Step 3: Transform and Process
This is where custom development happens. I typically write conversion scripts in TypeScript working with JSON for quick turnaround. The benefit is twofold: speed and integration. If any part needs to integrate with the final site, it's already in the same language, which eliminates translation layers and potential bugs. Each migration requires custom scripts because every site has accumulated its own unique combination of plugins, custom fields, and content patterns over the years.
Step 4: Upload with Repeatability
We set up our scripts to run repeatedly without creating duplicates. This repeatability is critical because we don't want to tell clients they can't upload content while we work. We need flexibility to run migrations multiple times and catch one-off errors that might occur during the process. This keeps business operations running smoothly throughout the migration. Our scripts are smart enough to detect existing content and update rather than duplicate, which means we can run test migrations, catch issues, refine our approach, and run again without creating a mess in the new CMS.
The Technical Challenges
The WordPress Plugin Problem
WordPress's open ecosystem is both its strength and its migration challenge. Anyone can create and install plugins, and these introduce new data sources, structures, and problems. Any plugin that deals with content or images requires special attention during migration. The gnarliest situation I've encountered? A custom body content plugin that wrote everything to the most incomprehensible XML format. We had to write a custom handler for over 200 tag types just to parse it correctly.
This experience taught me to set up handlers that identify unknown variables programmatically. Instead of playing guess-and-check with the data, we can systematically identify missing elements and check them off one at a time. This systematic approach transforms what could be weeks of debugging into a manageable, trackable process.
Beyond WordPress: Craft CMS and Webflow Challenges
While WordPress's open plugin ecosystem creates its own unique migration challenges, other platforms come with their own complexities:
Craft CMS: The Hidden Structure Problem
Craft's more curated ecosystem initially seems like it would make migrations cleaner. And in some ways, it does—there's less plugin chaos to untangle. But what we encounter instead is opacity. Craft's power comes from its flexibility with Matrix blocks and custom fields, which means structure gets built in ways that aren't immediately visible. Without comprehensive documentation from previous developers (and let's be honest, when does that exist?), we're essentially reverse-engineering content architecture decisions that were never formally tracked.
Matrix blocks present their own particular challenge. We've seen nested Matrix configurations that go four or five levels deep—editors building content structures within content structures, each with their own field configurations. On one migration, we discovered what appeared to be three content types in the CMS was actually 10+ distinct Matrix block combinations, each used slightly differently across the site. Every single one required its own transformation logic.
Webflow: The Variation Explosion
Webflow's visual-first approach is incredibly powerful for designers, and that's precisely what makes migrations complex. When it's this easy to make one-off customizations, teams do exactly that. Instead of creating a consistent "Team Member" collection and reusing it, we find five variations: "Leadership Team," "Advisory Board," "Department Heads," "Regional Managers," and "Contributors"—each with subtly different fields and styling approaches.
The challenge isn't that these are technically different content types. It's that they should be the same type with different presentation logic, but the platform made it easier to duplicate and customize than to abstract and reuse. This means our normalization work isn't just technical—it's editorial. We're making decisions about what should truly be distinct content types versus what should be unified with better data modeling.
Assessing Migration Complexity
The first thing we evaluate on any WordPress site is the level of custom content. If it's primarily simple text fields, titles, descriptions, basic metadata, it's an easy day. But lots of body content with rich text formatting, embedded media, shortcodes, and other dynamic elements requires significant fine-tuning and custom handling. Body content is inherently the most dynamic and therefore the most challenging to migrate cleanly. Shortcodes that worked in WordPress need to be transformed into components or content blocks in the new system. Embedded media needs to be re-associated. Custom HTML blocks need to be parsed and restructured.
The platform itself significantly impacts complexity assessment. WordPress migrations tend to be plugin-archaeology projects. Craft migrations are structure-archaeology—decoding nested Matrix blocks and undocumented field relationships. Webflow migrations are normalization projects—consolidating what should be unified content types. Each requires a different investigative approach, but all benefit from our systematic methodology of identify, document, handle, and verify.
Navigating Common Trade-offs
Images are a big trade-off point. Sometimes the source data doesn't provide all the metadata we need, alt text, captions, credits, or focal point information, so we have to write scrapers to capture it or occasionally do it by hand. When manual work is necessary, we rally the team and divide pages among us. We're all efficient with web tools, so we can brute force through that process, but it's a reminder that migration isn't purely automated. Custom HTML bits present similar challenges and require careful documentation and handling. These are the moments where having repeatable scripts pays off, we can run an initial migration, identify all the edge cases, handle them systematically, and then re-run with confidence.