Oops, an error occurred! Request: 7d27de7b92056

For years, content migration was the silent budget killer in every CMS project. Anyone who has lived through a major relaunch or system replacement knows the picture: a dedicated migration team that, over weeks or months, exports from old databases, maps fields, untangles dependencies, renames media, repairs rich text and ends with a list of manual corrections. Editorial production stood still in the meantime, nerves were frayed, the budget was tied up longer than planned. And the day after go-live the first tickets came in anyway, with broken links.

That was the status quo. It isn't any more.

What content migration really costs, if you reckon honestly

In classic projects the cost falls into three areas that rarely appear together in a quote. First: the migration pipeline itself — export, transformation, import. Second: the rework — everything the pipeline doesn't cover because the old data has “grown organically”. Third: the editorial standstill, because during the transition either everything is maintained twice or nothing gets published.

Our experience from many migrations is that the first two land in proposals; the third almost never does. Yet it's often the most expensive. If an editorial team can't publish for eight weeks, the lost value is higher than the licence cost of the new system.

What has changed with AI agents and MCP

For some months now we've been building content migration on a completely different foundation. At its core sit two pieces: an AI agent that understands the existing site, and a Model Context Protocol server (MCP) on the new CMS that gives the agent structured write access. The agent reads the old site, extracts structure and content, decides on the basis of a previously defined mapping rule which new content element fits best, and writes the result directly into the new CMS. No CSV import, no transformation scripts, no intermediate staging.

That this is possible at all comes down to an architectural principle we've been pursuing consistently for months: the CMS itself has to be agent-ready. It has to expose its writing capabilities cleanly not just to editorial teams, but also to agents — with defined tools, validation, workspace context, roles and rollback. That is exactly what our AI-Ready CMS as a Service on TYPO3 delivers. The MCP isn't a shortcut around the editorial team but a second, equally strong write channel alongside it.

What this looks like in practice

We've just scaled the approach in a project of our own. We had 45 blog posts as Markdown drafts, with frontmatter, image prompts, alt texts and topic-fitting extras. An agent read them, interpreted them, picked the right page type for each post and then wrote them, structured, into two websites: blog hero with title and teaser, text & image with the body and a placeholder for the later hero image, CTA section with a topic-fitting button label, FAQ with five editorially curated questions, meta fields, Open Graph and Twitter Card data. All in one go, all traceable, all reversible — because every change sits in a workspace and only goes live on publication.

What used to be a multi-week project was an afternoon working session. What used to need a team, we did with two roles: the human, who sets the mapping rules and checks quality. The agent, who handles execution.

What this means for your organisation

The most important point first: this isn't a press-the-button promise. Quality assurance remains a human craft, and it has to. What has radically changed is the ratio of effort to result. The pipeline is no longer the project, it's a tool. The editorial team stays operational, because the migration runs in the background and sits invisibly in the workspace for now. And the tail of work after go-live shrinks, because the structure fits the new system from the start — instead of being “bent into shape” as before.

In practical terms that means: migrations we would once have planned for two to four months, we now deliver in days. Not because we apply less care, but because we delegate the bulk of the effort to a machine that works consistently, patiently and fully transparently.

A look at your migration before you sign.

Let's talk about your migration

If you're facing a CMS replacement or planning a major relaunch, an open conversation is worth having before you sign a classic migration proposal. We look at your existing site, discuss the target structure and tell you realistically which part of the work an agent can take on today and which you should keep deliberately in human hands. 30 minutes, no pitch.

Book a slot directly

Frequently asked questions

What clients ask us most often about content migration — answered openly.

Does that mean you simply move all old content automatically into the new system?+

No. The agent works against a mapping that we agree with you up front — which old area moves where, which fields are taken over, which are renamed. Anything that can't be mapped unambiguously lands in a review queue, not in the frontend. Full automation without human review is a risk that doesn't pay off in content migrations.

What happens to images and media?+

Images are referenced and, where needed, restructured — same file, new context. Where your old media management has gaps (missing alt text, chaotic file names, duplicate assets), the mapping decides whether we replace, regenerate or flag as TODO. A migration is often the best moment to finally get media metadata in order.

How do you ensure style consistency and quality?+

The agent works against a style guide profile that defines your brand — tone of voice, allowed terminology, typographic rules, CTA patterns. A human checks at the end. We build the style guide profile once and refine it with each production. That way the migration becomes a style polish, not a style regression.

Does this only work with TYPO3, or with other CMS as well?+

The prerequisite is an MCP server on the target CMS that exposes its write capabilities in a structured way. For TYPO3 we have it ready. For other CMS we build the MCP in a manageable timeframe — weeks rather than months — and it pays off within the migration project itself. What matters is that the MCP respects the same security and workspace rules as your editorial team.

How realistic is the time saving really?+

A factor of ten compared with classic migrations is the typical figure in our current projects. With particularly grown legacy systems the saving is smaller because the mapping itself becomes complex — there the gain is less about time and more about consistency. After an intake conversation we'll tell you realistically where your migration would land.