Replatforming is moving a website onto a different CMS, host or architecture. It usually happens when the current setup has become slow, expensive or difficult to change. The move itself is mostly predictable work. What causes trouble is everything the old site was doing that nobody listed, like a redirect added years ago, a feed another system reads overnight, or a tracking tag in a template that gets replaced.
I've written PHP since 2006 and built on WordPress since 2007. The largest move I've led brought a publisher's eight high-traffic sites in-house, onto infrastructure the publisher ran itself.
When it's worth doing
The usual reasons for moving are:
- Releases involve enough handoffs that small fixes take days to go live.
- Hosting costs are rising faster than traffic.
- The site is so loaded with plugins and workarounds that each change breaks something else.
- Editors have to fight the CMS to get anything published.
For the publisher, it was about owning its release process and bringing hosting costs back in line with traffic. If the platform itself isn't the problem, moving is a lot of risk for not much gain. A performance pass or a tidy-up of the current site is sometimes the better answer, and an audit is the way to find out which.
What goes wrong
The failures tend to be the same few:
- Old URLs return 404s, or all redirect to the homepage.
- Canonical tags point at the wrong pages, so Google doesn't index the right ones.
- The sitemap lists only part of the site.
- Analytics isn't set up on the new site, so nobody can see how much traffic has been lost or where from.
- Forms, feeds and scheduled jobs the old platform handled stop working, and nobody notices until someone complains.
Several of these happened to Chimes Music, an online instrument retailer I worked with after their migration. They'd lost much of their non-brand search traffic. The new platform capped the sitemap, so a chunk of the catalogue wasn't being submitted, and the canonical tags were stopping pages from being indexed. With no working analytics they couldn't measure any of it. We set up GA4 first, so there was a baseline to measure from, then found the causes and planned the fixes in order of impact.
How I approach it
- Audit the current site. I list every URL, template, integration and scheduled job, and record current traffic, rankings and page speed to compare against afterwards.
- Agree what the new platform has to do better. Then check that the one you're considering actually does it.
- Map every old URL to its new address with a permanent redirect.
- Build the new site alongside the old one, with automated deployment set up early. On the publisher project, a deployment now takes under four minutes.
- Test before launch. Redirects, canonical tags, sitemap, structured data and tracking are all checked against the URL map.
- Launch at a quiet time, with a way to roll back.
- Watch it afterwards. For the following weeks I keep an eye on Search Console, analytics and the error logs, and fix anything that turns up.
Working together
If you haven't decided whether to move yet, an Architecture Audit is a fixed-fee look at your current platform, what a move would involve and what it would risk, ending in a recommendation. If you have decided, Project Delivery covers the migration from the plan to the live site.