Warum wir ein altes WordPress-Theme nicht zu Bootstrap konvertiert haben
Vor ein paar Jahren stand ich vor einer typischen Entscheidung. Unser Kundenportal lief auf einem selbstgestrickten Theme, das auf einem alten CSS-Framework basierte. Der Code war eine Mischung aus Fragmenten von 2014 und individuellen Anpassungen. Das funktionierte, aber jeder neue Entwickler brauchte Wochen, um sich einzuarbeiten. Ein Kollege schlug vor, das Ganze auf Bootstrap umzustellen. „Das ist der Standard”, sagte er. „Das macht alles einfacher.” Also setzten wir uns hin und analysierten den Aufwand. Das Ergebnis war überraschend: Wir taten es nicht. Stattdessen gingen wir einen anderen Weg und implementierten nur einen Teil des Bootstrap-Frameworks, und zwar genau so, wie es auf dieser Bootstrap-Seite beschrieben wird. Der Grund: Ein kompletter Umbau hätte unsere Liefertermine gesprengt.
Meine Erfahrung in den letzten zehn Jahren hat mir gezeigt: Framework-Entscheidungen sind nie nur technisch. Sie sind auch menschlich und organisatorisch. Deshalb möchte ich heute erklären, warum eine Migration nicht immer die beste Lösung ist, auch wenn alle darüber reden.
Das Problem mit vollen Migrationen
Ein vollständiges Umschreiben klingt sauber. In der Praxis entstehen dabei neue Fehler. Wir hatten ein Theme mit über 30 Individualseiten, jede mit eigenen CSS-Klassen. Einfach alles auf Bootstrap-Klassen umzuschreiben, hätte bedeutet, jede einzelne Seite durchzugehen. Das ist kein Sprint, das ist ein Marathon. Dazu kommt: Das alte Theme war responsive genug für 95 Prozent der Nutzer. Die restlichen fünf Prozent waren Tablets mit seltenen Bildschirmgrößen. Der Aufwand für eine perfekte Bootstrap-Umsetzung stand in keinem Verhältnis zum Nutzen. Manchmal ist gut genug wirklich gut genug.
Warum wir trotzdem Bootstrap-Komponenten nutzen
Die Entscheidung gegen eine Vollmigration bedeutete nicht, dass wir Bootstrap komplett ignorierten. Wir haben uns auf die Teile konzentriert, die uns echte Vorteile brachten: das Grid-System und die Utility-Klassen für Abstände. Ein Kollege hatte die Idee, nur die CSS-Datei mit diesen Modulen zu importieren. Das war schnell gemacht. Wir sparten uns dadurch stundenlanges Herumrechnen von Rändern und Abständen im alten System. Gleichzeitig behielten wir unsere eigene Typografie und Farbpalette. Bootstrap wurde so zum Werkzeug, nicht zum Meister.
Die Wartung entscheidet, nicht das Framework
Als Freiberufler arbeite ich oft an Legacy-Projekten. Der größte Fehler, den ich sehe, ist der Glaube, ein neues Framework löse alle Wartungsprobleme. Das tut es nicht. Ein Bootstrap-Theme, das keiner versteht, ist genauso schlimm wie ein altes Theme ohne Struktur. Wir haben daher ein internes Wiki geschrieben. Dort steht, welche Bootstrap-Komponenten wir nutzen und wie wir sie anpassen. Jeder neue Entwickler bekommt das Dokument am ersten Tag. Das hilft mehr als irgendein Framework-Wechsel. Das Ding ist: Ein Framework ist nur so gut wie die Dokumentation und die Disziplin des Teams.
Drei konkrete Vorteile eines partiellen Einsatzes
- Sie migrieren nur das, was Zeit spart, nicht das, was glänzt. Das Grid-System allein reduziert den CSS-Code um 40 Prozent in den meisten Projekten.
- Sie vermeiden den „wir-müssen-alles-neu-machen”-Reflex. Das spart Geld und Nerven beim Kunden.
- Sie lernen die Framework-Interna besser kennen, weil Sie selektiv vorgehen. Nach drei Monaten wissen Sie genau, welche Bootstrap-Klassen Sie wann brauchen.
Wann eine Vollmigration doch Sinn ergibt
Es gibt Fälle, in denen der komplette Umbau alternativlos ist. Ich erlebte das letztes Jahr bei einem Kunden, dessen Theme auf veralteten jQuery-Plugins basierte, die nicht mehr sicher waren. Da half kein partieller Einsatz. Da musste alles raus. Oder wenn Sie von Grund auf ein neues Projekt starten, dann starten Sie gleich auf einem soliden Framework. Aber für 80 Prozent der Bestandsprojekte reicht ein gemischter Ansatz. Entscheiden Sie nicht nach Hype, sondern nach konkreten Problemen: Ist die Ladezeit zu hoch? Dann optimieren Sie nur die Performance. Ist das Layout inkonsistent? Dann vereinheitlichen Sie nur die Raster.
Die menschliche Seite des Codens
Was viele vergessen: Ein Framework-Wechsel bedeutet Lernkurve für Ihr Team. Ein guter Frontend-Entwickler kann Bootstrap in einer Woche. Aber ein Team, das jahrelang mit einem eigenen System arbeitete, braucht Monate, um die Bootstrap-Denke zu verinnerlichen. In dieser Zeit sinkt die Produktivität. Wir haben das bei einem anderen Projekt erlebt: Drei Monate nach dem Umbau war keiner zufrieden. Die alten Workflows waren weg, die neuen nicht etabliert. Erst nach einem halben Jahr kam der Effizienzgewinn. Fragen Sie sich: Können Sie sich diese Verzögerung leisten?
Meine Checkliste vor jeder Framework-Entscheidung
- Liste alle konkreten Probleme auf, die das aktuelle Setup hat (z. B. nicht responsive, zu langsam, schwer zu erweitern).
- Prüfe jedes Problem auf eine schnelle Lösung ohne Vollmigration. Ein partieller Framework-Import reicht oft.
- Frage dein Team, wie viel Zeit sie für den Umbau brauchen. Multipliziere das mit drei (optimistische Schätzung).
- Berechne die Kosten gegen den Nutzen über zwei Jahre. Ein Framework ist kein Zauberstab, sondern ein Werkzeug.
- Dokumentiere die Entscheidung schriftlich. So vermeidest du in einem Jahr die Frage „Warum haben wir das nicht gemacht?”
Letzten Endes geht es um ein Gleichgewicht. Ich nutze Bootstrap selbst in fast jedem Projekt. Aber ich habe aufgehört, es als Allheilmittel zu sehen. Jedes Team, jedes Projekt, jeder Code hat seine eigene Geschichte. Die beste Entscheidung ist die, die Sie in einem Jahr noch vertreten können, ohne mit den Schultern zu zucken. Unser alter Theme-Code lebt noch heute. Und er funktioniert. Das zählt mehr als ein sauberes Framework-Label im Repository.
