CMS Migration Services
CMS migration without the traffic drop
Moving platforms should not cost you fifteen years of search equity, your order history, or a week of downtime. Vonnda migrates content, URLs, media and commerce data between systems, and treats your rankings as part of the payload rather than something to fix afterward.
- 160+
- E-Commerce sites launched
- 15 years
- Moving businesses between platforms
- 100%
- Of indexed URLs mapped before every launch
Start here
A migration is a risk exercise, not a build
The engineering in a replatform is rarely the hard part. Moving content between two systems is a solved problem, and any competent team can rebuild a template. What separates a migration that goes quietly from one that becomes a story is everything around the build: whether anybody mapped the URLs, whether the content model was designed or inherited, whether somebody was watching Search Console on the Monday after launch. That is why this page is organised the way it is. It tells you when moving is the right call and when it is not, what actually has to travel, how the work runs, the eight specific ways a migration loses traffic, and how long each size of project really takes. Those are the questions buyers ask us, in that order. If you take one thing from it: the migration is not the risky part. The unmapped redirect is.
When to move
Six signs your CMS is the problem
Publishing needs a developer
Every copy change becomes a ticket, and the marketing calendar runs at engineering speed.
Your content and your store disagree
Product data lives in two systems, both are edited, and neither is trusted.
Plugin debt
Forty plugins, three of them abandoned, and nobody is certain which ones are load-bearing.
Security is a monthly event
Patching, cleanup and reinfection have become a recurring line item instead of a non-event.
Speed is stuck
You have tried caching, images and a CDN, and Core Web Vitals still fail. The problem is architectural.
You have outgrown the roadmap
The license costs more each year and the features you need keep not arriving.
Migration paths
Where we move businesses from, and to
To Shopify
WooCommerce→Shopify
The most common E-Commerce move we run.
Our Shopify workMagento→Shopify
Off self-hosted, onto something your team can operate.
Our Shopify workSquarespace or Wix→Shopify
Outgrown the builder, and the export will not save you.
Our Shopify workCustom CMS→Shopify
Where most agencies say no.
Talk to usTo BigCommerce
WooCommerce→BigCommerce
When B2B pricing and multi-channel are the reason.
Our BigCommerce workMagento→BigCommerce
Away from self-hosted, keeping the catalogue complexity.
Our BigCommerce workTo headless
WordPress→Sanity + Next.js
Our own migration. Ask us anything.
How we use SanityDrupal→headless
Structured content out, a front end you own in.
How we use SanitySitecore→headless
Enterprise licensing traded for a stack you can hire for.
How we use SanityBoth directions
HubSpot CMS↔WordPress
We will tell you which one you want.
Our WordPress work
Scope
Content is the easy part
Content
Pages, posts, taxonomies, authors, revisions and every custom field, mapped into a real content model rather than dumped into rich text.
Media
The entire library, re-hosted and re-encoded, with alt text and captions preserved.
URLs and metadata
Titles, descriptions, canonicals, Open Graph tags, schema and hreflang, exported from the old site and diffed against the new one.
Commerce data
Products, variants, inventory, pricing tiers, orders, customers and subscription state.
Accounts
Users, roles and permissions, including password hashes where the destination platform supports them, so customers are not forced to reset.
Integrations
ERP, PIM, email, reviews, search, analytics and tag manager, rebuilt and verified in staging before anything goes live.
The engagement
Five phases, each with something you can hold
Audit and inventory
Full crawl of the existing site, content inventory, dependency and plugin list, integration map.
- You get: a scope document and a written risk register.
Content model
We design the schema in the new CMS and map every old field to a new one, including the ones nobody remembers creating.
- You get: a field mapping sheet, signed off before a line of code.
Build and scripted migration
Content moves by script, not by copy and paste, so it can be re-run on demand and your team keeps publishing on the old site until cutover.
- You get: a staging site with real content, refreshed whenever you ask.
SEO safety and QA
Redirect map built from the crawl, Search Console and analytics together. Metadata parity check, structured data rebuild, speed and accessibility pass.
- You get: a pre-launch QA report.
Launch and watch
Cutover in a scheduled window, redirects verified live, Search Console and rankings monitored daily.
- You get: written reports at seven and thirty days.
CMS migration and SEO
The eight ways a migration loses traffic, and what we do about each
Almost every horror story about CMS migration is really a story about one of these eight things going unhandled. None of them is difficult. All of them are boring, which is why they get skipped.
- URLs change and rankings go with them
- Every indexed URL mapped one to one from a full crawl plus Search Console export. Wildcards only where the structure genuinely changes.
- Pages lose their internal links
- Internal link graph compared old against new. Orphaned pages found before launch, not in month three.
- Metadata quietly drifts
- Titles, descriptions and canonicals exported pre-launch and diffed against the live site the day after cutover.
- Structured data disappears
- Schema rebuilt per template and validated. Product, article, breadcrumb and FAQ markup carried across.
- Crawl budget gets wasted
- Sitemaps regenerated and resubmitted, old sitemap paths redirected, robots.txt reviewed against the new structure.
- Images and alt text get lost
- Media re-hosted with alt text intact, served in next-gen formats with correct dimensions.
- Analytics goes dark at the worst moment
- Events, goals and conversion tracking rebuilt and verified in staging, so post-launch data is comparable to pre-launch.
- Nobody notices the drop for six weeks
- Rankings and organic sessions baselined before cutover, monitored daily for thirty days, reported in writing.
Time and budget
How long a CMS migration takes, honestly
Nobody else on this results page will tell you. Ranges assume content is reasonably structured and stakeholders can review inside a week. What moves the number is always the same three things: how many templates you really have, how clean the content is, and how many systems the site talks to.
| Project | Typical duration | What drives the number |
|---|---|---|
| Brochure siteunder 100 pages | 3 to 4 weeks | Template count, not page count. Ten pages on one template is a fast move. |
| Content site100 to 1,000 pages | 6 to 8 weeks | Editorial cleanup, custom fields, author and taxonomy structure. |
| E-Commerceup to 5,000 SKUs | 8 to 12 weeks | Product data quality, variant complexity, order history, payment and shipping reconfiguration. |
| Multi-store or B2Benterprise | 12 weeks + | ERP and PIM integrations, customer-specific pricing, multiple storefronts and locales. |
Want that number for your site?
The audit is a fixed, low-commitment first step and it ends in a real figure rather than a range.
Case study
We ran this migration on ourselves first
Vonnda moved its own site off WordPress to Sanity and Next.js. We built the content model as a block library first, ported the existing design onto it, verified traffic held, and only then shipped the redesign. Doing it in that order is the difference between knowing a migration went well and hoping it did. Every recommendation on this page comes from that project or from client work like it.
Questions
CMS migration questions we get every week
Will a CMS migration hurt our SEO?
It can, and that is entirely a function of preparation. Traffic loss after a migration is almost always caused by unmapped URLs, missing metadata or lost structured data, all of which are handled before launch rather than after. Expect a short settling period of one to three weeks while search engines recrawl, not a permanent decline.
How long does a CMS migration take?
Three to four weeks for a small brochure site, six to eight for a content site, eight to twelve for most E-Commerce, longer for multi-store or heavily integrated builds. Template count and content quality drive the number far more than page count does.
Can we keep publishing while the migration runs?
Yes. Because content moves by script rather than by hand, we can re-run the migration as often as needed. Your team keeps working in the old system until the cutover window, and we pull the final delta on launch day.
What happens to our old URLs?
Every indexed URL gets a 301 redirect to its closest equivalent, built from a full crawl plus your Search Console data so nothing that earns traffic gets missed. Redirects are verified live after cutover, not assumed.
Do we lose our order and customer history?
No. Orders, customers, subscription state and account credentials move with the rest of the payload wherever the destination platform supports it. Where a platform genuinely cannot accept historical orders, we tell you before the project starts and propose an archive instead.
Can you migrate from a custom or proprietary CMS?
Yes, and it is a large part of what we do. If there is no export, we extract from the database or crawl the rendered site and rebuild the structure from there. A missing export path changes the timeline, not the outcome.
Do you use migration plugins or write custom scripts?
Both, judged per project. Off-the-shelf tools are fine for straightforward content and terrible at custom fields, relationships and commerce data. We use them where they hold up and write scripts where they do not, which is most of the time.
What does a CMS migration cost?
It depends on template count, content volume and how many systems the site connects to. We scope in phases, so the audit is a fixed, low-commitment first step that produces a real number rather than a guess.
Tell us what you are on now, and what is not working
The first conversation is not a pitch. We will tell you whether a migration is the right move, and if it is not, what to fix instead.