A client asks for a “simple integration” between their new website and their CRM, inventory system, or email platform. Six weeks later, the project is still dragging on. It’s not necessarily because anyone gave them a bad estimate or skipped a step. The problem is that the integration was more complicated than everyone expected. The CMS simply wasn’t built to handle that kind of connection, and no one had stopped to figure out exactly how the systems would need to work together before development started. What sounded like a small task at the beginning quickly turned into a much bigger headache once the team got into the actual build.
And this happens all the time. You just don’t hear much about it in agency pitches, where integrations usually get presented as if they’re much simpler than they really are. This article looks at how leading web design companies approach CMS integrations, and why the agencies that do it well spend more time planning than coding.
The Content Model Decides Everything Before Design Even Starts
Most integration problems get traced back to the same root cause: the content model was built for the CMS’s default behavior, not for what the site actually needed to do. Fields get added ad hoc. Relationships between content types get bolted on later. By the time someone tries to pull that content into a CRM or push inventory data into product pages, the structure fights back.
Experienced teams treat content modeling as a separate phase from visual design, not a byproduct of it. What data does the CMS need to hold? What other systems need to read or write that data? What happens when a field gets renamed or a content type gets restructured six months after launch? Answering those questions before development starts is slower up front but considerably cheaper later.
Plugins Solve Small Problems and Create Bigger Ones
WordPress remains the most common foundation for these integrations by a wide margin. WordPress runs a huge share of the web, roughly 41% of all websites and around 59% of the identifiable CMS market.
But WordPress’s popularity comes with a downside. WordPress has a huge plugin ecosystem, which makes it really easy to add things like CRM integrations, payment gateways, and marketing tools without building them from scratch. When everything works, that’s a big advantage. The catch is that some of the site is now relying on code the agency didn’t build and may not have much control over.
That’s where things can get tricky. Plugins and themes are a much bigger source of WordPress security vulnerabilities than WordPress itself. So while adding a plugin might solve a problem in a few minutes, it can also create problems down the road if it’s poorly maintained or no longer secure. A good agency knows this and treats plugin selection seriously. They’ll check whether a plugin is actively maintained, look at its track record, and think twice before installing several plugins that all try to handle the same job. A weaker agency might just install the first plugin that seems to do what the client needs and move on.
Headless Isn’t a Trend, It’s a Trade
Headless CMS architecture gets presented as the modern solution to integration problems, and there’s a good reason for that. A headless CMS keeps the content separate from how it actually appears on screen. So instead of creating different versions of the same content for a website, mobile app, kiosk, and other platforms, they can all use the same source. The content is made available through an API, which means different frontends can pull from it whenever they need it. It’s a pretty useful setup when the same information needs to show up in more than one place.
But headless doesn’t magically make integrations simpler. You get more flexibility, but you also take on more technical decisions and more things to maintain. A good agency should be able to explain that trade-off clearly instead of treating headless as the answer to every integration problem.
What gets left out of the pitch is the trade involved. Headless integrations often require custom development and specific technical expertise, and the API layer can introduce performance overhead that a traditional CMS doesn’t have. There are usually no pre-built templates or default themes to fall back on, and coordinating multiple technologies across the stack creates its own maintenance burden. Agencies that recommend headless architecture without a development team capable of building and maintaining a custom front end are setting a client up for exactly the kind of drawn-out project described earlier. Headless is a legitimate answer to a specific set of problems. It’s a poor answer when the client just wants a straightforward site with one or two integrations.
Traditional vs. Headless CMS: A Quick Comparison
| Traditional CMS | Headless CMS | |
| Content and presentation | Bundled together in one system | Separated; content served via API |
| Best fit | Single website with a handful of integrations | Content reused across multiple platforms (web, app, kiosk, etc.) |
| Editing experience | Live preview and layout control built in | Often no visual preview; layout lives in custom frontend code |
| Development need | Lower; themes and plugins cover most needs | Higher; requires a custom frontend build |
| Ongoing maintenance | Concentrated in one system | Spread across CMS, API layer, and frontend |
| Where it breaks down | Struggles with multi-channel content reuse | Struggles when the team lacks frontend development capacity |
Content Editors Are Part of the Integration, Not an Afterthought
A CMS integration can work perfectly from a technical standpoint and still fail if the people using it every day find it frustrating. One downside of headless CMSs that often gets overlooked is that they can be a lot harder for content teams to work with. If someone is used to a traditional CMS, they may suddenly lose simple things they’ve relied on for years, like being able to preview a page or make basic changes to the layout themselves.
That might not sound like a big deal at first, but it can get frustrating pretty quickly. If the marketing team can’t see what a page will look like before it goes live, they may stop trusting the system. Or they start asking a developer to make every small change for them. And once that starts happening, you have to ask what the CMS is really solving. If every little content update needs a developer, the new setup may be creating more work than it saves.
Migration Is Where Estimates Fall Apart
Every CMS integration eventually runs into the same moment: moving existing content into the new structure. This is usually where timelines slip, because real content rarely matches the clean structure everyone assumed during planning. Fields are inconsistent. Some records are missing data the new system requires. Images were named and sized for a system that no longer exists.
The agencies that do this well look at the existing content before they write a single line of migration code. They work out what’s worth keeping, what needs to be cleaned up manually, and what probably isn’t worth bringing over at all. Skipping that step doesn’t make the messy content disappear. It just means you’re carrying the same problems into the new system. It just carries the problem into the new system, where it’s usually harder to spot and more expensive to fix.
What “Good” Actually Means, Beyond “It Didn’t Fail”
It’s easy to say a good agency plans carefully and a bad one doesn’t, but that’s a vague standard on its own. The agencies worth hiring tend to measure a successful integration against a short, specific list rather than a general feeling that things went fine:
- Time to make a content change. Can a non-technical editor update a page or trigger a workflow without filing a developer ticket?
- Data consistency across systems. Does the CRM, inventory system, or email platform stay in sync without manual reconciliation, and how quickly does a mismatch get caught?
- Maintenance burden after launch. How many hours per month does the integration realistically require to keep running, and does that match what the client was told upfront?
- Recovery time when something breaks. When a plugin update, API change, or workflow tool fails, how long does it take to identify the failure and fix it?
- Adoption by the team who has to use it. Are content editors and other staff actually using the system as intended, or working around it?
None of those show up in a project kickoff deck, which is exactly why they’re useful questions to ask a prospective agency. A team that can point to how it tracks these things after launch has usually learned from real projects, not just pitched them.
What Good Integration Planning Actually Prevents
The pattern across all of this is consistent. Integration problems usually don’t show up as some big, obvious failure. More often, they show up as delays, awkward workarounds, and a system that technically works but makes everyone’s job harder. A vendor payment feed that updates a day late. A content team that avoids a feature because nobody explained how it works. A plugin conflict that surfaces three months after launch, when the person who installed it has moved on to another project.
None of that gets caught by asking whether an integration is technically possible. With enough custom code, you can make almost anything work. But that’s not really the question you should be asking. The better question is whether the integration actually fits the way the business works, rather than simply matching what the CMS says it can do.
What to Ask Before Choosing a Development Partner
Before you hire an agency, ask them to show you how they’d actually structure your content. Don’t just listen to a list of features they can build or a general pitch about what’s possible. You want to see whether they’ve thought through how your team will use the CMS day to day and whether the setup will actually make sense for the business. Don’t just ask for a list of features they can build. It’s also worth asking how they choose and vet third-party plugins. What happens if a plugin they’re relying on stops being maintained? Do they already have a plan for replacing it, or will they only deal with it once it becomes a problem?
And if they recommend a headless setup, ask whether they’ve actually built and maintained a custom frontend before. You want to know they’ve dealt with the practical side of that setup, not just read about the benefits. And ask what happens to the content team’s day-to-day workflow once the CMS is no longer handling the page layout.
The agencies worth trusting should be able to give you specific answers, not vague promises. If an agency can tell you what they’ve built, where things went wrong, and how they fixed them, there’s a good chance they’ve actually learned from doing this work, not just selling it. CMS integrations are usually won or lost before development even begins. The decisions made upfront tend to matter far more than the problems the team has to scramble to solve later. The content model, the plugin choices, and the editorial workflow matter more to the outcome than which platform gets chosen. An agency that thinks through those details before development starts is usually the one worth hiring. If you’re looking for a team with experience in this area, browse our vetted list of web design agencies and find one that knows how to handle CMS integrations properly.