Die Kosten des Wandels: 4 Wege, wie Vendor Lock-in Ihr Geld kostet 

Executive Summary

Die meisten CMS-Evaluierungen konzentrieren sich auf die Kosten, die sich leichter vergleichen lassen und gleich zu Beginn sichtbar sind, wie Lizenzgebühren, Hosting und Implementierung. Die Kosten, die letztlich darüber entscheiden, ob die Auswahl wirklich stimmig war, treten jedoch erst später zutage – wenn die Plattform in den Märkten einer Organisation läuft, in den Redaktionsteams und in den verbundenen Systemen. Fast alle dieser versteckten Kosten lassen sich auf eine einzige Ursache zurückführen: Vendor Lock-in. Dieses macht eines von sechs weiteren Kriterien aus, die in jeder ernsthaften CMS-Evaluierung berücksichtigt werden sollten.

Es gibt vier unsichtbare Kosten des Lock-ins, die Einkaufsteams häufig übersehen.

• Das Erste ist, dass große Upgrades proprietärer Suite-Lösungen sich oft wie komplette Migrationsprojekte verhalten – statt wie routinemäßige Updates. So muss die Organisation die Veröffentlichungsfrequenz des Anbieters übernehmen und ihre individuellen Anpassungen jedes Mal neu aufbauen.
• Das Zweite ist, dass Talent durch Zertifizierungsprogramme und kleinere Entwicklermärkte vom Anbieter gesteuert wird. Das beeinflusst sowohl die Projektkosten als auch die Dauer, bis Rollen besetzt sind.
• Das Dritte ist, dass die Organisation weder die Produkt-Roadmap noch die Integrationsebene besitzt. Funktionen werden also nach dem Zeitplan des Anbieters ausgeliefert und veralten, während individuelle Brücken bei jedem Upgrade weiter gepflegt werden müssen.
• Das Vierte ist, dass Content und die dazugehörigen Workflows in der Cloud des Anbieters in vom Anbieter definierten Formaten liegen. Das macht es schwierig, ihn in einer nutzbaren Form zu exportieren, und Datenresidenz wird zu einem Compliance-Thema.

In all diesen Fällen nimmt WordPress eine andere Position ein, weil die Organisation die Kontrolle über ihre eigene Update-Frequenz, die Talentversorgung, Integrationen und die Eigentümerschaft am Content behält.

Diese vier Kosten lassen sich vor dem Vertragsabschluss sichtbar machen, mithilfe einer gewichteten Scoring-Tabelle, die auf jedes der vorgeschlagenen Systeme über sieben Kriterien und einen Fünfjahreshorizont angewendet wird. Anschließend erfolgt eine Validierung anhand der Anbieterverfügbarkeit, der absehbaren Gebühren und der Sicherheitsunterstützung. Der sichtbare Preis im Voraus ist selten die tatsächlichen Gesamtkosten, und WordPress schlägt proprietäre Suites in genau der einen Messgröße, die sie nicht erfüllen können: den Kosten des Ausstiegs.

---

Die Kosten der Veränderung

Vendor Lock-in wird nicht als Kostenfaktor betrachtet, bis es zu spät ist. Lassen Sie uns die vier wichtigsten Wege untersuchen, wie Vendor Lock-in Ihre Organisation Geld kosten kann.

Wenn eine Organisation eine CMS-Evaluierung durchführt, beginnt sie typischerweise (und endet) mit den Zahlen, die sich leicht nebeneinander vergleichen lassen: Lizenzgebühren, Hosting, Implementierung. Allerdings sind die unsichtbaren Kosten, die später auftauchen diejenigen, die letztlich bestimmen, ob Sie die richtige Entscheidung getroffen haben oder nicht. Das Problem ist nur: Diese Kosten sind sich im Business Case im Voraus schwerer abzubilden, weil sie davon abhängen, wie sich die Plattform verhält, sobald sie über Ihre verschiedenen Märkte hinweg läuft, in Ihren Redaktionsteams und in den digitalen Systemen, die damit verbunden sind.

Lock-in ist eines von sieben Kriterien, die sich in einer ernsthaften Evaluierung eines neuen oder bestehenden CMS lohnen, bewertet zu werden – zusammen mit Skalierbarkeit, Erweiterbarkeit, Sicherheit, Performance, Workflows und den Gesamtkosten des Betriebs (Total Cost of Ownership). Sehen wir uns die vier versteckten Kosten an, die durch Vendor Lock-in entstehen und die Einkaufsteams im Entscheidungsprozess häufig übersehen.

1. Migrationsprojekte werden als Upgrades getarnt

Bei vielen proprietären Suites ist ein großes Release näher an einer zweiten Implementierung als an einem Update und einer standortweiten Ausspielung. Sitecore verlangt beispielsweise in der Regel ein Migrationsprojekt, wenn ein neues Update verfügbar wird – weil die Anpassungen, die Sie möglicherweise gebaut haben, um Ihre Abläufe abzubilden, auf dem Datenmodell des Anbieters aufsetzen. Wenn sich dieses Modell zwischen großen Versionen ändert, müssen die Arbeiten, die auf der vorherigen Version beruhten, neu aufgesetzt und in den Modulen der Suite erneut getestet werden. Und selbst wenn das nicht bei jedem Update geschieht: Ein einziges Mal reicht aus, um in Ihren digitalen Abläufen eine ernsthafte Blockade zu verursachen. 

Das große Problem dabei ist: Sie bestimmen den Zeitpunkt nicht. Sie übernehmen die Veröffentlichungsfrequenz des Anbieters, und jede große Version bringt ihren eigenen Umfang (Scoping), ihr eigenes Testfenster und ihre eigene Budgetanforderung mit. Keine der zusätzlichen Arbeiten, die Ihre Teams rund um ein Update erledigen müssen, wird im Erstangebot sichtbar – dadurch wird es viel schwieriger, die Kosten präzise zu berechnen. Die Lizenzierung und Wartung von Sitecore zum Beispiel liegt bereits im oberen Enterprise-Segment, und dann werden etwaige wiederkehrende Upgrade-Projekte zusätzlich darauf berechnet. Die Kosten, Ihre individuellen Anpassungen bei jedem großen Release neu aufzubauen, sind nicht in den Lizenzgebühren enthalten – und diese Kosten fallen bei Ihnen an.

Bei WordPress ist ein Versions-Update einfacher als bei alternativen proprietären Systemen: Core, Plugins und Themes lassen sich in einem Takt aktualisieren, den Ihr Team festlegt, und der Code läuft auf einer Infrastruktur, die Sie bereitstellen, testen und auch wieder zurückrollen können. Das bringt die Kontrolle in Ihre Hände, denn Sie bestimmen Tempo, Zeitraum und Takt für Updates. Und dank der Abwärtskompatibilität laufen Updates auf WordPress reibungsloser als bei proprietären Weblösungen, und große Updates lassen sich leichter umsetzen – im Gegensatz zu proprietären Systemen, bei denen größere Updates oft eher einem kompletten Neulauf der Plattform gleichen.

2. Talent liegt vollständig in den Händen Ihres Anbieters

Adobe Experience Manager läuft auf einer eigenen Infrastruktur innerhalb von Adobe Experience Cloud, und die DevOps-Arbeiten erfordern Engineers, die genau diesen Stack kennen. Das lässt sich nicht auf ein allgemeines Team übertragen. Sitecore basiert auf .NET, wobei der Entwickler-Markt kleiner ist als bei WordPress, und die Menschen, die es betreiben, verfügen über Sitecore-Zertifizierungen. Herstellerzertifizierungen sind gut für Einheitlichkeit und dafür, sicherzustellen, dass alle, die am Produkt arbeiten, über dieselben Qualifikationen verfügen. Für Organisationen sind sie jedoch hinsichtlich der Steuerung der Lieferfähigkeit (Supply Control) wenig hilfreich. Das ist aus Sicht der Anbieter hervorragend, denn sie behalten die Kontrolle über den Talentpool, und neue Interessenten müssen erst durch deren Zertifizierung. 

Für Organisationen, die auf Agilität und schnelle Reaktionsfähigkeit angewiesen sind, kann das allerdings ihre digitalen Fähigkeiten beeinträchtigen: Der Talentpool bleibt klein und unter Kontrolle, Tagessätze lassen sich manipulieren, und die Zeit, die man damit verbringt, jemanden für eine Rolle zu finden, kann unnötig in die Länge gezogen werden. Die Verfügbarkeit von Talent – oder deren Fehlen – wirkt direkt auf Projektkosten und Projektdauer. Wenn ein Freelancer abspringt oder ein Lead Engineer das Unternehmen verlässt, ist Ihre einzige Option für Ersatz, zu versuchen, jemanden aus dem Kreis der Personen zu finden, die von dem jeweiligen Zertifizierungsprogramm in Ihrer Region hervorgebracht wurden. 

WordPress gibt Ihnen Kontrolle über die eigene Talentversorgung. Der WordPress-Stack besteht aus PHP, JavaScript, MySQL und standardmäßigen DevOps-Tools. Core ist GPL – also entscheidet kein Anbieter darüber, wer berechtigt ist, Ihre Plattform zu lesen, zu erweitern oder zu beheben. Das gibt Organisationen, die mit WordPress arbeiten, ein höheres Maß an Flexibilität und Anpassungsfähigkeit, wenn es um Talentbeschaffung für den Aufbau ihrer Plattformen geht. 

3. Sie besitzen weder die Roadmap noch die Integrationsebene

Proprietäre Suites sind nicht gerade knapp an Funktionen. Sitecore liefert Experience Edge für Headless-Deliveries, eine integrierte Customer-Data-Plattform sowie Marketing Automation aus. AEM liefert Content-Fragmente über GraphQL und lässt sich mit Adobe Target und Campaign verbinden. Die langfristige Einschränkung für Organisationen liegt nicht darin, ob ein System glänzende Funktionen oder Features bietet – sondern in der Kontrolle. 

Release-Zyklen laufen nach dem Zeitplan des Herstellers. Eine Fähigkeit, die Sie benötigen, wird also dann ausgeliefert, wenn sie in dessen Roadmap verfügbar ist – und eine Funktion, auf die Sie angewiesen sind, kann in dessen Zeitplan als veraltet erklärt werden. Das zwingt Sie, sich an Ihren Anbieter anzupassen – nicht umgekehrt. Proprietäre Systeme werden dazu angeregt, ein besonders attraktives Produkt zu entwickeln, das ihre Kunden darin festhält, unabhängig von der zusätzlichen Belastung durch Overhead, die entsteht, sobald sich innerhalb der Software etwas ändert.

Für Integrationen gilt die gleiche Grenze. Die veröffentlichten APIs verbinden die Plattform mit Ihrem CRM, Ihren Analytics- und Commerce-Systemen. Sie können sie jedoch nur so weit erweitern, wie es das Modell des Anbieters zulässt. Alles darüber hinaus erfordert individuelle Brücken, und Ihre Teams müssen diese individuellen Brücken bei jedem nachfolgenden Upgrade weiter pflegen. 

Mit WordPress gehört der Code Ihnen zum Lesen, Ändern und Behalten. Eine individuelle Integration in WordPress ist ein einmaliger Build auf einer Grundlage, die Ihnen gehört – nicht eine dauerhafte Haftung, die an die Release Notes eines anderen Unternehmens gekoppelt ist. Als Open-Source-Plattform hat WordPress selbst keine inhärenten Anreize, aber sein Pool an Core-Contributors und Entwicklern hat sie. Und diese werden dafür incentiviert, die Plattform so gut wie möglich zu machen – und zwar so lange wie möglich. Große Agenturen und Hosting-Anbieter im Ökosystem tragen zudem aktiv Stunden für Teams bei, um sie kontinuierlich zu verbessern.

4. Sie können Ihren Content nicht in einer nutzbaren Form mitnehmen

Bei den meisten proprietären Suites liegen Ihr Content und die Workflows darum in der Cloud des Anbieters – in vom Anbieter definierten Formaten. Sie haben dabei kein Mitspracherecht, und es gibt wenig Flexibilität. Dieser Lock-in verstärkt sich noch weiter, sobald diese Formate und Workflow-Engines auf die einzelnen Geschäftseinheiten ausgerollt werden: Denn jedes Team, das die nativen Templates, Komponenten und Freigabe-Workflows übernimmt, fügt eine weitere Ebene hinzu, die Sie andernorts neu aufbauen müssten. 

Webflow ist hierfür das deutlichste Beispiel. Sie können eine Website exportieren, aber nur als statisches HTML – mit eingeschränktem Vollzugriff auf den Code. Der Export liefert Ihnen also das gerenderte Ergebnis, aber nicht das System, das es erzeugt hat: nicht das Content-Modell, nicht die Bearbeitungsstruktur, nicht die Datenbeziehungen. Außerdem werden Ihre Audit-Trails und die Revisionshistorie nicht enthalten sein. Das macht Datenresidenz aus einer Unannehmlichkeit eine Compliance-Herausforderung: Sie müssen wissen, wo die Datensätze physisch liegen, in welchem Format sie zurückkommen und was den Export nicht überlebt. 

WordPress geht diese Herausforderung anders an. Ihr Content ist in einer Datenbank und in Anwendungs-Code abgelegt, der Ihnen gehört, sodass Sie ihn dort hosten können, wo es Ihre Vorgaben erfordern, und ihn zwischen Anbietern bewegen können, ohne eine Freigabe des Anbieters abzuwarten. Für ein Umfeld unter DSGVO oder einer sektoralen Prüfung bedeutet das: Sie können Datensätze direkt erzeugen – ohne zu warten oder von einem Exportprozess eines Anbieters abhängig zu sein. Die Eigentümerschaft an Ihrem Content liegt vollständig bei Ihnen. 

So können Sie die Kosten eines CMS aus Ihrer Shortlist über fünf Jahre vorhersagen

Ein einfacher, aber effektiver Weg, um die unsichtbaren Kosten eines CMS vor dem Unterschreiben sichtbar zu machen, ist eine gewichtete Scoring-Matrix – und sie dauert pro System etwa zwanzig Minuten. Bewerten Sie sieben Kriterien jeweils von eins bis fünf und gewichten Sie jedes entsprechend Ihrem spezifischen Unternehmen: Vendor Lock-in, Skalierbarkeit, Erweiterbarkeit, Sicherheit, Performance, Workflows und die Gesamtkosten des Betriebs. Platzieren Sie WordPress, Sitecore, AEM, Webflow oder jeden anderen Kandidaten auf Ihrer Liste und führen Sie die Bewertung über genau dieselbe Matrix durch, sodass der Vergleich wirklich fair ist. Anschließend validieren Sie die Gewinner auf drei Punkte, die die Bewertung ausblendet: ob qualifizierte Anbieter in Ihrer Region tatsächlich verfügbar sind, welche Lizenz- und Hosting-Gebühren in den kommenden fünf Jahren absehbar sind und wer Sicherheitsupdates bereitstellt – und wie lange.

Etwas, das wir sagen müssen: Eine schlechte Bewertung für eine Plattform bedeutet nicht zwangsläufig, dass es für die konkreten Anforderungen Ihrer Organisation eine falsche Entscheidung ist. Der entscheidende Punkt ist jedoch, jede Option über einen langen Zeithorizont zu bewerten und potenzielle versteckte Kosten zusammen mit den anfänglichen Lizenzgebühren der Plattform zu berücksichtigen. Der sichtbare Preis ist selten der tatsächliche Preis, den Sie zahlen, sobald Sie über Jahre in ein System hineingesperrt wurden und wieder herauswollen.

Proprietäre Datenformate sind der Haupttreiber für Lock-in

Eine Analyse von Cloud- und Plattformmigration aus dem Jahr 2016 im Journal of Cloud Computing identifiziert die Kosten für die Re-Engineering-Arbeit rund um die Datenformate eines Anbieters als die wichtigste Hürde beim Ausstieg. Eine Migration eines CMS stellt sich an derselben Mauer – aus demselben Grund.

Was das für WordPress bedeutet

WordPress sichert sich seinen Platz in der Shortlist anhand konkreter Punkte. WordPress betreibt mehr als 40% des Webs. Natürlich sind viele dieser Websites Blogs oder Ein-Seiten-Websites. Auf der anderen Seite handelt es sich bei einem beträchtlichen Teil davon um hochperformante multinationale Websites wie NASA, TIME Magazine und The Walt Disney Company Newsroom.   WordPress Multisite kann auf einem einzigen Core Hunderte von Instanzen betreiben – und ist damit eine extrem leistungsfähige Architektur, wenn ein Team über Dutzende von Markt- oder Brand-Websites hinweg agiert. WordPress VIP, WP Engine, Kinsta, Pantheon und vergleichbare Enterprise-Hosts liefern SLA-gestützte Sicherheit und Performance sowie DDoS-Schutz. Damit bieten sie genau die Art von Verantwortlichkeit, die IT und Recht üblicherweise sehen wollen, bevor sie Open Source freigeben.

Wenn eine WordPress-Plattform mit präziser Plugin- und Governance-Disziplin gebaut wird, bietet sie einer Enterprise-Organisation das Sicherheits- und SLA-Profil, das sie braucht – und hält gleichzeitig das Datenmodell, den Release-Plan und den anpassungsfähigen Talentmarkt in Ihren Händen. Genau so stellt WordPress auch eine proprietäre Suite in genau dem einen Kriterium, das die Suite nicht erfüllen kann: die Kosten des Ausstiegs. Eine WordPress-Installation kann in der Prüfphase im Hinblick auf den anfänglichen Aufwand höhere Kosten verursachen. Doch über einen Zeitraum von 5+ Jahren sind die Kosteneinsparungen durch WordPress im Vergleich zu einem festgefahrenen, gebundenen System enorm. 

---

Wechseln Sie zu einer Plattform, die Sie nicht ausbremst.

Wir arbeiten mit Unternehmen zusammen, um CMS-Migrationen zu WordPress zu planen und umzusetzen – ohne Abstriche bei Content, Architektur oder Stabilität nach dem Go-live.

Websites & Relaunch — Vollständige Relaunch-Projekte: von der Projektplanung und dem Design bis hin zum Build und Go-live – auf einer Plattform, die Sie tatsächlich besitzen.

Content Migration — URL-Mapping, Redirect-Strategien, Metadaten und Asset-Migration über große und komplexe Bestände hinweg.

Custom Integrations — Verbinden Sie Ihre neue WordPress-Plattform mit Ihrem bestehenden CRM, ERP, Analytics-Stack, SSO und MarTech-Tools.

Maintenance & Support — Zentrale Updates, Sicherheitsüberwachung und Governance der Plattform, sobald Sie live sind.

Quality Assurance — Experten-QA für Ihre neue Installation oder ein vollständiger Audit Ihrer bestehenden Lösung, bevor Sie entscheiden, was als Nächstes kommt.

Sie haben Fragen? Sprechen Sie mit unseren Experten.

---

Ähnliche Artikel