Home · Guide
CMS migration, without the rebuild.
A CMS migration is rarely a technology project. It is a content project wearing a technology budget: hundreds of pages, each of which must arrive intact, on time, at the same URL or a redirect from it, without the search rankings that took years to earn leaking away in a weekend. Most migrations run over because the work everyone underestimates is not moving the data — it is re-authoring the pages.
Why migrations fail
The pattern is consistent across the industry's own case studies: migrations exceed budgets and miss deadlines because of content chaos, not database exports. Legacy platforms hide structure inside templates and plugins; nobody has an accurate inventory of what exists; every page needs a human to re-place its content into the new system's components; and SEO preservation gets remembered at the end, when the redirect map is an afternoon's guesswork instead of a planned artefact.
The traditional answer is to make the project bigger: audits, spreadsheets, migration contractors, a quarter of a content team's year. The better answer is to make the re-authoring cheap.
The checklist that actually protects you
Whatever platform you are moving to — including ours — these are the phases that decide whether a migration protects or destroys value:
- Inventory reality, not the sitemap: crawl what is actually served, note what earns traffic and links, and decide deliberately what dies.
- Map URLs before anything moves: every retiring address gets a redirect target, validated as a whole graph — no chains, no loops.
- Preserve the metadata layer: titles, descriptions, canonicals and structured data are content, and they migrate with the page or the rankings do not.
- Re-author into the new system's structure rather than pasting HTML into it — a migration that imports markup imports every problem the markup had.
- Stage, compare, then cut over atomically — and know, before you flip, exactly how you flip back.
- Watch search console for weeks after, because the last redirect bug always surfaces in a crawler log, not a browser.
What migration looks like on Noice.work
Noice.work was built by people who do this for a living, and the platform carries the scars usefully. Give it the address of any page on the public web and it brings the page across as a draft: the read keeps what the page says — headings, prose, lists, calls to action — rather than its markup, copies the page's own images into your media library with provenance, and re-authors the content into your components and your brand. The shared header and footer come across the same way. What used to be the unbudgeted middle of every migration — a person re-placing content into components, page after page — becomes a supervised import you review.
The safety rails are the platform's normal ones, not migration specials. Imported pages arrive as drafts behind your review gates. Redirects are a single authoritative manifest with CSV import and whole-graph validation before an atomic commit — cycles, collisions and chains are refused before they are live. Publishing mints an immutable release, so the cutover is a pointer flip, and rolling back is the same flip in reverse. Sitemaps, robots directives, canonical tags and hreflang are first-class delivery features, not plugins to install afterwards.
The brand comes across too: the brand engine reads your existing site and generates the design system your migrated pages wear, so the new site looks like you on day one — verified against what was actually observed, not adapted from a template.
How long does it really take?
We are careful with this claim, because the honest answer depends on how much of your estate deserves to survive the move. What we can say from doing it: bringing a page across is minutes, not hours; bringing a section across is an afternoon of review, not a sprint; and the brand arrives in under ten minutes when your site's firewall permits the capture — roughly half of enterprise firewalls refuse automated reads, in which case the brand is built in the workbench with our help instead. The months in a traditional migration plan are mostly re-authoring labour, and that is precisely the part the agent does.
Questions people ask
Will we lose our search rankings?
A migration only loses rankings when URLs change without redirects, metadata is dropped, or content quality degrades in the move. All three are addressable: Noice.work re-authors content rather than truncating it, carries per-page titles, descriptions and canonicals as first-class fields, and validates the whole redirect graph before it goes live.
Can you migrate from any CMS?
The importer reads served pages, not databases — so it works against anything that renders public HTML: WordPress, AEM, Sitecore, Drupal, Webflow, a static site, or a platform nobody remembers the login for. Content behind authentication needs an export instead, which we handle case by case.
What about our thousands of PDFs and documents?
Documents move into the content library, where they become retrieval grounding for future pages — the agent composes new content grounded in what your documents actually say, with sources attached.
Do we have to migrate everything at once?
No. Because publishing has no build step, a section-by-section migration is natural: bring a section across, review it, publish it, repoint those URLs, and keep the rest where it is until its turn.