The most common argument in any technology meeting is always the same: "We need Open Source to avoid vendor lock-in." It's a mantra that sounds reasonable. Nobody wants to depend on a single provider that can raise prices, change features, or simply disappear.

However, there is a major flaw in this logic: it completely ignores what actually happens after the software is installed.

The Control Paradox

Let's look at what is happening in the higher education market. Currently, 71% of the top 100 universities in the world use Drupal. WordPress powers more than 40% of the entire web. These are platforms with massive communities, endless documentation, and, in theory, total freedom to change the code.

Yet, when we visit institutions that have used these platforms for years, we see the same pattern over and over:

Does this sound familiar? This isn't vendor lock-in. It is version lock-in, and it is much more dangerous because most people don't realize it's a problem until it's too late.

What is Version Lock-in?

Version lock-in happens when an organization gets trapped in an old version of software because the cost and risk of updating are higher than the resources available to do it. In the world of Open Source, this problem is much bigger than most people are willing to admit.

The Drupal Case: When "Updating" Means "Starting Over"

Drupal is the perfect example of version lock-in. On January 5, 2025, Drupal 7 officially reached its "End of Life." After 14 years, the version that was the gold standard for universities stopped receiving official security updates.

The problem is that as of late 2025, over 37% of all Drupal sites in the world are still running Drupal 7. That means roughly 134,000 websites are operating without official security support.

Here is the part nobody mentions in sales pitches: moving from Drupal 7 to Drupal 10 or 11 isn't an update. It's a total reconstruction. Because the architecture changed so much, the process requires you to:

In simple terms, it's like being told that to "update" your car, you have to buy a new one and manually move over every single part you want to keep. This is why many universities are still planning migrations to Drupal 10 even though Drupal 11 is already out. What started as a choice for "control" has become a trap that requires a massive investment to escape.

The Hidden Cost of Infrastructure

Version lock-in isn't just a technical headache: it's an economic one too. Because of its complex design, Drupal has much higher infrastructure requirements than other options. In real-world projects, we see costs like:

When you add these costs up over five years, the total cost for a medium-sized university can exceed $2.5 million. "Free" software turns out to be incredibly expensive once you calculate the actual cost of running it.

WordPress: A Different Kind of Trap

In the WordPress world, the problem looks a bit different but leads to the same result.

The Plugin Waterfall: A typical university site has 15 to 30 active plugins. Each one has its own update cycle. When you update the main WordPress software, you have to check every single plugin for compatibility. If one critical plugin breaks, most teams simply choose not to update the whole site.

The Custom Theme Problem: If you spent $50,000 on a custom theme four years ago, that code was built for a specific version. Updating it often means rewriting it.

The Invisible Debt: Every month you go without updating, the gap between your version and the current one grows. What should have been a weekend task becomes a six-month migration project.

The Case That Changed Everything: WP Engine vs. Automattic

In late 2024, the WordPress world faced a massive crisis. The co-creator of WordPress and CEO of Automattic launched a public campaign against WP Engine, one of the largest hosting providers.

This fight escalated quickly:

What does this mean for a university? It means the "ownerless" platform actually has a very powerful player who can block your access to critical security updates to win a business argument.

Autonomy vs. Freedom

There is a big difference between these two concepts. Autonomy means having the source code and your own server. Freedom means being able to launch a new marketing campaign in two hours without waiting for IT.

Open Source gives you autonomy, but it comes with a heavy workload that actually reduces your operational freedom.

Think of it like a car. Autonomy is having the tools and the manual to fix the engine yourself. Freedom is being able to drive wherever you want without worrying about the engine at all.

A Better Way to Think About the Problem

The debate shouldn't be "Open Source vs. SaaS." The real question is: who handles the workload?

In an Open Source model, the workload is yours. Every update, every security patch, and every migration is your responsibility. In a specialized SaaS model, that workload belongs to the provider. Updates happen automatically and the platform evolves constantly without you touching a single line of code.

Yes, there is a dependency on the provider, but that risk can be managed with a good contract. The risk of version lock-in, however, grows slowly until it becomes a structural disaster.

Next time someone brings up "vendor lock-in," ask them: When was the last time we actually updated to the latest version? How much would it cost us to migrate today if we had to? The answers might be more uncomfortable than any SaaS contract.

In our next article, we will take a deep dive into the hidden costs of "free" software and why the real cost of Open Source is usually double what you expected.