← Back to blog
You already know the feeling. Everyone agrees the website needs to change. IT knows it. Marketing knows it. Somewhere in a shared drive there’s a deck from eighteen months ago making the case. And still, nobody wants to be the one who kicks it off.
Part of that hesitation is reasonable because a migration will touch SEO, it touches every page your sales team links to in a proposal, and it touches whatever fragile integration is holding your lead flow together. Getting it wrong is visible in a way that few marketing projects are.
But putting it off has a cost too, and it’s one we hear about constantly from marketing teams who waited: every month spent working around a site that fights you is a month of campaigns that launch late, or don’t launch at all.
Top takeaways
A migration has four real phases: audit and scope, content and data migration, build and QA, and launch and stabilize
The things that actually break are rarely the redesign. Instead, it’s the redirects, content that doesn’t map cleanly to a new data model, and scope creep that won’t stop
The teams that come out ahead treat the migration as a marketing project with technical dependencies
Why marketing teams put migrations off
The hesitation usually comes down to three things.
Fear of losing search rankings that took years to build
Not knowing how long the project will actually take, so it never fits into a quarter
An experience with an agency or vendor who scoped it wrong, went dark mid-project, or handed back a site nobody on the marketing team could actually use
That last one is more common than people admit out loud. If your team has been burned before, treating the next migration as a checklist rather than a leap of faith is the whole point of this piece.
The four phases of a migration
Every migration we’ve run, regardless of the CMS on either end, moves through the same four phases—the work inside each phase changes. The order doesn’t.
Audit and scope
This is where the project either gets scoped honestly or gets scoped optimistically, and optimism is what causes the timeline to slip in month three. A real audit means counting your actual content (not “a few hundred pages,” but an actual number), mapping every integration that touches the site, and documenting which stakeholders need to sign off before launch. Skipping this phase to get to the “fun part” faster is the single most common mistake we see.
Content and data migration
Moving content from an old system into a new one is rarely a clean copy-paste. Content models don’t match. A blog post in your old CMS might be a flat field of text; in the new one, it’s a dozen structured fields. This phase is where much of the hidden effort in a migration lives, and it’s the phase most teams underestimate when they’re quoting timelines.
Build and QA
The part everyone pictures when they hear “migration.” Templates get built, integrations get reconnected, and the new site gets tested against the old one page by page. Good QA here means checking more than whether a page loads. It means checking whether a marketer who’s never used the new CMS can actually publish something in it without having to call for help.
Launch and stabilize
Launch day isn’t the finish line. Redirects need to be verified against live traffic, not just tested in staging. Analytics need a few weeks of side-by-side comparison to catch tracking gaps before they become a reporting mystery in next quarter’s board deck. Budget real-time here. Teams that treat launch as “done” are usually the ones who call two months later asking why a page stopped ranking.
Testimonial
Experiences Shared by Our Clients
The teams that come out ahead treat the migration as a marketing project with technical dependencies, not a technical project marketing has to wait on.
Syed Hussain
What typically breaks during a migration
Ask anyone who’s been through a bad one, and the list of what actually went wrong is rarely “the new design looked worse.” It’s usually smaller and more specific than that.
Redirects that were built in staging but never checked against real, live traffic patterns
A content model that didn’t account for how editors actually use fields, so publishing something simple now takes three extra clicks
A feature everyone assumed was included, discovered missing two weeks before launch.
A timeline built around the build phase alone, with no real estimate for how long content migration would take
Search Engine Journal’s breakdown of post-migration traffic drops points to the same handful of culprits again and again: broken redirect chains, accidental noindex tags left over from staging, and lost page speed. None of these are exotic problems. They’re just the ones that get skipped when a team is moving fast.
How long does a migration actually take
The truest answer is that it depends on what you’re actually moving, and anyone who gives you a firm number before doing an audit is guessing.
What moves the timeline the most:
- How many integrations the current site depends on (a marketing site with a CRM, a listings feed, and an analytics stack takes longer than a brochure site)
- How much content exists and how well it’s structured today
- Whether the migration includes a redesign, or just a platform change underneath an existing design
What doesn’t move the needle as much as people assume: which specific headless CMS you land on. The bigger swing factor is almost always the content and integration side, not the platform itself.
What moves quickly, when it’s scoped well, is what happens after launch.
What to ask a partner before you start
Before you sign anything, a few questions tend to separate a partner who’s done this before from one who’s learning on your dime.
- How do you handle redirect mapping, and who verifies it after launch, not just in staging?
- What happens if content migration takes longer than expected? Is that built into the timeline or treated as a surprise?
- Will our marketing team be able to publish independently on day one, or is there a learning curve you haven’t mentioned yet?
- Who owns the site after launch if something breaks?
- Can you show me a marketing team, not just a technical stakeholder, who’d vouch for how this went?
Common questions about website migrations
Will a website migration hurt my SEO?
It can, if redirects and indexing aren’t handled carefully. It doesn’t have to. The risk comes from skipped steps, mainly incomplete redirect maps and content that gets restructured without a plan for preserving what already ranks, not from the act of migrating itself.
How long does a website migration take?
It depends primarily on how much content you have, how many integrations the site depends on, and whether a redesign is happening alongside the platform change. Anyone who quotes a firm timeline before auditing your actual content and integrations is skipping a step.
Do we need a developer on staff to maintain a site after migration?
Not necessarily. One of the main points of moving to a headless CMS is giving marketing the ability to publish and update pages without a developer in the loop for routine changes. You’ll still want technical support available for bigger changes, whether that’s in-house or a managed partner.
What’s the difference between a redesign and a replatform?
A redesign changes how the site looks. A replatform changes the underlying system, sometimes with a new design, sometimes without. They can happen together, but they don’t have to, and knowing which one you actually need changes the scope significantly.
contact us
