We've built on every major CMS.
Happy Cog works across every major content management platform and holds official partnerships with many of them, so the platform recommendation comes out of your requirements, your team, and the stack you already run. Most agencies bidding on this work resell one system, which means the answer is settled before the first call. Ours isn't. Some clients hire us for a full replatform with a deadline attached, and some hire us for one question about whether the system they already have is worth keeping.
Twenty-seven years of building systems people still use.
We came out of the web standards movement, so semantic structure and accessible markup were part of the practice long before clients were paying for either. Content modeling is that same discipline pointed at a different problem, and it's the reason our builds tend to outlast the design that shipped on top of them. We have work still running well more than a decade after launch, which in web terms is a long time.
Building content management systems since the web standards era.
WordPress VIP Premier Partner, Craft Verified Partner across Craft, Commerce, and Enterprise, and Stripe Premier Partner, with production work on Sanity, Contentful, Storyblok, Webflow, and Shopify as well.
Content models built for publishing, B2B, education, non-profits, e-commerce, and restaurant groups.
Founded
Web standards and accessibility
Building on Craft before it carried the name
Headless and composable architectures in production
Content models built for AI retrieval
Three things go wrong with a CMS, and we get hired to fix all three.
The system was configured for launch day, not for the five years after it.
The templates got locked down to protect the design, and now changing a two-column layout takes a development engagement. Your marketing team files tickets for work it should be doing itself, and the site slowly stops changing. This is the most common reason we get called, and the fix usually sits in the content model rather than in the platform, which is why replacing the CMS on its own tends not to solve it.
The platform reached end of life and nobody warned you.
Kentico 13 goes unsupported at the end of 2026, and several organizations we’re working with right now heard that from us rather than from the agency that built their site. Once a hard date is attached, the migration gets scoped as an emergency, and emergencies are where search equity, historical content, and undocumented integrations quietly go missing.
The migration moved the pages and lost what was underneath them.
Page count is never what makes a migration expensive. The cost sits in the dealer locator, the gated member library, the recipe archive, the Salesforce sync nobody wrote down, and the redirect map that decides whether your organic traffic survives launch week. We’ve inherited enough of these to know where they break.
CMS work here covers six areas, and most engagements pull from several.
You can hire us for the whole program or for one phase of it, and each phase is scoped and priced on its own.
01 Platform selection and content modeling Choosing the system you’ll live with for the next five years, then modeling the content that has to live in it. +
Our team audits what you have now, meaning every content type, taxonomy, relationship, and editorial workflow, and maps it against what your people actually need to publish. Working across this many platforms is what makes that recommendation worth something, since the answer can land on whichever system actually fits. A fair number of our recommendations come back as “stay where you are and fix the content model,” which is not an answer a single-platform shop is in a position to give you.
02 CMS implementation Craft, WordPress VIP, Sanity, Contentful, Storyblok, and Webflow Enterprise. +
Craft is where we go for complex data modeling, custom integrations, and modular systems, and we’ve been building on it since before it carried the name. Craft Commerce handles products with real variant complexity. WordPress VIP is the answer for publishing at enterprise scale when security and compliance requirements come attached, which is why it shows up so often in publishing and media work. Sanity and Contentful earn their place when the same content has to feed a website, an app, and something else besides. Webflow Enterprise gives a marketing team more independence than anything else on this list and gives engineering the least room to work. We’ll tell you which trade you’re making before you make it.
03 Headless and composable architecture Decoupled front ends, API-first delivery, and multisite systems. +
Our engineers build Next.js and Vue front ends against a headless back end, and we run multisite systems where a dozen brand domains share one content model and one component catalog. Headless carries a real editorial cost, since preview, layout control, and publishing workflow all get harder, so we recommend against it whenever the content operation isn’t staffed to absorb that. When it does fit, it’s usually because several channels need the same content or because the front end has performance requirements a template layer can’t meet.
04 Replatforming and migrations Kentico, Drupal, Sitecore, Adobe Experience Manager, and proprietary systems. +
This is the largest part of our CMS practice right now. The work covers a complete content type inventory, taxonomy mapping, a URL audit and 301 redirect strategy that protects the search equity you already earned, scripted and manual migration paths chosen per content type, and an integration inventory so nothing that was quietly load-bearing disappears. Our team has moved product catalogs past 2,500 items for B2B manufacturers and resource libraries past 6,000 items for education publishers.
05 Integrations and systems work Salesforce, HubSpot, Bynder and other DAMs, Stripe, Algolia, Auth0, and custom ERP. +
We keep the systems that already work and rebuild the connections into the new platform. We’ve been building on Stripe for over a decade, with certified Stripe implementation architects on staff, and we were one of Stripe’s first partners. Where the current connectivity was never documented, which is more often than not, our team runs a technical discovery pass before we’ll put a number on the integration work, because an estimate written without that pass is a guess.
06 Author experience, governance, and training Component catalogs, editorial workflow, permissions, and documentation your team keeps. +
This is the part that answers the first problem above. Our team builds a catalog of modular blocks so that column counts, layout variations, image treatments, and content slots become authoring decisions rather than development tickets. We don’t hand over black boxes: your team gets training, written documentation, and a system it can run without calling us. Clients keep us because the work is good rather than because leaving would be expensive.
Search, answer engines, and AI retrieval
Our SEO team sits in the room from discovery rather than arriving after launch, because most of what decides organic performance gets settled during content modeling. The URL structure and redirect map are designed by our SEO lead before a single template is built, structured data (Product, Article, FAQPage, BreadcrumbList, and Organization) is implemented inside the code templates rather than bolted on with a plugin, and the content model itself is shaped so entries carry the fields an answer engine needs in order to quote them. Core Web Vitals, crawl depth, internal linking, and sitemap generation are treated as build requirements with acceptance criteria, not as a cleanup phase afterward.
The same structure that helps a page rank in Google is what makes it retrievable by ChatGPT, Perplexity, Gemini, and Google’s AI Overviews, so a build that gets this right is doing both jobs at once. Getting it wrong is expensive to reverse, since retrofitting a content model means touching every entry on the site.
Accessibility and performance
WCAG 2.1 AA and Core Web Vitals from the first wireframe rather than as a remediation project afterward. Our team came out of the web standards movement and has been building to these standards since well before clients wrote them into contracts.
Your team can build pages from Claude or ChatGPT without opening the CMS.
Most marketing teams are already drafting in an AI assistant and then pasting the result into the CMS by hand, which strips out the structure on the way in and leaves the editor doing the dull half of the job. We connect the two directly, so the assistant writes into your content model instead of into a text box. An editor can ask for a new landing page, a product update, or a set of regional variants, and it comes back assembled from the real entry types, fields, and components your site is already built from.
Built on MCP, against your actual content model
We build and host an MCP server for your CMS, scoped to the sections, entry types, and fields you decide an assistant should be able to see and touch. Because it works through your component catalog rather than through free-form markup, what comes back is a page your templates can actually render, with the right fields populated and the relationships intact. This runs on Craft, WordPress, and headless platforms alike, and it works on a system somebody else built, so it doesn’t require a replatform first.
Governance, so nothing publishes without your review
Everything an assistant creates arrives as a draft inside the editorial workflow you already run. Your permissions apply, your review steps apply, and your people sign off, which means an AI-drafted page reaches the live site only after someone decides it should. Every change carries a record of what was generated, from which prompt, and who approved it, and you can keep whole sections and fields out of reach entirely. We set these rules during content modeling, alongside the component catalog, because both are answering the same question about what an author is allowed to do.
You can scope this as its own phase or fold it into a larger build. Either way the work is the same: model the content properly, expose it deliberately, and keep a person on the approval.
Here’s how a CMS engagement actually runs.
We won’t start the build until the content model is signed off. That sounds obvious, and it’s the single most common place these timelines break.
Discovery and content architecture
Our team inventories the existing instance in full: every content type, data relationship, integration, editorial workflow, and access rule, each mapped to its equivalent in the new system. An SEO lead runs the URL audit and redirect strategy in this same phase rather than later. What comes out of it is the architectural blueprint for everything that follows.
Content model and component catalog
Sections, entry types, fields, categories, and content relationships, plus the catalog of modular blocks your marketing team will build pages from. You sign off here, because this is the decision that determines what the site is capable of for the next five years.
Modular build
We build component by component so your team can start using the system while it’s being built rather than meeting it for the first time in UAT. Structured data and schema markup go into the templates during this phase, alongside the components themselves.
Migration, redirects, and integrations
Scripted and manual migration paths run per content type, the 301 map deployed and tested against the full live URL inventory, and the CRM, DAM, search, and commerce connections rebuilt and verified against real data.
QA, launch, and knowledge transfer
Accessibility and performance testing, editor training, written documentation, and a defined post-launch window where our team watches crawl behavior, indexation, and rankings rather than assuming they held.
Each phase is scoped and priced on its own, and you can stop after any of them. How long the whole thing takes depends on content volume, integration complexity, and how much of the existing system was ever documented. We’ll give you a timeline before we start, and we’ll tell you if something we find in discovery changes it.
Three builds where the platform decision was the whole decision.
Central Park Conservancy
Since 2020 we’ve worked with the official caretakers of the park to build the definitive Central Park website, with a CMS, interactive maps, and a great deal underneath. It rolled out in phases through the pandemic and after it, which is the honest version of what a multi-year platform roadmap looks like: sequenced so each phase could be funded and shipped on its own.
Read the case study →
Wayside Publishing
A world language textbook publisher that had just acquired Fluency Matters and needed one site to carry both catalogs. The work turned on taxonomy: a content model with enough structure to cross-link titles, professional development, and support, so the site could explain proficiency-based pedagogy instead of burying it. Their own stakeholder put the brief plainly, that they had gone from a four million to a twenty million dollar company and needed a website that read like it.
Read the case study →
Chief
The career network for senior executive women needed an editorial platform rather than another marketing site. We built the publication headless on Sanity, with the article structure carrying the weight: contrasted headings, typographic cues, and lists that survive scanning. One content model serving two audiences, the readers who become members and the executives who have to be persuaded.
Read the case study →increase in mobile conversions for a global life sciences manufacturer after a modular CMS rebuild, alongside a 32 percent lift in organic traffic.
saved per transaction on a multi-location ordering platform, contributing to more than $3.4M in online order revenue in a single year.
reduction in cloud infrastructure costs for a wellness publisher after a headless replatform.
We build on every major platform, so the recommendation follows your requirements rather than our partner list.
Most agencies competing for CMS work resell one platform. That platform is their partner revenue, their internal expertise, and their staffing model, so the recommendation is effectively made before discovery starts. We're one of fewer than twenty WordPress VIP Premier Partners worldwide, a Craft Verified Partner across Craft, Commerce, and Enterprise, and a Stripe Premier Partner, and we build on Sanity, Contentful, Storyblok, Webflow, Shopify, and Laravel besides. Having shipped production work on all of them is what lets the recommendation come out of your requirements, your editorial team, and the systems you already run.
Being platform agnostic is not the same as having no opinion. We have strong views about which system suits which problem, and you'll get ours directly and early. What you won't get is a team that arrived with the answer already chosen.
Two other things that don't change. The code, the documentation, and the hosting relationship stay in your name, and we build systems your team can run without us. And when the honest answer is that your platform is fine and the content model is what's broken, that's the answer you'll get, even though it's the smaller engagement.
Let's have a chat →
Questions we get asked before a CMS project starts.
Which CMS should we use? +
It depends on what you publish and who publishes it, so the honest answer is that we won't have one until discovery. Craft tends to win when the content model is complex and the editorial team wants fine control. WordPress VIP wins at enterprise publishing scale with security and compliance requirements attached. Sanity and Contentful make sense when the same content has to feed a website, an app, and something else at once. Webflow gives marketing teams the most independence and engineering the least room. We build on all of these and hold official partnerships with several, which is what lets the recommendation come out of your requirements, your team, and the systems you already run.
How long does a CMS migration take? +
Most of the ones we run land between four and nine months from discovery to launch. What moves that number is content volume, how many integrations are load-bearing, and how much of the current system was ever documented. A lift-and-shift with a clean content inventory can go faster. A migration carrying an undocumented CRM sync, a members-only area, and a six-thousand-item resource library will take longer, and we'd rather tell you that in the estimate than in month five.
What happens to our search rankings when we replatform? +
They hold if the redirect strategy is built during discovery, and they don't if it gets handled the week before launch. Our SEO team runs a full URL audit at the start, maps every existing URL to its destination, and preserves the internal linking and structured data that earned those rankings in the first place. After launch we watch crawl behavior, indexation, and position for a defined window rather than assuming it went fine. A dip of a few weeks is normal. A permanent loss is a redirect failure, and it's avoidable.
Will our marketing team actually be able to change pages afterward? +
That's the point of the build. Our team designs a catalog of modular components so column counts, layout variations, image treatments, and content slots are choices your editors make inside the CMS rather than tickets they file with a developer. We train your team and leave written documentation behind. And where the honest answer for a particular feature is that it will always need a developer, we'll say so up front instead of letting you discover it in month three.
What's the difference between headless and traditional, and do we need headless? +
A traditional CMS manages your content and renders your pages. A headless CMS manages the content and hands it off through an API to whatever renders it, which might be a website, a mobile app, or a screen in a store. Headless fits when several channels need the same content, or when the front end has performance and interaction requirements a template layer can't meet. It costs you something in preview, layout control, and editorial simplicity, which is why we recommend against it more often than we recommend it.
Can our team publish straight from Claude or ChatGPT? +
They can draft and build, and a person still publishes. We connect your CMS to the assistant your team already uses through MCP, scoped to the content types and fields you choose, so a page comes back assembled from your real components rather than pasted in as a blob of text. What lands is a draft inside your normal editorial workflow, carrying your permissions and your approval steps, with a record of what was generated and who signed off on it. Nothing reaches the live site until someone decides it should.
CMS work usually leads somewhere more specific.
If your CMS is the reason things are slow, tell us what's stuck.
Whether that's a full replatform with a deadline attached or a single question about whether the system you have is worth keeping, we'd like to hear it. We'll tell you what we'd do about it, what it would take, and whether we're the right people for the job.