Digital Sovereignty Is More Than Where Your Data Lives

Mathias started with the difference between data sovereignty and governance. When governments and enterprises talk about sovereignty, they usually mean data sovereignty: your data sits on servers in your own country. Proprietary vendors can offer that easily. They tell you to use their servers and promise you can always get your data out.

What gets lost is governance. Who controls the software, who can change it, and what happens when someone outside your country changes the rules? You may own your data, but as long as it sits with a vendor, you don’t govern it. A political decision elsewhere—and it doesn’t have to be in the U.S.—can cut off access to a system that technically stores your data at home.

Mathias also pointed out that open source doesn’t only give you the freedom to use software. It also lets you learn it. When you run open source, the expertise ends up with the people who use and deploy it, spread across a country, the EU, or the world, instead of sitting with a single vendor. That distributed knowledge is something proprietary software can’t offer, and open source communities rarely use it as an argument.

We see the same in TYPO3 projects. When a client asks why TYPO3 is a sovereign choice, I don’t point to a feature. I point to the governance structure, the release cadence, and the many people who know the system—none of which a single company owns or could sell.

Fabian Stein from punkt.de argued the pragmatic side. When using proprietary software, you can still consider yourself data sovereign, when you copy the data you need out of it every day. If the platform disappeared tomorrow, you’d still have what matters.

For him, sovereignty used to be a yes-or-no question and has turned into a spectrum. Sometimes the proprietary tool is better, and then the honest advice to a client is to use it, as long as there’s an exit strategy with a known cost and a known timeline. A month and a five-figure budget to move away is an acceptable risk. A year-long migration project is not. His agency also sends clients a full export of their project documentation every month, so nothing lives only in a vendor’s tool.

I agreed. An exit strategy with a real price tag is worth more than a principled choice nobody can maintain. I’d only add that an exit strategy is itself a governance question. Regular exports, documented data structures, and repositories the client can clone at any time are what Mathias meant by managing the whole solution. The two positions were closer than they sounded at first.

Next, we got to agencies, and to my own decisions.

About ten years ago, we decided at b13 to work with one CMS only. We had tried a second system because a client pushed us toward it, and it didn’t work out. Reaching the same level of expertise in another system takes a lot of time and a lot of trial and error, and we didn’t want to do that trial and error on client projects. There’s a second problem: if you run the small projects on the new system while the big clients stay on the old one, the small projects always end up second in line. And in the end, nobody on our team wanted to work with another system anyway.

Fabian’s agency went the other way. They regularly add new technology stacks, and in his experience, a good developer gets far enough into a new stack within four or five weeks to be “three pages ahead of the client in the book.” With AI, he said, this goes even faster, so learning new software is no longer the bottleneck.

He has a point about AI. We see it at b13, too: our project managers now use AI to build small backend modules that would have needed a developer a year ago. But someone still has to review what they build: Does it follow TYPO3 best practices? Does it fit into the rest of the project’s code base? Is it secure? Those reviews need someone who knows the system well. If nobody on your team has that knowledge, AI will still produce code, and nobody will be able to tell whether it holds up in three years.

So for us, focus was never about money. We stayed with one system because that’s how we can vouch for the quality of what we deliver. AI makes it cheaper to get started with a new system, but you’re still responsible for what you build with it.

Mathias then asked: if it became really easy to move away from TYPO3, would that be the end of TYPO3?

I don’t think so. Our clients don’t stay with us because of TYPO3. They stay because of the relationship, because we understand their business, and because we’ve worked together for years. If that stops working, they should be able to leave, and TYPO3 allows that. It’s one of the reasons we recommend it: our clients aren’t dependent on us. There’s a large ecosystem of TYPO3 agencies, and any client can take their project to one of them.

In our experience, clients rarely leave over the software. When one moves away from TYPO3, it’s usually because the company was acquired and the new owner runs a different system. And moving away isn’t as hard as people think. Structured content can be migrated. With AI, you can also rebuild a site in another system starting from the live frontend, which is sometimes the better route than a database export full of content that hasn’t been online for years. We’ve done that ourselves when moving larger WordPress sites into TYPO3.

More of our larger clients now ask for what countries ask for: an open source system, access to the code, and people in their own organization who understand how it works. For a few of them, we work directly with their IT team and teach them how to make smaller changes on their own. Some now open their own merge requests, and we review them.

We started working this way a long time ago and never thought of it as a separate service. Listening to Mathias, I realized it’s what he described as the missing piece of sovereignty: building expertise where the system is used. We’ve just never talked about it publicly.

There’s a fear that comes with it, of course. If I hand over my knowledge, maybe the client won’t need us anymore. Fabian told us that one of their clients recently took the work in-house because they now have four or five people who can do it themselves, and he saw that as a good outcome. I agree, and I don’t think it makes the agency unnecessary.

We’ve seen what happens to in-house teams that work on their own systems for years. They only ever see their own project. They don’t run into other systems, other problems, or other ways of solving them, and over time, the way they maintain their website gets rusty. Practices that were fine five years ago stay in place long after better ones exist. An agency that works on many TYPO3 projects brings that outside view back in. So even when a client builds its own team, there’s a good reason to keep working with an agency: we help the in-house developers stay up to date.

It also affects how we talk about sovereignty with new clients. We always say we want to know what you want, and then figure out what you need. Sovereignty often belongs in the second group. Everyone needs it, but not everyone knows that yet.

At the end, Mathias asked everyone at the table what the CMS communities could do better. My answer was concrete: I’d like the TYPO3 Association to show how a company or a public institution, wth the help of TYPO3 partners, can build its own TYPO3 expertise. Not only a list of agencies, but a path to knowing TYPO3 well enough to own it. That path exists today, but few people know about it.

Mathias wrapped up with a point I fully agree with: sovereignty only works if clients, agencies, and CMS communities support each other, and if we stop treating it as all or nothing. Full digital sovereignty isn’t realistic for most organizations, but most can get a lot closer than they are today.

• Keeping data in your own country is necessary, but it’s the weakest sovereignty argument, because proprietary vendors can make it, too.
• Governance and local expertise are what only open source offers, and we should talk about them more.
• An exit strategy with a real price tag is better than dogma.
• AI lowers the cost of starting with a new system. You’re still responsible for what you build.
• Knowledge transfer doesn’t threaten the agency model. It’s part of sovereignty.