Decisions that still hold up in five years.

Choosing a content management system decides less about how a website looks than about how an editorial team will work for years to come. Systems that shine in a demo often fail in daily use over the unspectacular things: approval workflows, connections to specialist systems, multilingual sites, or the fact that every new page type costs development time again.

We accompany the selection from gathering requirements through to a reasoned decision. Together with everyone involved — editorial, IT, the departments — we capture what the target system has to do, translate that into criteria that can actually be tested, and compare the candidate systems against them. What you end up with is a decision you can still justify two years later, not just the name of the vendor with the best presentation.

Just as common is the question of operating model: classic, headless or hybrid. We have designed target architectures that serve both — familiar page editing for the editorial team and, at the same time, content as data for an app, a newsletter or further channels. Which variant holds up depends less on the technology than on who maintains the content and how many channels are genuinely served.

For systems already in place we take on the assessment of the landscape: where does extending pay off, where is replacement the more honest route, and what does the switch actually cost — including migrating the existing content.

The move to the cloud is rarely decided on technical grounds — it is decided on the invoice. Scalability, availability and faster provisioning are real; so are operating costs that end up higher after the migration because an application was simply lifted across one to one, without adapting it to the new cost model.

So we start by checking which part of your landscape actually gains from the cloud. For some systems it is the right step; for others, running them yourself remains the cheaper and calmer option. That assessment includes the service model: where rented infrastructure is enough, where a platform with databases and middleware as a service pays off, and where ready-made standard software is simply the sensible answer.

If the path does lead to the cloud, we plan it in stages rather than as a single cut-over date: containerising the applications, orchestration, automated provisioning, infrastructure described in a way anyone can retrace. We have built and operated platforms of this kind — from containerised eCommerce systems to services that must cope with substantial load peaks around scheduled publications.

One point that regularly comes too late in cloud projects is high on our list early: how you get out again. We make sure that dependence on a provider is a deliberate choice rather than something that happened along the way.

A data migration is the part of a system replacement that gets the least attention and can go wrong the most. The new system has been chosen, the interface is in place — and then it turns out that twenty years of grown content does not fit the new data model, that relationships are missing, or that nobody can say whether everything actually arrived.

We approach this kind of work in clear stages. It starts with an analysis of the source: what is actually there, what is redundant, what has drifted out of consistency over the years. From that comes the mapping onto the target model — the part that holds the real work, because structure, format and relationships rarely line up one to one. Only then comes the transfer, as a rule repeatable and in several runs, so that errors can be corrected between runs instead of on the cut-over date.

What matters to us is proof: a migration is only finished when you can state in numbers what was transferred and what was not — and when the discrepancies are explained. In a publishing project we moved roughly one million articles and some 3.4 million images from twenty years of archives this way, at a conversion rate of 99.82 percent. The remaining cases were named, not unknown.

Equally important is the transition itself: which systems run in parallel and for how long, when the switch happens, and what the way back looks like if something does not hold. We settle those questions before the first record moves, not after.

The hardest question about AI is not which model to pick, but which process actually benefits from it. A lot of what starts as an AI project turns out to be a data problem, a missing interface, or a workflow that classic automation would solve more cheaply and more reliably. We make that distinction at the start — before budget is committed.

Where a use case does hold up, we settle the questions that decide between smooth operation and trouble later. Which data is allowed to leave the building, and what does that mean for the choice between a hosted model and running your own? How do you check whether the results are good enough, instead of relying on a gut feeling? What does operation cost per month if usage grows tenfold — and how do you cap it? And where a decision has consequences, how does a human stay accountable for it?

Architecturally, we consistently advise encapsulating the AI rather than weaving it through the system. Models age faster than your application; keeping them behind an interface of your own means you can swap them without touching the product. That applies to changing provider just as much as to moving from a rented model to one you operate yourself.

What you get is an honest assessment: which use cases are worth it, what they realistically cost, in which order to tackle them — and which ones to leave alone. If you want to move on to implementation, our fixed-price offerings are listed under AI Packages; consulting does not commit you to them.