Thousands of pages migrated without copy-pasting: how we are rewriting Orisha's content in 4 languages with Claude Code

Problem

Dozens of WordPress sites inherited from Orisha acquisitions, with no structure in common, to be merged into a single multilingual Webflow site without losing years of search rankings.

Vydera Solution

Unify all of it on a single platform in four languages, with content rewritten, not copied over, and without months of copy-pasting.

  • 800
    Blog articles imported into the CMS
  • 3,000+
    Internal links updated, 0 broken
  • 600+
    SEO checks (209 pages across 3 languages)
  • 4
    Languages delivered (FR, EN, ES, NL)
Table of contents

The same results for your brand?

Audit delivered in 5 days. Without commitment.

Book a call

Orisha is a European business software publisher: 2,300 employees, 50,000 customers, seven markets, from retail to healthcare, from construction to food processing.

Through its acquisitions, the group had accumulated dozens of independent WordPress sites, one per business unit, on as many subdomains. The project, run with Digidop for design and Webflow Enterprise architecture: bring everything together on a single platform, organised by business unit, in four languages. Our part: the content. This case covers the first wave: two business units, Commerce and Construction, and the Group site.

The challenge: dozens of sites, no common template

First thing we saw on opening the old sites: they looked nothing alike. Hundreds of product, activity and service pages, built by different teams, in different countries, with no shared structure.

On top of that sat years of blog articles encoded in bespoke WordPress formats, and internal links pointing to URLs that were about to disappear.

Redoing all of that by hand meant months of copy-pasting and mistakes on every page. Copy-pasting would have relocated the mess instead of fixing it. And the point was not to replicate the existing sites, but to unify them.

Our approach: an engine, not copy-pasting

We turned the problem around. Rather than moving pages one by one, we built a migration engine driven by Claude Code: it reads each old site, extracts the content, rewrites it into the target structure, feeds it back into the CMS, translates it and restores the links.

Prove, have a human validate, then scale

One rule framed the whole project. For every content type:

  • we migrate five to seven sample pages first;
  • a human opens them in the Webflow editor;
  • we fix what only the eye catches;
  • only then does the full batch go out.

Why the human step? An automated check confirms that content is stored, not that it renders correctly. Most problems only surface when a page is opened. That discipline is why no batch broke when we moved to volume.

Our Claude Code setup

Reliability comes from how the project is configured, before the first prompt. Claude Code works on a structured knowledge base, designed so that it always has the right context within reach.

A repository organised as a knowledge base

An index at the root, one folder per business unit, a clean split between what the teams know about their market and the migration machinery.

  • CLAUDE.mdindex and update rules
  • bu-1-groupe/groupe.md (facts) + pages.md (generated)
  • bu-2-commerce/commerce.md + pages.md + csv/
  • bu-3-construction/construction.md + pages.md
  • app-webflow/the engine: scripts/, bridge/, extension/, reference.md (generated)

The index does not hold the knowledge, it points to it. When Claude Code works on a Construction page, it opens the Construction context, not the Commerce one.

Three principles hold it together:

  • Generated files, never hand-edited. The real Webflow identifiers (the site, the 4 languages, the 23 collections, the contact pages per business unit) live in a reference file regenerated by script. The AI never guesses an identifier, it reads the up-to-date reference.
  • A dated logbook. Every technical discovery is recorded with its proof: "draft status does not remove a page from the live site", "space calls 300 ms apart and retry, otherwise the API throttles". That log stops us making the same mistake twice, from one week to the next or from one agent to another.
  • In-house tools. All French writing goes through a dedicated reviewer that hunts down AI writing tics.

Two routes, one bridge

Webflow exposes two APIs that must not be confused:

  • the headless route (REST API) writes the CMS, SEO, Open Graph, translations and links, with no browser;
  • the visual route (custom Webflow extension and local service) writes the hard-coded French text inside components, which the REST API refuses to edit.

A bridge connects the two: for each page, a writing plan generated on the REST side, applied on the visual editor side.

Guardrails, not blind automation

Every write is re-checked by a separate read-back, because the API's immediate response can lie. Every link is tested live before it is written.

On a fix for translated links, the engine found 135 targets, then tested them one by one.

135
targets found by the engine
9
actually responded
9 valid targets, tested live 126 pages never published in that language

Without that check, we would have replaced 126 broken links with 126 new ones.

Rewriting the content, not just moving it

Unifying the structure was not enough. We reduced hundreds of heterogeneous pages to a handful of templates: activity, service, software product, landing, training. Each template has its own program. The 12 activity pages, for instance, share the same layout down to the order of their sections.

Where a classic migration transfers text as-is, we rewrote it from its sources: the old live page, a product PDF, a market brief. A subagent took charge of each page, read the existing version and drafted the new one. On one batch, that rewriting mobilised 54 agents in parallel. Two non-negotiable rules:

  • Zero invention. Every figure, every sentence comes from the source. A page that only existed in German on the old site stays in German. A page with no statistics gets fewer callouts, not invented numbers.
  • No empty sections. When a template had a section with no source, two options: generic brand-level content, or hiding the section, rather than inventing.

The CMS: bringing back years of blog posts

The CMS was the densest part of the project. Years of articles had to be brought back, 800 across three business units: 478 for Commerce, 270 for Construction, about fifty for the Group.

Exported WordPress content is not clean text. We found about thirty bespoke block types, in proprietary formats. The engine recognises each one, and salvages the text of unknown blocks so nothing is lost.

The costliest issue was not writing but rendering. Webflow accepts almost anything on import, then parses it at render time: an article stored without error could break the page when opened. We isolated those cases one by one and adjusted the engine to produce exactly the format the editor expects.

Bringing the articles back was not enough, they had to be navigable. We rebuilt the taxonomy that structures the CMS, 120+ entries (sectors, areas of expertise, solutions, add-ons, types), linked to each other and to the articles. Then we categorised the articles on a simple rule: deterministic wherever possible, AI only where needed. Sector and type were derived from the old WordPress categories, with no AI, on 100% of articles. Areas of expertise, missing from the source data, were classified by AI.

The instruction was strict: never force a wrong category just to fill a field. The result: 123 articles deliberately left uncategorised, and zero cross-market mis-assignment across the 748 articles checked.

Preserving search rankings

A badly run migration wipes out years of SEO. Three workstreams prevented that:

  • Internal linking. 3,000+ internal links updated to point at the right Webflow pages. Without trusting the sitemap: some pages are listed there but return a 404. Every target was tested live before the redirect was written.
  • Meta tags. Titles and descriptions audited across 209 pages in all three languages, over 600 checks in total. The audit revealed 17 Construction pages showing an "Orisha Commerce" title copied from another business unit, and 84 pages were rewritten in English and Spanish.
  • A single source of truth. Slugs, URLs and structure are driven by mapping spreadsheets supplied by the teams, which the engine reads to build each target URL. Where the source is incomplete, we cross-check it against the real page before writing anything.

Four languages, two levels of translation

The target site exists in French, English, Spanish and Dutch. The engine handles the same content in several versions, and only writes the foreign ones, never touching the original French.

We drew a line between two levels of translation. Plain translation renders the French correctly: right about 80% of the time. Advanced translation goes and finds the terminology the client actually uses on their old pages, language by language, and uses it as the reference. We built a glossary from the live sites, and the difference is stark:

What a correct translation produces
What the brand actually says
Dutch
Plain translation"clienteling", left untranslated
Advanced translationklantenbinding, the word the Dutch site uses
English
Plain translation"self-service checkouts"
Advanced translationSelf-Checkout, the in-house term
Spanish
Plain translation"punto de venta"
Advanced translationTPV, actual Spanish usage
English
Plain translation"employees"
Advanced translationassociates, the retail industry word

No machine translation guesses the right-hand column. You have to go and read it on the client's existing pages, language by language.

That is what separates a correct translation from text the brand could have written itself.

First wave results

  • 800 blog articles imported into the CMS, across Commerce, Construction and Group;
  • 748 articles (Commerce and Construction) translated into English and Spanish: titles, descriptions, breadcrumbs and SEO;
  • 3,000+ internal links updated, 0 broken links;
  • 120+ taxonomy entries rebuilt and linked, in 4 languages;
  • 209 pages audited and corrected for SEO title and meta, over 600 checks across the 3 languages;
  • 200+ pages given a share image in each brand's colours;
  • the Commerce business unit localised at 100%, with no leftover French.

Key takeaways

1. Migrating is not transferring. At this volume, the work is putting the content back in order: a unified structure, text rewritten from its source rather than copied.

2. The CMS is the real work. Static pages are visible, the blog and its taxonomy are not. Yet that is where the volume, the awkward edge cases and the substance sit.

3. Setup beats prompting. What makes an AI migration reliable comes down to four things: a structured repository, references that do not lie, a log of mistakes, and the rule "prove, validate, scale".

Project run with Digidop (art direction, UX/UI, Webflow Enterprise architecture) and the teams at Orisha and Webflow.

  • How long does a WordPress to Webflow migration take?

    It depends on the volume and the state of the source content. At Orisha, the first wave (three scopes, 800 articles and hundreds of pages) took 6 weeks. Data entry is automated. The time goes elsewhere: understanding the legacy formats, and having a human validate each page type before the volume goes out.

  • Is an AI-driven content migration reliable in production?

    Yes, provided there is a method. What makes an AI migration reliable is the setup far more than the model: a structured repository, identifiers read from a generated reference rather than guessed, a dated log of mistakes, and above all the rule prove, have a human validate, then scale. At Orisha, every page type was first migrated on five to seven samples, opened by a human in the editor, before the full batch. No batch broke when we moved to volume.

  • How do you avoid losing search rankings during a migration?

    Three workstreams. Internal linking: every historical internal link must point to the right new page, and every target must be tested live, because a sitemap lists pages that return a 404. Meta tags: titles and descriptions audited page by page, in each language. A single source of truth: target URLs built from the mapping spreadsheets supplied by the teams, never improvised. At Orisha, 3,000 internal links were updated without a single broken one.

  • What happens to WordPress blog articles in Webflow?

    They are imported into the CMS, but there is work to do first. A WordPress export contains bespoke blocks in proprietary formats: we found about thirty at Orisha. The engine recognises each one and salvages the text of unknown blocks so nothing is lost. The costliest part is rendering: Webflow accepts almost anything on import then parses it at render time, and an article stored without error can break the page when opened.

  • Can a multilingual site be migrated to Webflow?

    Yes. Webflow handles the same content in several language versions, and the API lets you write the foreign versions without touching the original language. The difficulty is editorial before it is technical: a correct translation is right about 80% of the time. The rest comes down to the terminology the brand actually uses, which you have to go and read on the old pages, language by language. At Orisha, the site ships in four languages: French, English, Spanish and Dutch.