Wir haben für uns selbst eine Unternehmenswebseite als Headless-CMS-Website mit Projekt-Rechner neu aufgebaut. Das Projekt umfasste die Greenfield-Entwicklung von Architektur und Design, die Umsetzung der Website, ein Headless CMS für die Inhaltsverwaltung sowie Hosting und Bereitstellung in Azure. So entstand eine moderne Grundlage für Webinhalte und die Pflege redaktioneller Inhalte getrennt von der sichtbaren Website.
Ausgangslage
Bei diesem Projekt handelte es sich um ein eigenes Vorhaben von ballmüller solutions. Die Aufgabe war, eine Unternehmenswebseite mit Projekt-Rechner umzusetzen und dafür eine neue technische und gestalterische Grundlage zu schaffen.
Aus dem Projektauftrag ergab sich eine Greenfield-Situation: Architektur und Design wurden neu entwickelt. Außerdem sollte die Website mit einem Headless CMS aufgebaut werden, damit Inhalte getrennt von der eigentlichen Darstellung verwaltet werden können.
Lösung
Wir haben die Website als neues System von Grund auf konzipiert und umgesetzt. Dazu gehörten Architektur und Design, die technische Realisierung der Website, die Einbindung des Headless CMS Strapi sowie der Projekt-Rechner als Teil der Anwendung.
Für den Betrieb haben wir das Hosting mit Docker und Azure aufgebaut. Die Auslieferung der Software wurde mit CI/CD über Azure DevOps organisiert. CI/CD bedeutet, dass Änderungen automatisiert gebaut, geprüft und bereitgestellt werden. Das Projekt lief von August 2022 bis Juni 2023 mit einer Teamgröße von 1.
Ergebnis
Geliefert wurde eine Unternehmenswebseite mit Headless CMS und Projekt-Rechner. Das Projekt wurde abgeschlossen.
Die Laufzeit betrug 11 Monate. Der Projektzeitraum reichte von August 2022 bis Juni 2023.
Technik
Zum Einsatz kamen folgende Technologien:
- ASP.NET Core für die Webanwendung
- Blazor WebAssembly für den im Browser laufenden Anwendungsteil
- Strapi als Headless CMS für die Inhaltsverwaltung
- MySQL als Datenbank
- Docker für den Betrieb in Containern
- Azure Static Web Apps für die Bereitstellung von Webinhalten
- Azure Container Apps für den Betrieb von Container-Anwendungen
- Azure DevOps für CI/CD, also für automatisierte Build- und Bereitstellungsprozesse
- TailwindCSS für das Styling der Benutzeroberfläche
Warum eine Headless-CMS-Website für solche Projekte passt
Eine Headless-CMS-Website eignet sich besonders dann, wenn Inhalte unabhängig von der sichtbaren Website gepflegt werden sollen. Ein Headless CMS verwaltet Texte, Bilder und andere Inhalte zentral und stellt sie über definierte Schnittstellen bereit; die Darstellung im Browser wird davon getrennt entwickelt. Das ist oft sinnvoll, wenn Unternehmen ihre Inhalte flexibel strukturieren und die Website technisch eigenständig weiterentwickeln möchten.
Für Vorhaben dieser Art ist die Trennung von Inhalt, Anwendung und Betrieb häufig ein pragmatischer Ansatz. Redaktion und Entwicklung arbeiten damit nicht am selben Teil des Systems. Inhalte können im CMS gepflegt werden, während die eigentliche Website als eigenständige Anwendung entsteht. Das hilft besonders dann, wenn Design, Interaktion oder zusätzliche Funktionen über eine klassische Standardwebsite hinausgehen.
Auch aus Sicht der Erweiterbarkeit bietet dieser Ansatz Vorteile. Wenn später weitere Bausteine hinzukommen, etwa Formulare, Rechner, Portale oder Anbindungen an andere Systeme, bleibt die Struktur meist klarer, als wenn alles in einem monolithischen System zusammenliegt. Monolithisch bedeutet in diesem Zusammenhang, dass viele Aufgaben in einer einzigen Anwendung und oft auch in einem einzigen technischen Produkt gebündelt werden.
Für den Betrieb ist außerdem wichtig, dass eine Headless-CMS-Website verschiedene Teile mit unterschiedlichen Anforderungen haben kann. Der öffentliche Webteil soll typischerweise schnell, stabil und einfach auslieferbar sein. Das CMS benötigt dagegen geschützte Zugänge, Rollen und einen klar geregelten Redaktionsprozess. Deshalb wird in solchen Projekten oft auch der Betrieb getrennt betrachtet, etwa für Website, CMS und ergänzende Dienste. Mehr dazu gehört meist zur Webentwicklung und zum Hosting und Betrieb.
Entscheider sollten dabei vor allem prüfen, wie stark Inhalte, Funktionen und Prozesse voneinander getrennt sein sollen. Nicht jede Website braucht ein Headless CMS. Wenn aber individuelle Anforderungen, eine eigene Anwendungsschicht oder zusätzliche Funktionen im Vordergrund stehen, ist dieser Ansatz oft gut geeignet. Wichtig ist eine saubere Informationsarchitektur. Damit ist gemeint, dass Inhalte, Seitentypen, Beziehungen und Pflegeprozesse vor der Umsetzung klar beschrieben werden.
Wie solche Projekte typischerweise umgesetzt werden
Bei einer individuellen Website oder Portal-Lösung beginnt ein solches Vorhaben in der Regel mit einer sauberen Klärung des Ziels. Entscheider, Fachseite und Umsetzung sollten zuerst festhalten, welche Inhalte bereitgestellt werden, welche Funktionen nötig sind und welche Abläufe für Redaktion, Freigabe und Betrieb vorgesehen sind. Gerade bei einer Headless-CMS-Website ist diese frühe Abstimmung wichtig, weil Inhaltspflege und Frontend getrennt geplant werden.
Danach folgt üblicherweise das fachliche und technische Konzept. Hier werden Seitenarten, Inhaltsmodelle, Rollen, Schnittstellen, Suchfunktionen und nichtfunktionale Anforderungen beschrieben. Nichtfunktional meint Anforderungen, die nicht direkt eine Fachfunktion darstellen, etwa Wartbarkeit, Sicherheit, Verfügbarkeit oder die Nachvollziehbarkeit von Änderungen. Parallel dazu entsteht meist ein Designkonzept für Struktur, Navigation und Oberflächenverhalten.
In der Umsetzung werden anschließend die einzelnen Bausteine entwickelt und miteinander verbunden. Typisch sind ein Frontend für die sichtbare Website, ein CMS für Inhalte, eine Datenhaltung sowie der geplante Betrieb. Wenn zusätzliche Funktionen wie Formulare, Rechner oder Integrationen hinzukommen, sollten sie nicht nur gestalterisch, sondern auch in ihrer Datenverarbeitung und Pflege durchdacht sein. Für die technische Umsetzung kommen je nach Zielbild häufig individuelle Leistungen in Frage, etwa Webanwendung, Datenhaltung und Betrieb.
Ein wichtiger Teil ist die Bereitstellung. In professionellen Projekten werden Änderungen üblicherweise nicht manuell auf Server kopiert, sondern über automatisierte Abläufe ausgeliefert. Solche Abläufe helfen, wiederholbare Releases zu schaffen und Fehlerquellen zu verringern. Ebenso gehört eine nachvollziehbare Trennung zwischen Entwicklungsstand und produktivem Stand dazu.
Vor dem Livegang sollte geprüft werden, ob Inhalte, Rechte, Navigation, Formulare, Ladeverhalten und Redaktionsprozesse zusammenpassen. Danach beginnt der operative Teil: Inhalte werden gepflegt, technische Abhängigkeiten beobachtet und Erweiterungen geplant. Wer ein ähnliches Vorhaben vorbereitet, kann eine erste Einordnung über den Projekt-Check oder ein unverbindliches Erstgespräch nutzen. Für uns als ballmüller solutions ist dabei entscheidend, dass Konzept, Umsetzung und späterer Betrieb von Anfang an zusammen gedacht werden.
Typische Stolpersteine bei Website, CMS, Daten und Betrieb
In solchen Projekten entstehen Probleme oft nicht in der sichtbaren Oberfläche, sondern an den Übergängen zwischen Inhalt, Technik und Organisation. Ein häufiger Stolperstein ist ein unklarer Zuschnitt des CMS. Wenn vorab nicht sauber festgelegt wird, welche Inhalte strukturiert gepflegt werden und was redaktionell frei bleiben darf, wird die Pflege später unnötig kompliziert. Ein CMS sollte Redaktionsarbeit unterstützen und nicht durch zu starre oder zu offene Modelle erschweren.
Ebenso kritisch sind Schnittstellen. Eine Schnittstelle ist eine definierte Verbindung, über die Systeme Daten austauschen. Auch wenn eine Website zunächst überschaubar wirkt, können schon kleine Zusatzfunktionen interne Abhängigkeiten schaffen, etwa zu Formularen, Datenbeständen oder externen Diensten. Diese Abhängigkeiten sollten fachlich und technisch früh beschrieben werden, damit Verantwortung, Fehlerbilder und Betriebsabläufe klar sind.
Beim Betrieb wird häufig unterschätzt, dass eine Headless-CMS-Website aus mehreren Teilen besteht, die unterschiedlich geschützt und überwacht werden müssen. Der öffentliche Webteil hat andere Anforderungen als das Redaktionssystem. Zugänge, Rollen und Freigaben müssen nachvollziehbar geregelt sein. Außerdem sollte festgelegt werden, wie Änderungen ausgerollt werden, wie im Fehlerfall reagiert wird und wer Inhalte oder technische Einstellungen anpassen darf.
Auch das Thema Daten verdient Aufmerksamkeit. Schon bei einfachen Websites können personenbezogene Daten anfallen, etwa über Kontaktformulare oder redaktionelle Arbeitskonten. Personenbezogene Daten sind Informationen, die sich auf eine identifizierte oder identifizierbare Person beziehen. Welche rechtlichen Anforderungen daraus folgen, sollte nicht technisch vermutet, sondern mit den zuständigen Stellen im Haus sowie bei Bedarf mit Rechtsberatung oder Datenschutzbeauftragten geprüft werden.
Schließlich lohnt sich der Blick auf die langfristige Wartbarkeit. Individuelle Systeme sollten so aufgebaut sein, dass Inhalte erweiterbar bleiben, technische Komponenten austauschbar sind und Deployment-Prozesse nicht an Einzelwissen hängen. Dazu gehören klare Zuständigkeiten, dokumentierte Abläufe und ein Betriebskonzept, das auch nach dem Go-live tragfähig ist. Wenn ein Projekt zusätzlich Datenhaltung oder Integrationen benötigt, betrifft das oft auch die Datenbankentwicklung. Gerade hier zeigt sich, ob die Lösung nicht nur heute funktioniert, sondern sich auch sauber weiterentwickeln lässt.
Häufige Fragen
Wovon hängen die Kosten einer Headless-CMS-Website ab?
Die Kosten hängen vor allem vom fachlichen Umfang, vom gewünschten Designgrad, von individuellen Funktionen und vom geplanten Betrieb ab. Relevant sind außerdem Inhaltsmodell, Schnittstellen, Rollen für die Redaktion und die Frage, ob neben der Website zusätzliche Bausteine wie Rechner oder Formulare entstehen. Für eine grobe Einordnung eignet sich der Kostenrechner. Wenn bereits eine Beschreibung oder ein Lastenheft vorliegt, ist ein Projektsteckbrief meist der bessere Start.
Wie wird bei einem solchen Projekt typischerweise vorgegangen?
Üblich ist ein Vorgehen von der Anforderungsklärung über Konzept und Design bis zur Umsetzung, Qualitätssicherung und Inbetriebnahme. Bei einer Headless-CMS-Website sollten Inhalte, Redaktionsprozesse und technische Architektur früh gemeinsam betrachtet werden. So lässt sich besser entscheiden, welche Teile individuell entwickelt werden und wie Betrieb und Pflege organisiert sind. Wichtig ist, dass fachliche Ziele, Inhaltsstruktur und technische Umsetzung nicht getrennt nebeneinander geplant werden.
Welche Risiken sollten Auftraggeber früh ansprechen?
Typische Risiken liegen in unklaren Inhaltsmodellen, unscharfen Zuständigkeiten und unterschätzten Abhängigkeiten zwischen Website, CMS und Betrieb. Wenn Rollen, Freigaben oder Schnittstellen erst spät geklärt werden, führt das oft zu Nacharbeit. Auch Sicherheitsanforderungen, Zugriffsrechte und der Umgang mit Daten sollten früh benannt werden. Rechtliche Fragen, etwa zum Datenschutz oder zu Vorgaben für öffentliche Stellen, sollten mit den zuständigen Fachstellen und gegebenenfalls juristisch geprüft werden.
Wie lange dauert die Umsetzung einer individuellen Website mit Headless CMS?
Das hängt vom Funktionsumfang, von Freigabewegen, vom Designanspruch und von vorhandenen Vorarbeiten ab. Auch Integrationen, redaktionelle Prozesse und Anforderungen an den Betrieb beeinflussen die Projektdauer. Bei individuellen Lösungen ist meist weniger die reine Programmierung entscheidend als die saubere Abstimmung von Inhalt, Architektur und Bereitstellung. Für eine erste realistische Einschätzung helfen eine kurze Projektbeschreibung oder ein strukturiertes Erstgespräch.
Was muss für den späteren Betrieb besonders beachtet werden?
Für den Betrieb sollten Website, CMS, Bereitstellung und Verantwortlichkeiten als zusammenhängendes System betrachtet werden. Wichtig sind geregelte Zugänge, nachvollziehbare Veröffentlichungsprozesse, Überwachung technischer Komponenten und ein klarer Umgang mit Änderungen. Wenn mehrere Dienste beteiligt sind, muss feststehen, wie Fehler erkannt und behoben werden. Ebenso sollte vorab geklärt sein, wer Inhalte pflegt, wer technische Anpassungen verantwortet und wie Weiterentwicklungen geplant werden.
