Three years ago, I signed a renewal that cost my team €14,400 for the year. The tool did one thing: it collected form submissions and pushed them into a spreadsheet. When I asked what happened if we stopped paying, the account manager said something I still remember: "You can export the list, but not the logic."
That sentence is the whole argument for migrating from proprietary SaaS to sovereign open source tools. Not the licence fee. Not the marketing. The fact that the value you build inside these platforms—the rules, the automations, the relationships between data—belongs to somebody else's infrastructure and somebody else's legal jurisdiction.
Sovereignty gets sold as a compliance box. In practice, it's an operational question: who can switch off your tool, read your data, or change the price while you have no alternative? Here's what I've learned actually doing these migrations, including the two that went badly.
Key Takeaways
- Data export is not the same as logic export—test whether your automations survive outside the vendor's walls before you commit.
- Budget for internal ops capacity, not just licence savings. The tool is free; the person who patches it on a Sunday is not.
- Exit costs hide in contract clauses, proprietary export formats, and API rate limits that only bite when you try to leave.
- A GDPR-compliant self-hosted setup requires you to sign your own DPA-equivalent with your hosting provider—most teams skip this and inherit a gap.
- Sequence by criticality, not by enthusiasm: start with a workload where failure costs you nothing politically.
- The real return isn't cheaper software. It's a shorter list of people who can say no to you.
Why sovereign open source migration is more than a cost exercise
Most business cases I've seen lead with the invoice. "We'll save €9,000 a year on seats." Fine. But if savings were the only driver, half these projects would never start—because the first year often costs more than it saves.
The three questions that actually decide it
When I evaluate a potential migration now, I run it through three filters before touching a spreadsheet:
- Who has legal reach over the data? A US-headquartered provider is subject to US legal process regardless of where the datacentre sits. That's not paranoia, it's how the jurisdictional stake works.
- What breaks if the vendor changes terms? Per-seat price hike, API deprecation, feature moved behind an enterprise tier—I've lived through all three.
- Can we run it ourselves? Honestly. Not aspirationally.
That third one is where projects die. A tool being open source tells you nothing about whether your team can keep it patched, monitored, and backed up at 2 a.m. when the container won't restart.
The argument that doesn't hold up
"Open source means free." No. It means the licence is free. In my last full migration—a collaboration and file-sync stack for a 40-person company—the licence line went to zero and the infrastructure line went from €0 to roughly €380/month for hosted VMs, managed backups, and an object storage bucket. Add about six hours a month of an engineer's time for updates and monitoring.
Net it out and we saved money. But we saved maybe 30%, not the 90% the original slide deck promised. The 90% figure assumed the ops work was free, which is the single most common accounting error in this space.
The hidden costs nobody puts in the deck
Exit costs are the part of the conversation that vendors design carefully and buyers discover late.
What exit costs really look like
I once spent eleven days rebuilding a workflow that took twenty minutes to build inside the original SaaS. Nothing exotic—a form that routed requests to the right person based on a dropdown value. The vendor exported the submissions as CSV. The routing logic, the conditional notifications, the escalation rules: gone. Rebuilt from memory and screenshots.
Three places to look before you sign anything:
- Contractual notice periods and auto-renewal windows. Annual terms with 60-day notice are common and easy to miss.
- Export format fidelity. Can you get attachments? Threaded history? Metadata? Or just a flat table?
- Retention after termination. How long does the vendor keep your data, in what form, and can you demand deletion in writing?
Ask for a trial export before the renewal date, not after. Most vendors will let you export a sample. The ones that won't have told you something important.
The ops capacity question you cannot skip
Self-hosting shifts the support model. With a SaaS vendor you get a contract and a response SLA. With a community-supported open source project you get a forum, a release cadence, and a security advisory list you need to actually read.
Who subscribes to those advisories in your organisation? If the answer is "nobody yet," that's your first hire or your first outsourcing contract—not your first migration.
Building the migration plan that survives contact with reality
My first attempt at this was a disaster, and it's worth describing because the failure mode is so typical. I picked the highest-visibility tool in the company—the one everyone used every day—as the pilot. Rationale: maximum impact, maximum learning. Result: three weeks of complaints, a partial rollback, and a credibility hit that delayed the whole programme by two quarters.
Sequence by blast radius, not by enthusiasm
The correct order is the boring one. Start with a workload where a rough week costs nothing politically. Internal wikis. A test-environment CI runner. A file-share for one team. Prove the pattern, write down what you learned, then climb.
Here's the comparison I now use to score candidates:
| Factor | Good first candidate | Bad first candidate |
|---|---|---|
| User count | Under 15 | Whole company |
| Data sensitivity | Internal, non-regulated | Customer records, HR, finance |
| Integration depth | Standalone or one API call | Hooked into five internal systems |
| Export quality | Standard formats available | Proprietary blob, no schema docs |
| Rollback cost | Re-enable the old account for a month | Data already transformed and deleted |
The 90-day shape
Roughly: weeks one to three for the audit and the export test; weeks four to eight for standing up the replacement and running it in parallel; weeks nine to twelve for cutover and the first patch cycle. Parallel running is non-negotiable in my book—it's the only honest way to discover the features people depend on but never mentioned.
Expect the cutover to overrun. Mine did, twice, by about three weeks each time. The cause was never the software. It was the integrations and the one person who had built a personal workflow on top of the old tool and told nobody.
Who maintains it, and who is accountable?
This is the question that separates a real programme from a procurement exercise. Someone has to own the stack: patch cadence, backup verification, access reviews, incident response.
Community support versus a contract
Community support is often excellent and always asynchronous. That's a fine trade for an internal wiki. It's a bad trade for the system your customer support team uses to answer tickets, unless you have an internal escalation path that isn't a forum thread.
Options I've used, in increasing cost:
- Internal ownership by an existing platform engineer, with time formally allocated.
- A managed hosting provider that runs the open source software for you—same code, someone else's on-call rota.
- A commercial support subscription from a vendor built around the project.
Picking the cheapest and pretending the time is free is how these programmes quietly unwind eighteen months later.
How a self-hosted tool actually gets GDPR compliant
Here's the part that catches people. Moving to self-hosting doesn't remove your obligations—it redistributes them. You become, in effect, the operator of the processing, and you still rely on a hosting provider underneath.
Concretely, that means you need a data processing agreement with your infrastructure provider, an internal record of what personal data sits in which system, a documented retention policy, and a working process for access and deletion requests. Self-hosting gives you the technical ability to delete a record on demand. It doesn't give you the paperwork.
I've seen this gap left open for months because everyone assumed "we host it ourselves now, so we're fine." You're not fine; you're differently exposed.
When you should not migrate
Not every tool deserves this treatment. If a SaaS product is cheap, peripheral, handles no personal data of consequence, and would cost you three weeks to replace, leave it alone. Sovereignty is a means of managing risk, and spending €20,000 of engineering time to de-risk a €40/month tool is a bad trade dressed as a principle.
My rough rule: migrate when the annual spend, the data sensitivity, or the switching risk crosses a threshold that would hurt. One of those three. Not all three, not a feeling.
The thing that surprised me most across these projects wasn't the cost savings or the technical work. It was how differently the team behaved once the tool was ours. People proposed changes. They asked for features. They treated the system as something they had a say in, because they did.
That's hard to put in a business case. It's also, in my experience, the part that lasts.
