Stuff from the Loft came to us with a challenge that sounds straightforward on paper: build a modern website that reflects the brand, and migrate a large WordPress blog archive into Webflow without losing functionality, discoverability, or readership. Two streams running in parallel, each with its own complexity, and both needing to land at the same time.

It was a proper build, not a theme swap. And the blog migration in particular turned out to be the kind of work that rewards process and punishes assumptions. Here's what we learned, what we changed, and what we'd tell you if you're planning something similar.

Blog migrations are never "just content"

There's a reason so many CMS migrations stall or go sideways. The content itself is rarely the hard part. What makes a blog archive functional is everything around it: the categories and tagging structures that help readers find what they're looking for, the search and pagination that keep them browsing, the commenting and sharing features that drive engagement, and the SEO equity that took years to build through backlinks, indexed URLs, and domain authority.

Lose any of that during the move and you're not migrating. You're starting over with a fresh site that happens to have old posts on it. The difference between those two outcomes is planning, and it's a distinction that doesn't get enough attention in the early stages of most migration projects.

We migrated the full WordPress archive into Webflow CMS and redirected traffic from the legacy blog domain to the new one, keeping everything functional and discoverable. That outcome was the result of methodical preparation across content mapping, URL redirect strategy, and platform-level decisions that were locked in before any build work began.

Start with outcomes, not tools

It's one of the most common mistakes we see on builds like this, and we've been guilty of it ourselves. You pick the CMS first because you know it well or because the client has a preference, and then you spend the rest of the project bending the platform to fit requirements it was never properly evaluated against.

The better approach is to define the outcomes you need first, then choose the stack that supports them. On this project, the win was not "using Webflow." It was pushing Webflow to deliver the experience the brand actually needed, which meant understanding what that experience looked like before writing a single line of code or choosing a single tool.

If you're evaluating platforms for a migration, start by listing what your content needs to do, not where it needs to live. How does search need to work? What does the archive structure look like? Are there custom post types, dynamic filtering requirements, or integrations that the new platform needs to support natively? Those answers should drive the technology decision, not the other way around.

This is a principle that applies well beyond CMS choices. Any time you lead with the tool rather than the problem, you risk building something that's technically complete but functionally misaligned. We've seen teams pick a headless CMS because it sounded modern, only to realise their content editors needed visual control that the setup couldn't provide. The platform should serve the strategy, never the reverse.

Ambiguity in discovery becomes cost in delivery

Every migration has unknowns. That's expected. The problem is not the unknowns themselves but how late they get addressed. On complex builds, ambiguity does not resolve itself quietly in the background. It compounds. A vague assumption in the discovery phase becomes a technical constraint in build, which becomes a scope change in testing, which becomes a difficult conversation about timelines and budget.

We now flag unknowns earlier and resolve them before anyone commits to a technical approach. That means asking harder questions in discovery, even when the answers slow things down, because the alternative is dealing with those same questions later when they're ten times more expensive to answer.

For complicated sections of a build, especially when a solo developer is carrying the work, we also add deliberate review checkpoints. Not status meetings. Actual technical reviews where someone else looks at the approach, pressure-tests the assumptions, and catches problems before they compound. It's a small investment of time that pays for itself many times over.

It's worth saying that this isn't about being cautious for the sake of it. Speed matters, and we're not interested in slowing projects down with unnecessary process. But there's a difference between moving fast with clarity and moving fast with gaps. The first one gets you to launch. The second one gets you to a conversation about scope creep.

Scope should reflect reality, not optimism

One of the biggest shifts we made after this project was in how we audit existing sites before scoping a migration. Previously, our upfront analysis was solid but not deep enough to catch the edge cases that inevitably surface during build. Content types that don't map cleanly to the new CMS. URL structures that need custom redirect logic. Third-party integrations that were buried in the WordPress setup and only revealed themselves when we started pulling things apart.

We now run a more detailed technical audit before writing a single line of scope. This means the estimate reflects what the project actually involves, which protects both us and the client from the kind of mid-project surprises that erode trust and blow timelines.

If you're on the client side of a migration, this is worth pushing for. Ask your agency what their audit process looks like. Ask what they're checking beyond page count and content volume. The depth of that answer will tell you a lot about whether the scope you're being quoted is grounded in reality or built on optimism.

A good audit should cover content types, URL structures, redirect requirements, third-party dependencies, custom functionality, SEO baseline metrics, and any platform-specific features that won't carry over automatically. If your agency can't walk you through what they checked and what they found, the scope probably has holes.

Make it easy to migrate from day one

This one sounds like admin, but it's engineering. File naming conventions, image sizes, content formats, asset organisation: set these rules early and you remove an entire category of problems later in the project. Spaces and special characters in filenames, inconsistent image dimensions, content that doesn't conform to the new CMS structure. These things come back to haunt you, usually at the worst possible moment when you're trying to get through final QA.

We now create client asset guidelines at the start of every migration project. Not as a nice-to-have, but as a deliverable. "Make it easy to migrate" is a project requirement, and treating it that way means the team spends its time solving interesting problems instead of cleaning up preventable ones.

This applies to content as well as assets. If you're moving hundreds of blog posts, for example, having a consistent content structure across those posts makes the migration significantly smoother. Posts that follow a predictable format can be batch-processed. Posts that are all slightly different in structure need individual attention, and that individual attention has a cost that most project timelines don't account for.

Structured feedback changes everything

If there's one operational change that made the biggest difference to how smoothly this project ran, it was how we handled feedback. Long email chains are where requirements go to die. Amendments scattered across threads and drip-fed one change at a time create a kind of low-level chaos that's hard to see in the moment but obvious in hindsight. Every isolated change request carries a context-switching cost, and when those requests arrive without structure or batching, the rework adds up fast.

We now consolidate all feedback in one place, in one format, delivered in batches. It keeps momentum, reduces rework, and means nothing gets lost between rounds. If you're working with any agency on a complex build, agree on a feedback format early. It's one of the simplest things you can do to keep the project moving and the relationship healthy.

A feedback format doesn't need to be complicated. A shared spreadsheet or a simple document that lists the page, the element, the change, and the priority is enough. The point is that everyone knows where to look, nothing lives in someone's inbox, and the development team can plan their work around complete rounds rather than reacting to one-off messages throughout the day.

Reuse what works, and document why it worked

The blog functionality on this build, including search, comments, and pagination patterns, worked well. The Finsweet tooling helped extend what Webflow could do natively, and the case study layouts landed exactly as intended. Good collaboration and short, focused meetings kept decisions moving throughout, while having design and dev working together from the start made fast iteration possible.

These aren't extras or nice-to-haves. They're the baseline for how complex builds should run. But they're also easy to lose if you don't actively carry them forward. We now document what worked on each project, not just in a retrospective that lives in a folder nobody opens, but in reusable patterns and approaches that feed directly into the next build. The goal is compound improvement: every project should benefit from the lessons of the one before it.

There's a broader principle at work here too. Agencies that treat every project as a fresh start are doing themselves and their clients a disservice. The value of working with an experienced team isn't just what they know; it's what they've already solved. When good patterns become part of the process rather than staying trapped in individual project memories, everything gets faster, tighter, and more reliable.

The takeaway

The best builds are not the prettiest comps. They're the projects where discovery is honest, feedback is structured, and the migration plan is treated like product work rather than a checkbox on a project timeline.

If you're planning a CMS move in 2026, treat it like a platform change, not a redesign. The content, the SEO equity, the functionality your audience relies on: that's the product. The new site is just where it lives. Get the migration right and everything else follows. Get it wrong and the redesign, no matter how good it looks, won't deliver the results you're expecting.

And if you're early in the process and still working out what the move actually involves, that's exactly the right time to talk to someone who's done it before. Not after you've picked a platform. Not after you've written the brief. Before any of that, while the decisions that shape the entire project are still open.