Software ist kein Auto. Sie kaufen sie nicht einmal und fahren sie zehn Jahre, bis der TÜV Sie zwingt, etwas Neues zu nehmen. Software ist eher wie ein Garten: Sie wächst, sie verändert sich, sie braucht Pflege. Und manche Pflanzen müssen irgendwann raus, damit andere wachsen können.
Wer das ignoriert, merkt es zuerst nicht. Die Plattform läuft ja. Aber die Wartung wird teurer. Updates dauern länger. Neue Features, die woanders in einem Tag eingebaut sind, kosten hier eine Woche. Irgendwann steht die Frage im Raum: Reißen wir alles ein und fangen neu an — oder gibt es einen Weg dazwischen?
Es gibt ihn. Und er heißt nicht “irgendwann mal modernisieren”, sondern: Schritt für Schritt ablösen, im laufenden Betrieb. Genau das, was in der Theorie “agile Entwicklung” heißt — und was in der Praxis Geschäftsmodelle rettet.
Drupal 7 ist nicht Drupal 10 — und das ist auch gut so
Wenn Sie heute hören “Wir nutzen Drupal”, sagt das ungefähr so viel aus wie “Wir fahren ein Auto”. Welche Generation? Welcher Bauzustand? Welche Wartungsstufe? Genau diese Fragen entscheiden, ob die Software für Sie arbeitet — oder gegen Sie.
Drupal hat in den letzten zehn Jahren eine fundamentale Wandlung durchgemacht. Drupal 7, das viele Plattformen noch im Bauch tragen, war ein eigenständiges System mit eigenem Framework, eigenen Konzepten, eigenem Kosmos. Drupal 8, 9 und jetzt 10 setzen auf Symfony als Fundament — ein modernes, weltweit gepflegtes PHP-Framework. Templates werden nicht mehr in PHP geschrieben, sondern in Twig. Abhängigkeiten werden nicht mehr manuell zusammengeklickt, sondern über Composer verwaltet. Strukturen, die früher als “guter Stil” galten, sind heute schlicht falsch.
Das klingt nach Detail, ist aber ein Welten-Unterschied. Eine Codebasis, die nach Drupal-7-Mustern aufgebaut ist und in einem Drupal-10-Projekt wohnt, ist keine fertige Software — sie ist Wartungslast vom ersten Tag an. Jedes neue Feature, jeder Bugfix, jedes Update wird teurer als nötig, weil das Fundament nicht zur Etage passt.
Die gute Nachricht: Diese Wandlung war kein Zufall. Drupal hat sich bewusst geöffnet, professionalisiert, anschlussfähig gemacht. Wer heute in Drupal investiert, investiert nicht in eine Insellösung, sondern in einen weltweit gepflegten Standard. Behörden, Verlage und große Plattformen setzen genau aus diesem Grund auf Drupal.
Code hat einen Lebenszyklus — wie alles andere auch
Jede Software durchläuft die gleichen vier Phasen. Ob Sie sie bewusst gestalten oder nicht — sie passieren ohnehin.
- Geboren werden. Die erste Version entsteht. Es wird gebaut, getestet, ausgeliefert. Vieles ist provisorisch, weil “es laufen muss”. Das ist normal und richtig.
- Wachsen. Neue Anforderungen kommen, neue Funktionen werden eingebaut, mehr Nutzer kommen dazu. Die Codebasis wird größer, komplexer, an manchen Stellen unordentlich.
- Reifen. Irgendwann muss Substanz her. Was provisorisch war, wird stabil. Was sich bewährt hat, wird systematisch. Was Risiken birgt, wird abgesichert. Das ist die Phase, in der professionelle Plattformen entstehen.
- Ablösen. Manche Komponenten haben ausgedient. Bibliotheken werden nicht mehr gepflegt. Module passen nicht mehr zur aktuellen Architektur. Sie werden nicht patchworkartig erweitert, sondern geordnet ersetzt — durch das, was heute Standard ist.
Das Problem bei vielen Projekten: Phase drei und vier finden nicht statt. Der Code wächst, aber er reift nicht. Er bekommt neue Features, aber alte Probleme bleiben drin. Irgendwann steht die Plattform an einem Punkt, an dem jede Erweiterung doppelt so lange dauert wie nötig — und niemand traut sich mehr, etwas zu ändern.
Wer den Lebenszyklus respektiert, hat dieses Problem nicht. Wer ihn ignoriert, zahlt es mit Zinsen.
Fehler gehören dazu — aber es gibt zwei Arten
Niemand baut perfekte Software. Wer das verspricht, sollte misstrauisch machen. Fehler sind Teil des Handwerks, und in einem ehrlichen Entwicklungsprozess passieren sie ständig. Aus den richtigen Fehlern lernt man — sie machen das Team besser, das Produkt stabiler, den nächsten Schritt klüger.
Es gibt aber zwei Arten von Fehlern, und nur eine davon ist akzeptabel.
Die erste Art sind Lern-Fehler. Ein experimentelles Modul wählen, das nach drei Monaten zeigt, dass es nicht trägt. Eine Architektur-Entscheidung treffen, die später überarbeitet werden muss, weil die Anforderungen sich verändert haben. Eine externe Schnittstelle nutzen, die später nicht mehr unterstützt wird. Solche Fehler sind die Realität jeder echten Entwicklung. Wer sie ehrlich kommuniziert und konsequent korrigiert, baut Vertrauen auf.
Die zweite Art sind strukturelle Fehler. Eine Codebasis nach veralteten Mustern bauen und sie als modern verkaufen. Bekannte Wartungsprobleme nicht ansprechen. Versprechen geben, die das technische Fundament nicht halten kann. Diese Fehler sind keine Lernerfahrung, sondern ein Bruch in der Vertrauensbeziehung — egal ob bewusst oder aus Unkenntnis.
Hier liegt eine wichtige Linie, an der wir uns als Agentur sehr klar orientieren: Wir verstecken Probleme nicht. Wenn eine Plattform an einem Punkt ist, an dem die einfachen Antworten teurer werden als die ehrlichen, sagen wir das. Und wir zeigen einen Weg nach vorn, der für das Geschäft funktioniert — nicht nur für das Projekt-Ticket.
Schritt für Schritt ablösen — die agile Antwort auf Modernisierung
Wenn eine Plattform an dem Punkt steht, an dem das Fundament nicht mehr trägt, gibt es traditionell zwei Wege. Beide haben einen Namen, aber nur einer davon hat in den letzten Jahren auch Ergebnisse geliefert.
Der erste Weg heißt Big-Bang-Rewrite. Alles wegwerfen, neu bauen, irgendwann live schalten. Das klingt sauber, ist aber in der Praxis selten erfolgreich. Während die neue Plattform entsteht, läuft die alte weiter — mit allen Problemen. Neue Features werden zurückgestellt, weil sie ja “in der neuen Version sowieso anders gemacht werden”. Das Geschäft wartet. Und am Ende ist das neue System oft nicht besser als das alte, sondern nur anders.
Der zweite Weg ist schrittweise Ablösung im laufenden Betrieb. Komponente für Komponente wird modernisiert, während die Plattform weiterläuft. Die alte Architektur und die neue existieren nebeneinander, und Stück für Stück wandert die Funktionalität in das neue Fundament. Das hat drei klare Vorteile aus Geschäftssicht:
- Die Investition bleibt erhalten. Was funktioniert, wird nicht weggeworfen, sondern überführt. Sie zahlen nicht zweimal für dieselbe Funktion.
- Die Einnahmen laufen weiter. Kunden merken nicht, dass im Hintergrund modernisiert wird. Bestellungen, Anmeldungen, Buchungen funktionieren — durchgehend.
- Das Risiko verteilt sich. Statt eines großen Live-Gangs gibt es viele kleine. Jeder Schritt ist überschaubar, testbar, zurückrollbar. Was nicht funktioniert, wird korrigiert, bevor das nächste Stück angepackt wird.
Genau so sieht agile Entwicklung in der Geschäftspraxis aus. Nicht als Buzzword, nicht als Methodenkoffer, nicht als Zertifikat. Sondern als Prinzip: In kleinen Schritten Wert liefern, kontinuierlich besser werden, niemals den laufenden Betrieb opfern.
Wir haben diesen Ansatz nicht nur bei Drupal-Projekten erfolgreich angewendet. Auch bei Laravel-basierten Plattformen funktioniert er — etwa beim Wechsel von einem Admin-Panel zu einem anderen ohne Live-Pause.
Praxisbeispiel: SteBoFo
SteBoFo.de ist eine Marketplace-Plattform, auf der Händler und Hersteller Möbel, Wohnaccessoires, Messemöbel, Ausstellungsstücke und Restposten direkt an Endkunden verkaufen — mit eigener Preishoheit und einer dedizierten Zahlungsstrecke pro Anbieter. Hinter dem Projekt steht ein Branchenprofi mit Jahrzehnten Erfahrung im Möbelvertrieb und einem klaren Wachstumsplan.
Mitten in der Entwicklung kam SteBoFo zu redbeed. Die Plattform war zu großen Teilen aufgebaut, das Design stand, erste Anbieter waren angesprochen. Aber technisch zeigten sich Spannungen, die mit jedem Tag teurer geworden wären — eine Codebasis, die zwar in einer aktuellen Drupal-Version lief, aber an vielen Stellen nicht so aufgebaut war, wie es moderne Drupal-10-Projekte verlangen. Genau die Art von Diskrepanz, die wir zu Beginn dieses Artikels beschrieben haben: Drupal 7 ist nicht Drupal 10, und alte Muster im neuen System bedeuten Wartungslast.
Wir haben die Codebasis modernisiert, die Multi-Vendor-Architektur stabilisiert und eine custom Stripe-Anbindung pro Anbieter zuverlässig umgesetzt. Schritt für Schritt, im laufenden Projekt, ohne Neuanfang. Heute ist SteBoFo live. Anbieter registrieren sich, stellen ihre Artikel ein, verbinden ihr Zahlungskonto und verkaufen direkt. Die Plattform ist auf einer Codebasis, die mit jedem zusätzlichen Anbieter mitwachsen kann.
Das Entscheidende: Der Kunde hat seine Investition nicht verloren. Was bereits funktioniert hat, wurde übernommen und stabilisiert. Was nicht trug, wurde geordnet ersetzt. Der Live-Gang kam nicht in zwei Jahren — er kam in den nächsten Wochen.
Fazit: Software-Lebenszyklus ist Geschäftslogik
Die Frage “Neu bauen oder weiterleben lassen?” ist keine Tech-Frage. Sie ist eine Entscheidung mit klaren Geschäftsfolgen — Kosten, Risiko, Time-to-Market, Wettbewerbsposition. Wer den Lebenszyklus seiner Software respektiert, schützt seine Investition und bleibt handlungsfähig. Wer ihn ignoriert, baut sich Wartungskosten auf, die irgendwann nicht mehr beherrschbar sind.
Die ehrliche Antwort auf den Modernisierungsdruck heißt fast nie “alles neu”. Sie heißt: schrittweise ablösen, im laufenden Betrieb, mit klarer Roadmap und einem Team, das sowohl die alte Codebasis versteht als auch das neue Fundament beherrscht. Das ist agile Entwicklung in der Geschäftspraxis — und es ist meistens deutlich günstiger als das, was viele Plattform-Inhaber befürchten.
Wenn Ihre Plattform an einem Lebenszyklus-Punkt steht, an dem die nächsten Schritte unklar sind — oder wenn Sie das Gefühl haben, dass Ihre Codebasis schneller wächst als sie reift — sprechen Sie mit uns. Wir schauen uns das gemeinsam an, ehrlich und ohne Drama. Manchmal ist die richtige Antwort, dass nichts geändert werden muss. Manchmal ist sie, dass eine geordnete Modernisierung längst überfällig ist. Wichtig ist nur, dass die Entscheidung auf Fakten beruht — und nicht auf der Angst vor dem Aufwand.