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, so the answer is settled before the first call. We don't walk in with one. 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.
We've been building systems people still use since 1999.
We came out of the web standards movement, so semantic structure and accessible markup have been part of how we build from the beginning. Our content models get the same care, which is a big part of why our builds tend to outlast the designs that launched on them. Some of the sites we built are still running well more than a decade after launch.
Building content management systems since the web standards era.
WordPress VIP Premier Partner, verified Craft Enterprise Partner, Stripe Premier Services Partner, and official partner of Sanity, Contentful, Storyblok, Shopify, Webflow, and many more.
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 set up for launch day and hasn’t kept up since.
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.
When Kentico set an end-of-support date for Kentico 13 (the end of 2026), several organizations we work with heard it from us rather than from the agency that built their site. We scope migrations like these well ahead of the deadline, so your search rankings, historical content, and undocumented integrations all carry over to the new platform.
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. Our team inventories every one of them before the move and carries each one over to the new platform.
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 need to publish. Because we work across this many platforms, the recommendation can land on whichever system fits. When your current platform fits those needs, our team can rebuild the content model on the platform you already have.
02 CMS implementation WordPress VIP, Storyblok, Contentful, Craft, Sanity, Shopify, Webflow, and many more. +
We choose the platform project by project, starting from your technical and functional requirements: how your content is structured, which systems the site has to connect to, who publishes and how often, and what your developers will maintain after launch. We'll recommend the platform that fits those requirements and walk you through the reasoning before you commit to 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. Our team works out with you in discovery whether headless suits the project, based on your technical and functional requirements (such as how many channels share the content and what the front end has to do).
04 Replatforming and migrations Kentico, Drupal, Sitecore, Adobe Experience Manager, and proprietary systems. +
This is the largest part of our CMS practice. 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. If the current connections were never documented, our team runs a technical discovery pass first, so the integration estimate reflects how your systems connect today.
06 Author experience, governance, and training Component catalogs, editorial workflow, permissions, and documentation your team keeps. +
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.
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. We treat Core Web Vitals, crawl depth, internal linking, and sitemap generation as build requirements with acceptance criteria.
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. We build that structure into the content model from the start, so every entry carries it from launch day.
Accessibility and performance
We can build to the latest WCAG standards and Core Web Vitals from the first wireframe. 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.
Approvals that match how your team publishes
We build the publishing workflow around what your team decides is important. AI-created pages can arrive as drafts that go through the review and approval steps you choose, or publish directly where your team is comfortable with that. Your permissions apply in every case. Every change carries a record of what was generated, from which prompt, and who approved or published 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.
Here’s how a CMS engagement actually runs.
Our team gets your sign-off on the content model before the build begins.
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
We define the 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 is deployed and tested against the full live URL inventory, and the CRM, DAM, search, and commerce connections are rebuilt and verified against real data.
QA, launch, and knowledge transfer
Our team runs accessibility and performance testing, trains your editors, writes the documentation, and watches crawl behavior, indexation, and rankings for a defined window after launch rather than assuming they held.
Each phase is scoped and priced on its own, and you can stop after any of them. We’ll give you a timeline before we start, built from your content volume, your integrations, and what we learn about the current system in discovery.
Some examples.
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. We rolled it out in phases over several years and planned each one so it could be funded and shipped on its own.
Read the case study →
Wayside Publishing
Wayside, a world language textbook publisher, 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. One of Wayside's stakeholders put the brief plainly: the company had grown fivefold and needed a website that matched its new size.
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 serves 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 verified Craft Enterprise Partner, a Stripe Premier Services Partner, and an official partner of Sanity, Contentful, Storyblok, Shopify, Webflow, and many more. 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.
We'll give you our recommendation directly and early, once we've looked at your technical and functional requirements.
A few things don't change, whatever you hire us for. The code, the documentation, and the hosting relationship stay in your name, and we build systems your team can run without us.
Let's have a chat →
Questions we get asked before a CMS project starts.
Which CMS should we use? +
It depends on the project, so we won't recommend one until discovery. Our team looks at your technical and functional requirements (your content model, the systems the site has to connect to, how your editors work, and what your developers will maintain) and recommends the platform that fits those requirements. We're official partners of WordPress VIP, Storyblok, Contentful, Craft, Sanity, Shopify, Webflow, and many more.
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. Our estimate gives you a timeline for your project, built from what we find in discovery.
What happens to our search rankings when we replatform? +
We'll work hard to make sure your rankings carry over to the new site. 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. Rankings often dip for a few weeks after a launch, then come back.
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.
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. Whether headless fits depends on your technical and functional requirements (how many channels need the same content, and what your front end has to do), so we work that out in discovery, project by project.
Can our team publish straight from Claude or ChatGPT? +
Yes. 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. We build the workflow and approvals around what your team wants, so pages can go live straight from the assistant or pass through whatever review steps you set, with a record of what was generated and who approved or published it.
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 and what it would take.