Umgang mit technischen Schulden: Unsere Abkehr von Microsoft IIS

Das aufgekaufte Unternehmen hatte einen großen und regionalen Kundenstamm. Es nutzte ein eigenes CMS, das in Active Server Pages (ASP) programmiert war und auf Windows-Servern mit Microsoft IIS lief. Das System war wartungsintensiv, umständlich zu bedienen und unterstützte moderne Webanforderungen wie URL-Rewrite nicht.

Einer der übernommenen Server lief zum damaligen Zeitpunkt noch mit Microsoft Windows Server 2003 - ein Betriebssystem, das bereits mehrere Versionen hinter dem aktuellen Stand zurücklag. Die Betonung liegt auf mehrere.

Wir haben uns das Ziel gesetzt, alle Kunden auf ein neues CMS zu migrieren. Die Migration sollte aber mehr als nur ein manueller Datentransfer sein. Wir wollten die Projekte unserer Kunden in einem neuen CMS neu aufbauen, um aktuelle technische Vorteile, wie responsive Layouts und eine verbesserte SEO-Struktur, voll ausschöpfen zu können. Zugleich haben wir unseren eigenen Software-Stack überarbeitet, um langfristig noch mehr Aufwand und Kosten zu senken. Wir bevorzugen nun Software, die unter einer MIT-Lizenz läuft, und setzen, wo immer möglich, nur noch auf Long-Term Support (LTS) Versionen. 

Obwohl wir MIT-lizenzierte Software verwenden, bedeutet das nicht, dass wir diese kostenfrei nutzen. Tatsächlich investieren wir jährlich mehrere Tausend Euro in die Weiterentwicklung der von uns eingesetzten Frameworks.

Da wir absolut keine Zeit zu verlieren hatten, teilten wir alle Kunden nach Komplexität und Dringlichkeit in Gruppen ein. Anschließend etablierten wir eine Universalvorlage für all unsere Projekte. Aus meiner früheren Tätigkeit in der Entwicklung mit Embarcadero Delphi habe ich die Vorteile des Rapid Application Developments zu schätzen gelernt. Genau diese Schnelligkeit im Aufbau neuer Software und Benutzeroberflächen wollte ich auch bei uns umsetzen. Dabei haben wir die Implementierung konsequent in zwei Prozesse unterteilt: Programmierung und Inhaltsverwaltung. Jedes Projekt umfasste also einen technischen und einen redaktionellen Teil. Der Hintergedanke: Ein Kunde muss keine präzisen Anpassungen am Aussehen (CSS) vornehmen. Wir müssen jedoch in der Lage sein, solche Änderungen effizient und zentral im Code vorzunehmen, und das auch über eine Weboberfläche von irgendeinem Strand aus. Alle Projekte sollten ähnliche Strukturen haben, dass auch neue Entwickler problemlos einsteigen können.

Zu Beginn der Transformation entwickelten wir die gemeinsame Grundlage, die bis zum heutigen Tag stetig weiterentwickelt wird. Es waren stets 2-3 Kundenprojekte in der Vorbereitung, aktiven Entwicklung und Nachbereitung.

Wir haben alle Kunden zu Beginn informiert und sie vor eine schwierige Entscheidung gestellt. Es gab drei Standardprozesse, für die sich jeder Kunde entscheiden konnte: Archivierung einer statischen Version des Projekts zu minimalen Kosten, Neuimplementierung mit neuem Design zu günstigen Konditionen oder Beendigung des Projekts.

Innerhalb von 18 Monaten gelang uns die Transformation. Unser neues System erweiterte sich um unzählige Kundenprojekte. Unser neu eingeführter Software-Stack skalierte hervorragend. 

Eine der größten Herausforderungen bestand darin, unsere Kunden davon zu überzeugen, dass es schlecht ist, ihre Websites über Jahre und Jahrzehnte hinweg technisch unverändert zu lassen. Wir begegneten Kunden, deren Websites seit 20 Jahren nicht aktualisiert worden waren. Die technischen Details waren für viele Kunden nebensächlich, solange sie online präsent waren. Dennoch konnten wir die meisten Kunden durch die unbestreitbaren Vorteile überzeugen, eine Neukonzeption ihrer Projekte in Betracht zu ziehen.

Es gab nur einen einzigen Kunden, bei dem wir gezwungen waren, die Dienstleistung von unserer Seite aus zu beenden. Seine Homepage wurde mit HTML-Frames realisiert und die Preise waren noch in Deutsche Mark angegeben.

Trotz aller Herausforderungen bot uns dieses Projekt viele Lernmöglichkeiten. Wir haben über die langfristige Systemwartung, die Etablierung von Kundendienstprozessen und den Einsatz von langlebigen Softwaremodulen hinaus viel gelernt. Eine meiner wesentlichen Erkenntnisse ist, dass ich zukünftig keine proprietäre Microsoft-Software mehr nutze. Die erheblichen Lizenzkosten, mangelhaften Sicherheitsupdates und umständliche Administration machen ihre Verwendung für mich unwirtschaftlich. Proprietäre Software ohne Zugriff auf den Quellcode nutzen wir im Allgemeinen nicht mehr für Kundenprojekte.

Heute vertrauen wir auf Linux-basierte Systeme mit Long-Term-Support. Diese bieten uns die nötige Flexibilität und Sicherheit und helfen gleichzeitig, unsere Kosten zu senken. Das bloße Nutzen von Linux-basierten Systemen bringt noch keinen direkten Vorteil. Aber die Skaleneffekte, wie die effizientere Nutzung von Hardware-Ressourcen, weniger Overhead im Software-Stack und eine vereinfachte Administration, sind für uns von wesentlicher Bedeutung.

Die Migration von mehr als 100 Kunden war sicherlich keine einfache Aufgabe. Durch den Übergang zu unserem neuen CMS können wir unseren Kunden nun ein zeitgemäßes, effizienteres und benutzerfreundlicheres Erlebnis bieten. Wir haben unseren Kunden ein leistungsfähiges Tool zur Verfügung gestellt, um ihr Umsatzpotenzial zu optimieren. Jetzt sind wir an einem Punkt angelangt, an dem wir unseren Kunden angemessene Preise anbieten können, während wir gleichzeitig wieder Gewinne erzielen.

Und natürlich, wir haben uns darauf konzentriert, die Fehler der Vergangenheit nicht zu wiederholen. Unser neues CMS ist nun nach einem Plattformansatz konzipiert. Alle Inhalte, seien es Seiten, Blog-Beiträge oder individuelle Datenbanken, können in jedes gewünschte Datenformat exportiert werden. Wir haben aus unseren Erfahrungen gelernt und vermeiden nun, die Daten unserer Kunden in einem proprietären Tresor einzuschließen.

Wir agieren nicht nur als Dienstleister für unsere eigenen Kunden, sondern leisten auch Unterstützung für andere Unternehmen in unserer Branche. Hierbei konnten wir feststellen, dass viele Firmen für die Online-Auftritte ihrer Kunden auf ungeeignete Lösungen zurückgreifen. Ein gutes Beispiel hierfür ist die Nutzung von WordPress. Die Entscheidung für WordPress beruht oft weniger auf den spezifischen Bedürfnissen des Kunden, als vielmehr auf dem Wunsch der Agentur, schnell und mit begrenztem technischem Know-how ein Resultat liefern zu können. Das führt jedoch oft zu Webseiten, die weder nachhaltig noch skalierbar sind. Viele Projekte sind nach dem Erstaufbau starr und unflexibel und erhalten von Beginn an aufgrund hoher technischer Schulden keine weiteren Aktualisierungen. Spezifische Anforderungen können teils gar nicht vom Dienstleister umgesetzt werden.

Wir ermutigen unsere Partner stets, den notwendigen Aufwand und die erforderliche Expertise zu investieren, um nachhaltige Lösungen anzubieten. Dies dient nicht nur der Verbesserung der abgelieferten Qualität für den Kunden, sondern hilft auch dem Dienstleister dabei, interne Risiken und Arbeitsaufwand erheblich zu reduzieren.

Darüber hinaus ist es wichtig zu bedenken, dass viele technische Tools, wie beispielsweise WordPress Pagebuilder oder Baukastensysteme, primär auf Endanwender ausgerichtet sind. Als technischer Dienstleister sollte man in der Lage sein, mehr zu leisten, als lediglich Endanwender-Software zu bedienen. Andernfalls besteht die Gefahr, dass man schnell unter den eigenen technischen Schulden des Projekts begraben wird.