What remains when the vendor disappears?

The decision that outlasts the contract

Every software decision is a bet on a vendor’s future. What gets assessed are features, prices, reference customers and the support promise. What gets checked is whether the platform delivers today what is needed. What gets checked far less often is what will hold true in five years, once the conditions have shifted, and what remains when the vendor is no longer there.

For every organisation that runs digital infrastructure and expects it to last longer than the next budget cycle, this is a central question. The answer, or the absence of an answer, determines whether an organisation stays able to manoeuvre in a crisis.

Three ways to fail

The software landscape offers enough precedents to understand the pattern behind critical dependencies. The new conditions rarely arrive all at once. They arrive gradually, which is exactly what makes them so hard to recognise.

01. The vendor is acquired, and the product becomes a dead end

Ektron was one of the most widely used proprietary enterprise CMS platforms in the .NET space, deployed by companies that had opted for a stable, specialised platform. After Accel-KKR acquired first Ektron and shortly afterwards EPiServer, the two companies were merged under the EPiServer name in January 2015. What followed was a forced migration. Ektron customers had to move to a new platform, regardless of whether their systems were ready for it. The vendor continued to exist. The product that had been built on for years did not.

This is not an isolated case but a standard pattern in a market where private equity firms acquire vendors, consolidate product lines and present customers with a fait accompli. The decision about whether your own system keeps running is then made somewhere else.

02. The vendor still exists, the relationship of trust does not

Not every crisis ends in insolvency or acquisition. Sometimes it shows itself in repeated rounds of layoffs, in unstable roadmaps and in leadership changes on an annual cycle. On paper the vendor is intact. In practice, the stability that a platform decision depends on is missing.

This can be observed at several established enterprise CMS vendors whose product generations are so far apart that a migration within the same product family effectively amounts to a rebuild. Anyone who ignores such signals because the contracting party still exists is deciding on an incomplete basis.

03. The vendor leaves and leaves a gap behind

Digital River, a global e-commerce service provider with customers such as Adobe and Lenovo, began its wind-down in January 2025 and filed for Chapter 7 bankruptcy in May 2025. Marin Software, an established provider of digital advertising management, followed in July 2025 with a Chapter 11 filing. Both companies had a large customer base, contracts and integrations that nobody can replace overnight.

The trend behind this is measurable. According to data from the equity management platform Carta, analysed by TechCrunch, 966 US startups from its own customer base shut down in 2024, compared with 769 the year before. Enterprise SaaS accounted for 32 percent of all closures, the largest share of any category. The figures cover Carta customers only and therefore show just one part of the market. The direction is unambiguous nonetheless.

For organisations that have built their digital ecosystem deeply on one platform, this represents a concrete risk. Workflows, data structures, integrations and internal knowledge then hang on a system that nobody actively maintains any more, and on a migration project for which neither time nor budget was planned.

Why open source answers differently at a structural level

In a proprietary system, control over code, roadmap, licensing model and operations rests solely with the vendor. If that vendor falls away, whether through insolvency, acquisition or a strategic pivot, the future of the software is open. The code is not accessible, not transferable and cannot be developed further by third parties. Security updates stop.

Anyone who stays on the platform will sooner or later face the question of when to migrate. The longer that decision is postponed, the more innovation cycles pass the organisation by.

In an open-source system, the code lies open. It can be inspected, forked, developed further and operated, regardless of what happens to the original service provider. That is not a technical footnote but a structural guarantee that proprietary systems by definition cannot give. Open source does not mean that a piece of software never reaches the end of its lifecycle. It means that this decision is not made by a single company.

What open source does not guarantee

Open source is not insurance against everything. Open-source projects are discontinued too, when the community is too small, when the project is no longer maintained or when the market shifts. The decisive questions are therefore how large and how active the community is, how long the project has existed and who carries it, a single organisation or a broad ecosystem.

An open-source project with an active global community is structurally more stable than a proprietary SaaS product carried by a handful of developers, regardless of how much venture capital was raised.

Drupal is a solid example of this. The content management framework has been developed by a global community since its first release in January 2001, drupal.org lists more than one million registered community profiles, and the software runs at governments, universities and large enterprises on every continent. That reach is the result of an architectural decision, namely open code, no proprietary dependencies and no single organisation as a point of control.

The special case of custom development

Software developed specifically for one organisation, such as portals, internal tools or industry-specific applications, carries no community network by definition. If the team that built it falls away, what remains in the worst case is a black box.

The answer does not lie in doing without custom development but in the way it is built. Code that is documented and modular and builds on open standards can be taken over by another team. Code with proprietary frameworks, undocumented dependencies and no test coverage cannot. The difference between maintainable and unmaintainable custom development is not a question of technology but a question of the attitude with which it is built.

Exiting is a governance question, not just a licensing question

This is the point that is missing from most discussions about lock-in. Open code is the necessary condition for the ability to act, but not the sufficient one. Organisations with open systems get stuck just as regularly, because nobody can name which system serves which goal, who decides on changes, which data sits where and in what structure, and to which standards things are built.

Anyone who can answer these questions has an exit path, including out of a proprietary system. Anyone who cannot answer them stays bound, even if the source code is freely available. This is why the work on independence does not begin with the choice of technology but with goals, processes and responsibilities. The technology follows from that.

What this means for publishers and media houses

In publishing houses and media companies, this risk meets particularly long system lifecycles. Editorial, subscription, shop and distribution systems are interwoven over years, and every migration touches live production. At the same time there is a concrete trigger, because support for Drupal 7 ended in January 2025, and platforms without security updates are not a viable option for houses with paid content and user data.

Factorial works in this environment for C.H. Beck, dpa, Verlagsgruppe Oetinger and RTL Publishing, among others. What these projects show is always the same pattern. The technical migration is the smaller task. The bigger task is to clarify beforehand which systems serve which goal and who decides on what.

How to recognise a partner you can hand over from

Vendor risk applies not only to platforms but to service providers as well. It can be tested at three points. Does the system run on an open-source platform with its own community. Is the custom development documented, modular and tested. Do repositories, operations and access sit with you. If these three points are met, another team can take over without rebuilding.

This is exactly how we work. Handover readiness is a requirement on the code for us, not an add-on at the end of a project, and it shows in every architecture decision, in every code review and in every platform recommendation.

The next step

For your own system landscape, this can be clarified in half a day. That is exactly what we do in the Governance Quick Check, which ends with a map of your digital systems, along with the three to five places where dependency is most expensive today.

What would be your first step if the news came tomorrow?