Contentful's Luke Wertz & Nick Switzer on Migrating Off Legacy CMS

Legacy CMS platforms lock your front end and back end together, so every new channel becomes its own project. In Episode 45 of Beyond the CMS, Chris Bryce sits down with Luke Wertz and Nick Switzer of Contentful for a live AMA on what it actually takes to move off WordPress, Drupal, Sitecore, or AEM and into a modern, composable content stack.

Luke manages Contentful's commercial mid-market solution engineering team in North America, and Nick manages the enterprise side from Denver. Between them they have close to four decades in the CMS space, and they walk through Contentful's founding story in Berlin, where updating a single word in a native mobile app used to mean shipping an entirely new version of the app.

We cover the real difference between legacy, monolithic, and composable platforms, what a 2026 migration actually looks like, why Contentful stays rigid on structured JSON delivery while building flexible tools for editors, and how Contentful's AI Actions and API first management layer let agents like Claude create, scale, and govern content directly inside the platform.

Key topics

Why Contentful was built for API-first content across every channel, not just the web
The honest difference between legacy, monolithic, and composable CMS platforms
What migrating off WordPress, Drupal, or Sitecore into Contentful actually looks like in 2026
Content modeling as the foundation that makes reuse and speed possible
AI Actions and how Contentful embeds generative AI into the content workflow itself
Why Contentful chose to stay rigid on structured JSON delivery and flexible on the human editing experience
Agentic content operations: connecting Claude to Contentful for migration, governance, and alt text audits
Structured content and AEO: why composable architecture helps brands get cited by AI
Contentful's roadmap: agentic analytics, agentic content management, and agentic migration

Chapters

0:00 Welcome to Episode 45: the "Car Guys" origin story
1:29 Meet Luke Wertz and Nick Switzer of Contentful
3:53 Contentful's founding story: an app that needed a new release just to change words
6:18 A Dotfusion case study: one hub for app, web, and in-store screens
6:43 Defining headless: content infrastructure over jargon
8:05 Headless in plain English: separating content from presentation
9:33 The developer view: content models and the job of your content
13:05 Where a Contentful site actually lives: SaaS hosting, not patching
16:49 Legacy, composable, and monolith: mapping the CMS market
18:53 Why teams migrate once content needs to do something
20:38 Choosing Contentful when your team is lean
22:09 AI inside the platform versus AI acting on the platform
23:09 API first for delivery and for management
25:17 Live question: have we passed the tipping point for composable?
27:10 Rigid on delivery, flexible for humans: structured JSON and live preview
29:24 Claude and Contentful: a week of content ops down to an hour
31:11 What's next: agentic analytics, alt text agents, and closing the loop
33:40 The next two problems: scale and governance
35:50 A third M for the roadmap: plumbing, and agentic migration
36:49 Wrap-up: thanks, and see you in Episode 46

Frequently asked questions

What is Contentful? Contentful is an API-first, headless content platform founded in Berlin that lets teams manage content in one place and deliver it to websites, mobile apps, kiosks, and AI agents.

What does headless CMS mean? Separating content from presentation. Content lives in a structured API layer, so the same piece of content reaches a website, app, or screen without being rebuilt for each channel.

What's the difference between a legacy CMS, a monolithic CMS, and a composable CMS? Legacy platforms like WordPress or Drupal couple the front end and back end together. Monolithic enterprise platforms bundle heavy infrastructure that many teams underuse. Composable platforms like Contentful separate content from delivery so teams can move faster with a narrower engineering footprint.

What does migrating off WordPress or Sitecore to Contentful involve? Mapping existing, often unstructured content into a defined content model, then moving it in phases rather than a single big-bang rewrite. Contentful's API-first architecture and modern tooling, including AI-assisted migration, make that mapping step faster than it used to be.

Where is a Contentful site hosted? Contentful is a SaaS platform, so Contentful runs the infrastructure, security, and CDN delivery. Teams typically pair it with a front end host like Vercel and no longer patch servers or manage plugin updates themselves.

What is content modeling and why does it matter? A content model defines the structure of a piece of content, like a blog post or a promotion, so it can be reused across every channel without being rebuilt each time. Getting the model right up front is what makes everything downstream fast.

What are Contentful AI Actions? Pre-built generative AI templates inside the Contentful workflow for tasks like translation, SEO metadata, and alt text, run in bulk or automatically rather than bolted on as a separate tool.

How does structured content help a brand get found by AI? AI agents cite content they can parse cleanly. Structured, schema-rich content from a headless CMS is already formatted the way agents and crawlers expect, which is the foundation of answer engine optimization.

Can an AI agent connect directly to Contentful? Yes. Contentful's API-first management layer means anything done in the interface can also be done through an API, so an agent like Claude can create, review, and manage content the same way a person would.

What is agentic content operations? Using AI agents to create, scale, and govern content rather than treating AI as a single writing tool. Contentful frames this as three stages: create, scale, and govern, with people staying in the loop on approval.

What is Contentful's role in a composable or MACH stack? Contentful sits at the center as the content hub, feeding structured content out to whichever front end, app, or channel a team chooses to build.

What are the next challenges once AI is creating content at scale? Scale and governance. Once AI can produce more content than a team can review by hand, the harder problem becomes making sure the right content goes out and that it is properly controlled.

Related from Dotfusion

We have been a Contentful partner for years, building composable, API-first sites for enterprise brands moving off legacy platforms. See our Contentful development services.

Links: Contentful https://www.contentful.com | Dotfusion https://www.dotfusion.com

Full transcript

Edited lightly for readability.

Welcome to Episode 45: the "Car Guys" origin story

All right, we are live. Amazing. We are on Episode 45 of Beyond the CMS. The show started with the intent to bring the leading thought leaders in the content industry together for open conversations about the state of content operations now and into the future. I was inspired by the Car Guys, who I listen to on NPR. I just thought it was cool that people could call in and get their carburetor problems solved live over the airwaves, and have a friendly conversation while they were at it. We have got an amazing lineup of thought leaders here today.

Before I introduce this week's guests, thanks to everyone making time during lunch in the Eastern time zone, and breakfast on the West Coast. We are live on LinkedIn right now. If you have questions for any of us, leave them in the comments. The technology on our end should bring your comments up live so we can answer them. If that does not work for some reason, we will look through the comments afterward and get back to you. And if you are watching this in the future, leave a comment and give us a like. We really appreciate it.

Meet Luke Wertz and Nick Switzer of Contentful

I'm Chris Bryce, founder and CEO of Dotfusion. We are a Contentful partner, and today we have got Luke Wertz and Nick Switzer from the solution engineering team at Contentful joining us to share their thoughts on what's happening in the world of content. You both have engineering backgrounds and have bridged over to solutions, which gives you a really great broad scope of information to share with us. Luke, maybe introduce yourself, and then we will get going and have a wonderful chat.

Thank you so much for having us, Chris. It's a real privilege to be here. I'm Luke Wertz. I manage the commercial mid-market solution engineering team for Contentful here in North America. As you mentioned, I spent about 20 years on the implementation side, helping implement a wide variety of CMSs for a lot of different types of customers. Now I get to help at the solutioning stage, pretty early in planning, thinking about how to solve specific business challenges with technology.

Nick, welcome. What's going on out there in the high mountains?

Great to be here, Chris. Joining from Denver, one of Contentful's headquarters cities, so we have got a great presence here. Honestly I would just be repeating a lot of what Luke said if I gave you my background, because we have had the privilege of our careers overlapping for the last fifteen or so years. Like Luke, I spent about 20 years in the CMS space and ran an implementation team for quite a while before coming to Contentful. Now, like Luke, I sit on the pre-sales side focused on consulting and solving business problems. My team specifically supports our enterprise customers and prospects. I should set expectations here that I am not the carburetor guy, so we will point those questions toward Luke.

I'll talk carburetors.

Awesome, can't wait.

Contentful's founding story: an app that needed a new release just to change words

I'll ask one or the other of you questions to keep it simple. Luke, do you want to talk a little about Contentful's history? I believe the idea was created in Berlin. Can you share what Contentful actually is?

Absolutely. Contentful was founded in Berlin, though we have offices all over the world now. It really started with a simple idea. Back when Sasha and Paolo founded Contentful, updating content in a native mobile app on an iPhone or Android meant releasing a whole new version of the app just to change the words or the pictures. The overhead becomes huge for teams managing multiple versions of an app. So the idea was: how do we make it easier for teams to manage the words, the pictures, and the digital experience, and deploy them from a centralized location regardless of channel. Even though it started as a native mobile app problem, it caught on quickly everywhere else. Normal websites lean on this architecture at scale, and so do mobile apps and digital signage, basically anywhere you need to get messaging to a device connected to the internet. Taking a headless approach, using a platform like Contentful, makes that easier, scales better, and streamlines the process. It was a really cool solution to a problem that was very emergent back in the early 2010s, when Contentful was founded.

A Dotfusion case study: one hub for app, web, and in-store screens

That lines up with our experience. One of our larger Contentful projects was for a very large pizza chain, and the solution needed exactly that: a centralized content hub for a mobile app and a website, with the plumbing already in place for display screens at the retail locations down the road. With a composable or headless architecture, it doesn't matter where you publish. You can publish anywhere without changing the core foundation of where your content lives. I use the word headless a lot, and I have a whole collection of different definitions people have given me, because I still get asked what it means today. The folks who watch this show, typically CMOs and VPs of marketing, are not so concerned about the tech stack. They care about how easy their publishing workflow is. Nick, can you give me your best definition of headless, for the record?

Defining headless: content infrastructure over jargon

For sure. Let me reframe it slightly, because our founder Paolo said something interesting in a public internal meeting once: he never really liked the term headless, because it defines what the platform is not rather than what it is. We like terminology like content infrastructure, which we landed on a few years ago, and these days we hear composable a lot in the market. Not to say headless is the wrong word, it is a totally valid term, but there are a few interchangeable terms out there that all point at similar value.

Headless in plain English: separating content from presentation

I like content infrastructure because it feels relevant to the world we are living in now, where content gets delivered and managed by agents and lots of different tools. We are thinking a lot about AEO and agentic assembly. To answer your original question, headless is about separating the content from the presentation. That matters because it lets you build content as clearly structured elements with clear governance and process around them, which makes those use cases so much easier. Quick serve restaurants are a great example, we have a lot of customers in that space. Take a Tuesday lunch special promo. It's going to look a little different on your website, a little different on your mobile app, a little different on your drive up order screens, and regional restaurants will probably want to localize it too. The real power of headless is that you manage that content in one place, update it in one place, and it gets pushed out to every channel. You know it's the right content, properly governed, and customers get a consistent way of engaging with your brand no matter where they show up.

The developer view: content models and the job of your content

Let's bend the conversation into some developer speak too, because this matters a lot for devs exploring different ways to ship and deliver. Luke, can you describe the headless architecture itself, and the idea behind microservices and the developer opportunity with Contentful?

Absolutely, and at the risk of going too nerdy, hold me back. Rooting this in value: why make this choice? At the end of the day we are not choosing an architecture for fun or out of ideology. We choose it because we need to accomplish something. Microservices or a headless architecture shift the focus away from what the content is in the abstract, and center the conversation on what the job of the content is. Once you focus on what you need the content to do, chances are it needs to do the same job whether it's presented on a website or a native mobile app. Working back from the idea that your content has a job, you can articulate that job, and then express it as a content model. That's where the underlying plumbing comes in. Once you have that abstract description of the content's job, you can abstract one level further and create instances of that content. You create multiple types of content, manage it in one centralized place, and distribute it to many different places. That final last mile of delivery, whether it's a mobile app or a website, shapes a lot about the experience around the content. But the editorial team, the marketing team, whatever title they carry these days, gets to concentrate their effort in one place and have that impact felt everywhere. That's my best shot at a non-technical definition of headless architecture.

That is awesome. I have actually been role-playing through some recent conversations, trying to describe why to consider a composable architecture to a very non-technical team. I was lucky enough to have a stakeholder who was a developer, and I got put on the spot: what do you recommend? I avoided anything platform specific and said Next and React are great for a lot of reasons, and that's the kind of fundamental stack decision you can make powering Contentful. Something else came up in that conversation: where do we host it? They had something like a DreamHost server, and the honest answer is you don't really host anymore, but you kind of do, there's static site generation and an edge network involved. Nick, can you take a shot at how you answer, where is a Contentful site actually hosted?

Where a Contentful site actually lives: SaaS hosting, not patching

Piggybacking on what Luke was saying, it's easy to get lost in the weeds here. There are important conversations to have around CDN configuration, cache invalidation, and your front end framework, but ultimately, what is the outcome you care about? From a technical perspective it comes down to getting to market faster and operating more efficiently as a business. Having worked in the world of self-hosted, manually updated open source CMS, I know the personal pain and the organizational cost of maintaining hosting. Applying Linux patches, monitoring for security updates, applying core platform updates, applying plugin or module updates, there is a whole world of work that stacks up. From a purely Contentful standpoint, it's a SaaS platform. We have a dedicated infrastructure team, a dedicated security team, and battle-tested APIs and CDN configurations that perform at scale, delivering billions of requests every month. That's all work our joint customers are no longer doing, which frees those teams to focus on higher value work, building net new things that drive the business forward. So to answer directly: we handle where it's hosted from the Contentful side, and we have great partners in the industry. Vercel comes up a lot as a front end hosting and delivery partner with a similar value proposition, all focused on the same outcome, getting to market faster, operating more efficiently, and building the value and revenue growth your company cares about.

Super cool. I was talking to our COO recently and she said, 'I just published a site to Vercel using Claude Code.' I thought, the world is so awesome right now. Shout out to those guys, they are making the delivery of ideas quick, easy, and manageable.

Legacy, composable, and monolith: mapping the CMS market

When we talk about CMSs on this show, they tend to fall into three categories. There's legacy, the WordPress and Drupal kind of platforms that have matured through open source communities over time. In the middle there's headless and composable, fast, light, and quick to get to market. And then there's monolithic, heavy infrastructure that does a lot of things, sometimes more than people actually use. I want to understand where Contentful sits across that range, and then get into a question that always comes up for folks moving to a more modern stack: migration itself. Luke, what do you think of how I've defined that ecosystem?

That's totally fair. These solutions emerged to solve specific problems. The self-hosted, legacy platforms, the Drupals and the WordPresses, existed to lower the barrier to entry, to get people who are just starting out something up and running, backed by a lot of community support. That makes sense, it's a choice with pros and cons. On the monolith side of that continuum, nobody got fired for choosing IBM. There are safe choices out there. Those solutions exist too, and they solve a specific problem set, which may or may not be a business problem.

Why teams migrate once content needs to do something

Fair enough. When I think about solutions like Contentful, composable solutions that focus on integrating widely to expedite migrating into the platform, we know most people are coming to Contentful from somewhere else. We have to make that migration straightforward. We sit in a space where people coming in need to move fast, need to ship. Their needs vary in terms of where content gets delivered, and where else in the tech stack it might need to be transformed, actioned, or reviewed. That's the point of the API first part of the headless definition: it's easy to have content created and managed in Contentful show up somewhere else, get transformed, and get written back in programmatically, with no editor needing to copy and paste. Once teams start to feel the pressure of needing their content to actually do something for them, not just sit there, that's when they start looking at headless, composable solutions like Contentful. We make it easier to do the meaningful things with your content.

Choosing Contentful when your team is lean

I'm trying to leave something useful here for folks who don't know which to choose.

Just choose Contentful, that's easy.

Well, that is what we did, and it makes a lot of sense. I used to work with global integration shops and did a lot of AEM work in my day, and that has its place. But I came back to a smaller agency size where we need to get things done quickly, without multiple layers of engineering. A point that's maybe not well known about a platform like Contentful is that we can develop on it so quickly with a narrower engineering skill set. It's primarily front end, with a bit of tooling, but we can move fast and build things that are genuinely beautiful. Our ethos is beautiful technology, we love things that look good, and we are not limited by the tooling connecting the presentation to the back end. We are free to run, and your portfolio of projects from global brands backs up the ability to create really beautiful experiences too. I think that's important.

AI inside the platform versus AI acting on the platform

Time goes by really quickly once we get rolling. We have got to throw some AI into the conversation. AI is impacting content platforms and the experience of using them in a couple of different ways. There's AI within the platform, and there's the external use of your own frontier models at your agency, brand, or organization to interact with the platform. Nick, can you take us down the AI path?

Let's go. I'm glad you mentioned it, because I hinted at this earlier. What's fascinating, and I think folks are really starting to pick up on it this year, is that there's the delivery side, which is what we have been thinking about for a while. But there's also the management side, and that's where the distinction between legacy, monolithic, and composable, and what headless and API first actually mean, really starts to matter. That's where we are seeing some interesting impact right now.

API first for delivery and for management

Contentful has been API first from day one, and we have talked a lot about the delivery side of that. It makes it easier to get content into mobile apps, websites, and digital displays. But it's also API first on the management side, which means everything you do in the Contentful interface you can also do through an API. When you click in that interface, it's literally calling our content management API under the hood. For AI, that matters because machines understand code, and APIs are how machines talk to each other. Headless platforms, and Contentful specifically, are well positioned to interact with agents, both through in-platform integrated AI and through the broader tooling ecosystems businesses are using to bring agents into their day-to-day work. Agents can natively interact with the platform and do all of the same things a human can. When you combine those, you get to a process we talk about a lot: create, scale, and govern your content. Agents create the content, and Contentful has always done scale and governance well, keeping humans in the loop and making sure content is delivered to every channel dependably. That's where businesses are going to see real acceleration from meaningful AI involvement in their workflows, not just 'hey Claude, go write me a blog post' with no idea who you are or what you talk about as a brand.

Live question: have we passed the tipping point for composable?

Let me take a minute to acknowledge someone from Denver saying hello. Gabriel writes on LinkedIn: 'It really feels like we passed the tipping point favoring composability. There are differences, but the cost benefit seems more in balance these days, especially with AI coding.' Gabriel, if you are still listening, clarify that and we will address it. But one point worth chatting about openly, and one of the real challenges of composable systems, is total cost of ownership. As an agency, we need different ways of estimating total cost when we scope a project. The interesting part is that the CMS, Contentful itself, is typically not the barrier. It's figuring out the scope of connecting ancillary tooling. What I'm seeing, and I'd love your take on this, Luke and Nick, is that headless CMSs, Contentful included, have acknowledged they can't be rigidly API only. We built a visual editor, and that move made a lot of sense: you get the best of both worlds, you can see what you're doing, but you're still working with content models. Luke, can you talk about where Contentful chooses to be rigid around the composable idea, versus where it bends to make the tooling and the cost make sense for people?

Rigid on delivery, flexible for humans: structured JSON and live preview

Oh man, we don't have enough time left, but let's leave the chat on. At the root of your question is optimizing for humans versus optimizing for machines. Legacy or monolith platforms force you into a specific choice, you either optimize for the machines or for the humans. Where does Contentful choose to be rigid or not? We choose to be rigid on delivery. It's structured JSON, one hundred percent of the time. We help you take that structured JSON through our SDKs and other tooling and turn it into whatever the final delivery needs to be, HTML for your website, or your language of choice for native mobile apps. That's the rigidity on delivery. On the human side, that rigidity is what lets us build tools to optimize for the human experience, immersive live preview environments where a user sees the impact of their work in real time before they hit publish. That's powered by the rigidity in delivery: we can cleanly offer an API endpoint with access to unpublished content and one without. The one without is for public delivery, the one with draft access is for internal preview, and they are structurally identical. That rigidity, that structure, that governance is what enables all of it. And because the delivery side is structured JSON, well described and tightly formatted, it's already optimized for machines out of the box. You don't have to choose either or, or sacrifice time optimizing for one side at the expense of the other.

Claude and Contentful: a week of content ops down to an hour

Speaking of time, Gabriel got back to us with a bit more clarity, and he makes a great point. When you're choosing your infrastructure, composable Contentful lets you get going quickly, and if you add modern agentic engineering into that tooling, you get an accelerated go to market. Claude and Contentful are basically best friends out of the box. We have run all kinds of experiments where elaborate content workflows that used to take a week of effort across multiple teams, moving a little bit of content around its supply chain, now take about an hour. It's really well done. Compare that to the monolithic tool sets that look sexy to buy, with all that stuff going on, but there's Java underneath, and you need a really serious bunch of people ready to deploy it, and it takes a long time.

High pain tolerance required.

Very high pain tolerance. It has its place, but we really love the nimble go to market speed we have here.

What's next: agentic analytics, alt text agents, and closing the loop

Before we head out, I want to talk a bit more about Contentful the product, some of the features and the roadmap you are open to sharing, to leave folks thinking, oh wow, I hadn't thought about this. Luke, let me throw out a couple of thoughts and then you chime in. Without getting too far into specific commitments, as a business we're thinking a lot about how we support creating and optimizing experiences for humans and for machines. On the roadmap, we're thinking about things like agentic analytics, which you'll see from us very soon. Luke, you have talked a lot about whether your content is actually working for you. Agentic analytics closes that loop inside Contentful: is my content working, if not what else should I try, did that work, and you keep going from there. Managing that with agents means instead of going to a complex data dashboard or a team of analysts, you're having a natural language conversation: where is my content performance weak, where is it strong, let's build an audience and run an experiment where it's underperforming. Taking that further, we're thinking a lot more about agentic content management and agentic assembly and delivery, and how we help teams deliver the value their business needs faster.

This can manifest in small, basic ways too. A pain point that has been a problem at enterprise scale for a long time is a question as simple as, find me all of my media that doesn't have alt text. That can be a genuinely painful process without a lot of concerted thought behind it. Bring a content operations agent into the platform, or connect Claude Desktop through an MCP server, and you can just ask that question and get the answer instantly. That's the theme I'd put forward closing out, knowing we're already a couple of minutes over: how do we empower folks to operate more efficiently and produce higher quality content in the fast moving world we're all headed toward. Luke, you spend a lot of time thinking about this too, I'd love to hear what I'm missing.

The next two problems: scale and governance

I'll give you my 30 second answer. I love the question, because at the root of it, you're asking what I'm most excited about, what's happening. We are at an inflection point right now in redefining what it means to create content. A lot of the folks I'm talking to right now, that's the problem right at the end of their nose, how do I type the right prompt to get the right thing on the screen. I have gray hair, I've been doing this a while, and I can tell you: I get that's the problem you're thinking about right now, but let me tell you about the next two problems you're going to have. Once you get prompting absolutely dialed in and everyone is working at lightning speed, the next two problems are scale and governance. As soon as you let the robots start making content for you, you're going to have more content than you know what to do with. How do you make sure the right content is scaling, and that you've got the governance controls in place to make sure the right content is getting out? When I think about Contentful's history and where we started, we have great plumbing. Nobody likes to buy plumbing, but our infrastructure is so good.

A third M for the roadmap: plumbing, and agentic migration

Being able to run agents at scale, with the necessary controls in place to scale content production and then govern it, that feature set may not make the headlines, the banners and the ads, but it's what's going to really change teams' daily experience of making and managing content over the next two, three, four years. That's what I'm excited about.

I'll throw down a final excitement moment and add an M to your making and managing: migrating. Some of the fun stuff we're doing in the Dotfusion lab is agentic migration tooling. We are literally moving thousands of pages off WordPress into Contentful models, with controls built in, over a weekend. AI is genuinely great at migration, there are intricacies to get right and dialed in, but with Next, React, and this kind of clean content modeling, it just works. So that's the three Ms of the roadmap: making, managing, and migrating.

Wrap-up: thanks, and see you in Episode 46

It looks like we have got another couple of hours of cool stuff we could talk about, and maybe we will do this again, but people are probably finishing up lunch and heading back to work. Thanks to everyone who commented on our thread. For those of you just joining, listening, and for folks who listen in the future, we are stoked to share what we know. I'm Chris from Dotfusion, we are Contentful partners, we love building on the platform, and we can't wait to show some of the cool stuff we're doing with agents and with humans, making the world a better place along the way. Thanks, Luke and Nick, really appreciate your time and the thought you put into sharing with everyone here. I'm going to press some buttons and end the show. We'll be back in a few weeks for Episode 46. Thank you both.

Thanks, Chris. Thank you.

Episode 45: Beyond The CMS #45 - Migrating Off Legacy CMS - Luke Wertz & Nick Switzer (Contentful)