Webentwicklung mit Altlasten: sanieren oder neu bauen?

Zusammenfasst: Der Artikel erklärt, dass die Entscheidung zwischen Sanierung und Neubau in der Webentwicklung nicht vom Aussehen oder Framework abhängt, sondern von Stabilität, Code-Qualität, Schnittstellen, Datenflüssen und den realen Arbeitsabläufen im Unternehmen. Eine Sanierung lohnt sich, wenn Kernlogik, Datenmodell und Integrationen noch tragfähig sind und gezielte Modernisierungen ausreichen. Ein Neubau ist sinnvoller, wenn Architektur, Sicherheit, Wartbarkeit, Barrierefreiheit oder Performance grundlegende Probleme verursachen und jede Änderung neue Fehler auslöst. Empfohlen wird eine technische Vorprüfung mit Fokus auf geschäftskritische Funktionen, Hosting, Migration, Redaktionsprozesse und Risiken, damit Unternehmen in Österreich belastbar statt nach Bauchgefühl entscheiden.

Legacy-Code fällt selten im Kick-off auf. Er fällt auf, wenn das Formular am Freitagabend keine Daten mehr speichert, wenn die API nach einem kleinen Update still stirbt oder wenn niemand mehr sagen kann, warum ein Button erst nach dem dritten Klick reagiert. Genau dort beginnt die eigentliche Arbeit in der Webentwicklung: nicht bei Farben oder Animationen, sondern bei der Frage, ob ein Bestandsystem noch tragfähig ist.

Für viele Unternehmen in Österreich ist das keine akademische Diskussion. Da gibt es gewachsene Portale, alte CMS-Installationen, Sonderlogik aus mehreren Entwicklungsphasen und Workarounds, die seit Jänner niemand dokumentiert hat. Alles läuft irgendwie. Bis eine neue Funktion dazukommt, Barrierefreiheit nachgerüstet werden muss oder die Ladezeit auf mobilen Geräten kippt. Dann steht die nüchterne Entscheidung im Raum: sanieren oder neu bauen?

Die Antwort hängt nicht an einem Framework und auch nicht an der Frage, ob der alte Code ‘schön’ ist. Es geht um Wartung, Datenbank-Logik, Schnittstellen, Redaktionsabläufe, Risiken im Echtbetrieb und darum, wie viel Geschäft an diesem System hängt. Wer Webentwicklung in Wien oder anderswo in Österreich einkauft, braucht an dieser Stelle keine Show, sondern einen technischen Blick mit Hausverstand.

Zuerst zählen Abhängigkeiten in der Webentwicklung, nicht Oberflächen

Ein altes System wird oft falsch beurteilt, weil zuerst das Frontend diskutiert wird. Die Oberfläche ist aber meistens nur der sichtbare Teil des Problems. Spannender ist, was darunter hängt: ERP-Anbindung, CRM-Synchronisation, Rollenmodell, Import-Logik vom Wochenende, alte Zahlungsanbieter, PDF-Generatoren, Benutzerrechte, Tracking-Skripte und eine Datenbank, die über Jahre mit Sonderfeldern zugeschüttet wurde.

Wenn wir ein Bestandsystem prüfen, schauen wir zuerst auf vier Dinge:

• Technische Stabilität: Gibt es reproduzierbare Fehler oder nur Glück im Echtbetrieb?
• Code-Qualität: Ist die Logik lesbar oder lebt alles in einer Datei mit Seiteneffekten?
• Schnittstellen: Welche Anbindungen dürfen bei einer Änderung auf keinen Fall kippen?
• Pflege im Alltag: Können Redakteure und Teams sauber arbeiten oder basteln alle an Workarounds herum?

Genau an diesem Punkt kippt die Wahrnehmung oft. Eine Website kann optisch halbwegs okay wirken und technisch trotzdem kurz vor dem Bauchfleck stehen. Umgekehrt kann ein unspektakuläres System intern sauber gebaut sein und mit überschaubarer Sanierung noch lange halten. Wer sich für den technischen Unterbau von Projekten in Ihrer Webentwicklung in Wien interessiert, findet im Beitrag Webentwicklung Wien Hands-on: Code mit Handschlagqualität einen passenden Blick auf Architektur, Wartung und Umsetzung.

Wann Sanierung in der Webentwicklung die bessere Entscheidung ist

Sanieren zahlt sich aus, wenn der Kern noch gesund ist. Das klingt banal, spart aber viel Geld und Nerven. Wenn Datenmodelle logisch aufgebaut sind, die wichtigsten Schnittstellen stabil laufen und die Geschäftslogik korrekt arbeitet, muss nicht alles weg. Dann geht es eher um gezielte Eingriffe: Frontend erneuern, Datenbank-Abfragen bereinigen, alte Komponenten ersetzen, Deployment aufräumen, Caching sauber einführen oder eine Headless-CMS-Anbindung nachrüsten.

Typische Fälle für Sanierung:

Die Fachlogik ist wertvoll, aber der Rahmen ist veraltet

Viele Portale haben über Jahre Regeln gesammelt, die nicht in einem Standard-Plugin stecken. Freigaben, Preislogiken, Rollen, Exporte, interne Prüfschritte. Das neu zu bauen klingt am Anfang verlockend, wird aber schnell teuer, wenn jedes Detail wieder entdeckt werden muss.

Das Problem sitzt im Frontend, nicht im Kern

Langsame Ladezeiten kommen oft von aufgeblähten Themes, alten JavaScript-Paketen oder schlechtem Rendering. Die Geschäftslogik im Backend kann trotzdem in Ordnung sein. Dann ist eine technische Sanierung sinnvoller als ein Komplettabriss.

Die Übersiedlung von Daten wäre riskanter als die Reparatur

Wenn Jahre an Inhalten, Bestellungen oder Benutzerkonten im System liegen, ist Datenmigration kein Nebenjob. Ein falsches Mapping und Sie suchen wochenlang nach schiefen Datensätzen. Da kann eine kluge Sanierung der vernünftigere Weg sein.

Sanierung heißt aber nicht Kosmetik. Wer nur neue Farben auf altes Chaos legt, kauft sich die Probleme einfach später wieder ein.

Wann ein Neubau in der Webentwicklung ehrlicher ist

Es gibt Systeme, die man nicht mehr retten sollte. Das merkt man nicht daran, dass sie alt sind, sondern daran, dass jede kleine Änderung neue Fehler produziert. Wenn eine Anforderung drei Workarounds, zwei Sondertabellen und eine stille Hoffnung braucht, ist das kein Fundament mehr.

Ein Neubau ist oft die bessere Entscheidung, wenn diese Punkte zusammenkommen:

• Die Architektur blockiert Weiterentwicklung. Neue Features reißen an alten Abhängigkeiten.
• Die Wartung ist wirtschaftlich nicht mehr sinnvoll. Jeder Eingriff wird zur Fehlersuche im Nebel.
• Sicherheits- und Update-Probleme häufen sich. Alte Plugins oder Frameworks lassen sich kaum noch verantworten.
• Barrierefreiheit und Performance sind nur mit Gewalt nachrüstbar. Dann baut man doppelt.
• Die Redaktions- oder Arbeitsabläufe passen nicht mehr zum Unternehmen. Das System zwingt Teams zu Umwegen.

Ein Klassiker aus der Praxis: günstiges Template, viele Plugins, mehrere Vorentwickler, keine klare Dokumentation. Im Demo-Modus schaut alles brauchbar aus. Im Echtbetrieb kommen dann kaputte Abhängigkeiten, CSS-Ausnahmen ohne Ende und Seiten, die sich mit jedem Plugin-Update anders verhalten. Billig war das nur beim Start.

Wenn ein Neubau im Raum steht, muss die Entscheidung sauber gegen die laufenden Kosten der Altlast gehalten werden. Genau dort hilft auch ein Blick auf Webentwicklung Kosten 2026: Was eine professionelle Website, Webanwendung oder ein Relaunch in Österreich wirklich kostet. Nicht wegen einer Zahlenschlacht, sondern weil dort sichtbar wird, wie sich Architektur, Wartung und Relaunch-Aufwand gegenseitig beeinflussen.

Die eigentliche Entscheidung fällt in einer technischen Vorprüfung der Webentwicklung

Ob Sanierung oder Neubau sinnvoll ist, entscheidet sich nicht in einer Bauchgefühl-Runde. Es braucht eine nüchterne Vorprüfung. Die ist kein Papier für die Schublade, sondern eine kleine technische Bestandsaufnahme mit klarer Empfehlung.

In der Praxis arbeiten wir dabei meist in dieser Reihenfolge:

1. Geschäftsrelevante Funktionen erfassen

Was darf auf keinen Fall ausfallen? Bestellung, Login, Kundenportal, interne Freigaben, Produktsuche, Formularlogik. Wer hier ungenau ist, plant an der Realität vorbei.

2. Schnittstellen und Datenflüsse in der Webentwicklung aufzeichnen

Woher kommen Daten, wohin gehen sie, wer pflegt sie? Viele Probleme in der Webentwicklung entstehen nicht im Frontend, sondern an stillen Übergaben zwischen Systemen. Ein ergänzender Überblick findet sich im Beitrag Was Wartungsverträge in der Webentwicklung leisten, der zeigt, wie laufende Betreuung Stabilität sichert.

3. Code und Hosting technisch prüfen

Wie alt sind die Komponenten? Gibt es Tests, Logging, Deployments, Backups? Läuft alles nur, weil jemand im Team noch weiß, welchen Server man besser nicht angreift?

4. Redaktions- und Teamprozesse bewerten

Ein System kann technisch stabil sein und im Alltag trotzdem teuer werden, wenn jede kleine Inhaltsänderung Entwicklerzeit frisst.

5. Migrationsrisiko gegen Sanierungsrisiko stellen

Beides hat Aufwand. Beides hat Risiken. Wer nur die Neubau-Kosten anschaut, vergisst oft die versteckten Kosten des Weiterwurstelns.

Barrierefreiheit, SEO und Performance sind Teil der Architektur in der Webentwicklung

Bei Altlasten werden WCAG, technische SEO und Performance gern als spätere Aufgaben behandelt. Das ist einer der teureren Denkfehler. Wenn die Struktur schief ist, hilft Ihnen kein schneller Accessibility-Patch und auch kein SEO-Text auf einer langsamen Seite.

Barrierefreiheit beginnt bei sauberem HTML, klaren Formularen, Tastatur-Bedienbarkeit und sinnvollen Komponenten. Technische SEO beginnt bei Rendering, Ladeverhalten, interner Verlinkung, Weiterleitungen und einer Struktur, die Suchmaschinen überhaupt verstehen können. Performance hängt an Asset-Größen, Rendering-Pfaden, Datenbank-Abfragen und oft an Kleinigkeiten, die sich summieren.

Gerade bei einem Relaunch von Altlasten ist das kritisch. Wenn Sie umziehen und Weiterleitungen, Metadaten, URL-Struktur und Inhaltsbeziehungen nicht mitdenken, verlieren Sie Sichtbarkeit und erzeugen intern Chaos. Wer vor dem Go-live noch eine technische Checkliste braucht, findet in Webentwicklung: Top Fehler vor dem Launch einige Punkte, die in solchen Projekten regelmäßig übersehen werden. Außerdem lohnt ein Blick auf Webentwickler und Meta-Frameworks: Wie sie die Webentwicklung revolutionieren, um aktuelle technische Entwicklungen einzuordnen.

So sieht eine brauchbare Umsetzung in Österreich aus

Für mittelständische Unternehmen und Start-ups in Österreich muss die Entscheidung nachvollziehbar bleiben. Kein Mensch braucht ein Architektur-Diagramm mit fünfzig Kästchen, wenn am Ende unklar ist, was heuer konkret gebaut wird. Besser ist ein klarer Umsetzungsplan mit Etappen.

Ein brauchbarer Weg sieht oft so aus:

• kritische Altlasten zuerst absichern
• Risiko-Bereiche isolieren
• Datenmigration früh testen
• UX/UI-Design erst auf realen Abläufen aufbauen
• Wartung und Monitoring vor dem Launch mitdenken

Wenn Beratung für Webentwicklung in Wien gesucht wird, ist genau diese Bodenhaftung entscheidend. Ein lokaler Partner mit direktem Draht bringt nicht automatisch bessere Software. Er bringt aber oft schnellere Abstimmung, ehrlicheres Risikomanagement und mehr Handschlagqualität in der Umsetzung. Das ist im Alltag etwas wert, gerade wenn am Wochenende plötzlich eine Anbindung klemmt oder die Datenbank-Logik nach einem Import schiefgeht.

DEV sense arbeitet genau an solchen Punkten: gewachsene Systeme prüfen, technische Schulden offenlegen und eine Umsetzung aufsetzen, die nicht nur beim Launch gut aussieht, sondern auch später noch angreifbar bleibt.

Häufig gestellte Fragen

Woran erkenne ich, ob ein Legacy-System noch sanierbar ist?

Wenn die Kernlogik stabil läuft, die Daten konsistent sind und Schnittstellen nicht bei jeder Kleinigkeit kollabieren, ist Sanierung oft realistisch. Wenn dagegen schon kleine Änderungen unerwartete Nebeneffekte auslösen und niemand mehr die Architektur erklären kann, spricht viel für einen Neubau.

Ist ein Neubau immer teurer als eine Sanierung?

Nicht automatisch. Eine billige Sanierung kann teurer werden, wenn alte Probleme nur verschoben werden und jede Erweiterung wieder Sonderaufwand erzeugt. Ein Neubau kostet am Anfang mehr Konzentration, kann aber im Betrieb deutlich sauberer und wartbarer sein.

Was passiert mit bestehenden Daten bei einem Neubau?

Die Übersiedlung von Daten ist fast immer ein eigenes Teilprojekt. Inhalte, Benutzerkonten, Bestellungen oder Dokumente müssen geprüft, bereinigt und in das neue Modell überführt werden. Genau dort entstehen viele versteckte Risiken, wenn das zu spät eingeplant wird.

Wie stark beeinflussen Barrierefreiheit und SEO die Entscheidung?

Ziemlich stark. Wenn ein Altsystem semantisch schlecht aufgebaut ist, auf mobilen Geräten schwächelt und bei Formularen oder Navigation grundlegende WCAG-Hürden hat, wird Nachrüstung schnell teuer. Dann ist ein Neubau oft sauberer als Flickwerk.

Wann lohnt sich eine externe technische Prüfung vor der Entscheidung?

Sobald mehrere Schnittstellen, ein Kundenportal, alte Plugins oder komplizierte Workflows im Spiel sind. Eine nüchterne Vorprüfung spart Diskussionen, weil nicht Geschmack gegen Geschmack steht, sondern Risiko gegen Aufwand. DEV sense wird genau für solche Vorab-Bewertungen oft beigezogen, gerade wenn intern schon klar ist, dass das Bauchgefühl allein nicht mehr reicht.

Ist WordPress bei Altlasten automatisch ein Problem?

Nein. Das Problem ist selten der Name des Systems. Das Problem sind unklare Erweiterungen, schlechte Code-Qualität, Plugin-Wildwuchs und fehlende Wartung. Es gibt saubere WordPress-Projekte und es gibt Installationen, die man lieber nicht mehr angreift.

Jetzt sauber entscheiden statt weiter flicken

Die Frage ‘sanieren oder neu bauen’ lässt sich nur technisch ehrlich beantworten. Nicht mit Vorlieben, nicht mit Tool-Hypes und schon gar nicht mit einem schnellen Blick auf die Startseite. Relevant sind Architektur, Datenflüsse, Code-Qualität, Anbindungen, Wartung und die Abläufe Ihres Teams im Alltag.

Wenn der Kern eines Systems gesund ist, kann Sanierung viel Sinn ergeben. Dann geht es um gezielte Eingriffe, nachvollziehbare Prioritäten und eine schrittweise Modernisierung. Wenn das Fundament aber bröckelt, jede Änderung neue Schäden auslöst und Barrierefreiheit, SEO oder Performance nur noch mühsam hineingebogen werden, ist ein Neubau oft die ehrlichere Entscheidung.

Webentwicklung ist an dieser Stelle kein schönes Versprechen, sondern technisches Handwerk. Für Unternehmen in Wien, Niederösterreich und im Rest von Österreich zählt vor allem, dass die Entscheidung belastbar ist und die spätere Umsetzung im Echtbetrieb hält. Lieber einmal sauber prüfen als drei Jahre lang teuer flicken. Das spart selten nur Geld. Es spart vor allem Zeit, Nerven und die berüchtigten Freitagabende mit kaputter API.