services
Happy Cog has been replatforming enterprise sites since 1999, and we hold official partnerships with several of the platforms people move to, but we'll still say so when the move isn't worth making. We plan every migration so your search traffic, your integrations, and twenty years of archived content are still there after launch.
Migrating sites since before most of the platforms people are leaving today existed.
Between WordPress VIP, Storyblok, Contentful, Webflow, Craft, Shopify, and many others. We're a WordPress VIP Premier Partner, a Storyblok Certified Partner, a Contentful Solution Partner, a Certified Webflow Partner, a Craft Verified Partner, and a Stripe Premier Partner.
Alongside twenty-year editorial archives, multi-brand product catalogs, and gated member areas nobody had documented.
A migration is the one project where the requirements already exist, because the existing site is the spec. The work is reading that spec accurately, which is harder than it sounds when the system has been running for a decade and the people who configured it have moved on. We've inherited enough of these to know which parts of a site need a closer look.
Kentico Xperience 13 loses support at the end of 2026, Drupal 7 already has, and Sitecore and Adobe Experience Manager licensing keeps climbing whether or not you're getting more out of it. Several organizations we work with heard about their own end-of-support date from us before they heard it from the agency that built the site, which turned a planned project into an emergency.
The dealer locator, the gated member library, the recipe archive, the nightly CRM sync, and the thing that emails the sales team when a form gets filled in were all built by people who have since left. None of it is in a requirements document. We've opened enough of these systems to know that the integration inventory is where migration estimates go wrong, which is why we run a technical discovery pass before we'll put a number on that part of the work.
A redirect map built the week before launch is the most common way a replatform loses money. Every URL that changes needs a destination, the internal links need to point at final URLs instead of through a redirect hop, and the structured data that earned those rankings has to come across with the content. Rankings usually dip for a few weeks after any launch and then recover. When they don't recover, the cause is almost always a redirect or metadata failure, and it's avoidable.
Plenty of clients bring us in for the assessment alone, or for the search and redirect work alongside an agency that's handling the build. We scope and price each area on its own.
Our team audits the system you have now, covering every content type, taxonomy, integration, editorial workflow, and access rule, then maps that against what your people need to publish. You get a recommendation with the trade-offs written down, plus a sequenced roadmap you can fund one phase at a time. A fair number of our assessments come back as "stay where you are and fix the content model," which costs us a larger engagement but is the right answer to give you. Where the decision is close, we scope both options with hours attached to each, so you can choose based on cost instead of on a vendor demo.
Our engineers build the migration per content type, because the right approach for thousands of evergreen articles isn't the right approach for a few hundred product pages with variant complexity. We run the migration repeatedly into a staging environment so your editors can see real content in the new system months before launch, and the dry runs double as QA. Where the old system exports badly, we work from whatever the platform gives us, which sometimes means combining a raw export with the platform's own API to fill the gaps.
Our SEO team runs the URL audit at the start of discovery, maps every existing URL to its destination, and uses GA4 and Search Console to quantify the ranking exposure of anything being consolidated or retired before you decide. Our default is that URLs don't change, because fewer changes mean less risk and more equity preserved. We also audit the redirects you already have, where broken chains and loops from a previous migration are common. After launch we watch crawl behavior, indexation, and position for a defined window.
The same structural work decides whether answer engines can quote you. Schema markup, semantic hierarchy, and clean heading structure are what ChatGPT, Perplexity, Gemini, and Google's AI Overviews rely on, and we confirm during the build that GPTBot, ClaudeBot, and PerplexityBot can reach the content you want surfaced, since many sites block them without meaning to.
We keep the systems that already work and rebuild the connections into the new platform. Our team inventories the integrations in discovery, and where the current connectivity was never documented we run a technical pass before scoping, so the estimate reflects the system as it exists. We'll also flag early when something in the current stack should be replaced instead of reconnected, usually because the new platform already does that job natively.
Not every replatform is a CMS replatform. Our engineers have moved product catalogs with hundreds of thousands of items between commerce platforms such as Adobe Commerce, Shopify, and BigCommerce, with variant structure, merchandising relationships, and customer accounts intact. We've done the same for resource libraries and member directories that behave like catalogs even when nothing is for sale. We're a Shopify Partner and a Stripe Premier Partner, and when the payment provider changes as part of the move, we carry saved payment methods and active subscriptions across so your customers don't have to re-enter anything.
Our team builds the new hosting environment, whether that's WordPress VIP, your own Azure or AWS tenant, or a Cloudflare Worker running a decoupled front end, and we write the cutover runbook with the rollback path in it. We're an AWS Select Consulting Partner and a Cloudflare partner with accredited Cloudflare configuration engineers on staff, and we recommend Cloudflare as the CDN and WAF on most projects. The hosting relationship, the repositories, and the documentation stay in your name throughout, so you own the whole thing.
Analytics is the thing most likely to break silently. Our analytics team rebuilds GA4 and GTM against the new templates, re-tests the dataLayer events your reporting depends on, and confirms consent management still behaves the way your legal team signed off on. We do this in staging, so the first week of post-launch data is trustworthy enough to tell you whether the migration worked.
We design the new content model and component catalog around the way your team publishes, then train them and create written documentation for you. This is also where we simplify, since most legacy systems accumulate widgets almost nobody uses, and carrying every one of them forward adds cost without adding value.
These are a sample of the migrations we take on. The full list is longer, and we're glad to walk you through the ones closest to your situation.
A B2B publishing group moving a portfolio of financial and professional titles, including the paywall, the registration flow, the lead generation forms, and the audience data platform underneath them.
A financial services firm moving to a headless architecture with a Next.js front end on Cloudflare Workers, combined with a corporate domain change, which meant the redirect map had to survive a platform move and a domain move at the same time.
A large SaaS company whose marketing team wanted to ship pages on a complex, multilingual site without filing tickets.
A multinational restaurant brand that asked us to consolidate their marketing and ordering sites.
A management consultancy where we scoped the Sitecore upgrade and the replatform side by side, with hours attached to each, and then ran the migration once the numbers made the decision easy.
A global commercial foodservice manufacturer with more than a dozen brand domains, consolidated onto one WordPress multisite installation with a shared component catalog and the Bynder, Salesforce, and HubSpot connections carried across.
We start with a content inventory, which guides all the other work.
Our team documents every content type, integration, workflow, and access rule in the current system, and our SEO team runs the full URL audit in this same phase. We create a migration plan and a redirect strategy.
Our team designs the new content model, the component catalog, the integration map, and the hosting architecture.
We build the migration per content type and run it into staging repeatedly, so your editors are working in the real system with real content well before launch. We build and test the redirects against the full live URL inventory in this phase, months ahead of cutover.
Our team moves DNS, puts the redirect map live, points the integrations at the new system, and creates a rollback plan in case something goes wrong. We write the runbook in advance and walk your team through it, so everyone involved understands the sequence before the day arrives.
We monitor crawl behavior, indexation, rankings, analytics, and form submissions for a defined period, with someone on our team accountable for fixing what turns up.
Most agencies bidding on replatform work resell one system. 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 Storyblok Certified Partner, a Contentful Solution Partner, a Certified Webflow Partner, a Shopify Partner, an Adobe Digital Experience Partner, a Craft Verified Partner, a Stripe Premier Partner, and a Sanity Partner, and we have expertise with many more (including Sitecore).
We still have opinions about which system suits which problem, and we'll share them along with our reasoning.
Sometimes the answer is that you shouldn't move. When the platform is fine and the content model is broken, we'll tell you that even if it means a smaller engagement for us.
Most replatforms we run take four to nine months from discovery to launch. Content volume, the number of integrations, and how well the current system is documented all affect that number. A lift-and-shift with a clean content inventory can go faster. A migration with an undocumented CRM sync, a members-only area, and a large resource library will take longer.
We can move quickly when needed. If you're coming up on a deadline (such as Kentico Xperience 13 losing support), get in touch ASAP and we'll figure out a plan that works for you.
We work hard to keep any drop small, and rankings often improve after launch because the new site performs better. 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. Our default is to keep URLs unchanged wherever we can, since every change adds risk. After launch we watch crawl behavior, indexation, and rankings for a set period. A short dip is normal. If rankings don't recover, we investigate the cause and work with you to fix it.
We'll know after the assessment. When your marketing team can't change a two-column layout without filing a ticket, that's usually a content model problem. A replatform is clearly the right call when support is ending, when licensing costs have outgrown the value you get, when the architecture can't support what you need to publish next, or when the system is so customized that any redesign means a rebuild anyway.
It depends on what you publish and who publishes it, so we won't have a recommendation until we learn more. Each CMS has different strengths and hosting models, which is why we work with so many of them.
We'll inventory them during discovery and rebuild them in the new platform. If the current connections were never documented, we'll run a technical pass before scoping. Our engineers work regularly with Salesforce, HubSpot, Bynder, Algolia, Auth0, Stripe, and custom ERP systems. We'll also flag when something should be replaced instead of reconnected, which comes up most often with search, paywalls, and marketing automation tools.
No, not if you don't want to. Most sites we inherit carry years of pages nobody reads, and a migration is the cheapest opportunity you'll get to retire them. We rank existing content by traffic, rankings, and inbound links, then recommend what to migrate, what to consolidate, and what to retire (with redirects for anything that still has link equity). You'll make the final call with the data in front of you.
Yes. A platform move that carries the existing design across is faster, cheaper, and lower risk than doing both at once, and it lets you make design decisions later on a system that can support them. The case for combining them is that a redesign means rebuilding templates anyway, so combining them means you only pay for that once. We'll talk through which makes sense for your situation.
Whether that's an end-of-support date you didn't choose, a platform that stopped fitting, or a question about whether the move is worth making at all, 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.
