Management Summary
Wir haben die IT der Wodara GmbH in zwei Monaten modernisiert. Die neue Umgebung haben wir parallel aufgebaut und schrittweise migriert. Seafile ersetzt den Windows-Dateiserver, Fleet verwaltet die Geräte zentral, und Authentik bündelt Anmeldung und Berechtigungen. Eine Private-Cloud-Instanz ersetzt den lokalen Server, pfSense die alte Firewall. Vaultwarden, Paperless-ngx, Zammad und Snipe-IT ergänzen die Umgebung. Beim E-Mail-System fiel die Wahl bewusst auf Microsoft 365.
Genau diese Ausnahme macht den Fall interessant: Digitale Souveränität entstand hier durch klare Anforderungen, nicht durch einen radikalen Austausch aller Systeme.
| Kennzahl | Ergebnis |
|---|---|
| Projektdauer | 2 Monate |
| Downtime gesamt | 5 Stunden (davon 1 in der Arbeitszeit) |
| Kosten über fünf Jahre | –30 % |
| Bewertung der IT durch Mitarbeitende | von 2,0 auf 4,5 von 5 Punkten |
Ausgangslage: Gewachsen statt geplant
Wodara ist ein familiengeführtes Berliner Handwerksunternehmen mit rund 175 Mitarbeitenden. Es ist in Sondereinigung, Höhenarbeiten, Grünanlagenpflege, Hausservice und Winterdienst tätig. Die Mitarbeitenden sind an vielen Einsatzorten unterwegs. Verwaltung und Disposition sind deshalb auf eine verlässliche IT angewiesen.
Die alte Umgebung war über Jahre gewachsen: Windows-Dateiserver, lokaler Exchange, ein Server vor Ort und eine ältere Firewall. Geräte wurden einzeln gepflegt, Rechte verteilt verwaltet, und viel Wissen steckte in einzelnen Köpfen. Die Folgen waren typisch. Updates wurden verschoben, neue Geräte brauchten viel Handarbeit, Rechte wuchsen unkontrolliert, und Dateien lagen doppelt ab. Der Betrieb lief rein reaktiv.
Das BSI nennt Updates einen Grundpfeiler der IT-Sicherheit. Voraussetzung dafür ist ein Überblick über alle eingesetzten Systeme. Genau dieser Überblick fehlte. Das Ziel war deshalb eine IT, die sich aktualisieren lässt, deren Zustand sichtbar ist und deren Komponenten austauschbar sind.
Die Entscheidung: Warum nicht einfach neues Microsoft?
Ein Upgrade im Microsoft-Ökosystem hätte vertraute Oberflächen und weniger Veränderung bedeutet. Das Kernproblem hätte es aber nicht gelöst: Neue Software allein hätte nur die alte Betriebsweise umgezogen.
Statt Produkte zu vergleichen, haben wir die Entscheidung an sieben Fragen ausgerichtet:
- Lassen sich Updates kontrolliert einspielen?
- Ist die Umgebung dokumentiert?
- Sind Komponenten austauschbar?
- Lassen sich Geräte und Rechte zentral verwalten?
- Wo liegen die Daten?
- Was kostet die Umgebung über fünf Jahre?
- Wie sinkt die Abhängigkeit von US-amerikanischen Big-Tech-Anbietern?
Die modulare Open-Source- und Hybridarchitektur bedeutete mehr Planungsaufwand und mehr Begleitung der Mitarbeitenden. Dafür bietet sie Daten auf eigenen Servern in Deutschland, offene Standards, plattformübergreifende Geräteverwaltung und geringere Lizenzabhängigkeiten. Unternehmen mit anderer Fachsoftware oder einem großen Microsoft-Team können zu einem anderen Ergebnis kommen.
Warum hybrid? Den Exchange-Server haben wir durch Microsoft 365 ersetzt. Das war eine pragmatische Entscheidung, keine Open-Source-Entscheidung. Rückblickend würden wir hier Mailcow prüfen, denn Wodara ist weniger an Microsoft gebunden als zunächst angenommen. Die Lehre daraus: Digitale Souveränität ist kein Endzustand, sondern eine laufende Abwägung zwischen Unabhängigkeit, Kosten und Nutzbarkeit.
Das Zielbild
| Bereich | Vorher | Nachher |
|---|---|---|
| Dateiablage | Windows-Dateiserver | Seafile |
| lokaler Exchange | Microsoft 365 | |
| Passwörter | kein Standard | Vaultwarden |
| Geräte | Einzelpflege | Fleet |
| Identitäten und Rechte | verteilt, einzeln gepflegt | Authentik (SSO), gruppenbasiert |
| Server | physisch vor Ort | Private Cloud |
| Firewall | alte Appliance | pfSense |
| Dokumente | verteilt | Paperless-ngx |
| Support | mehrere Kanäle | Zammad |
| Inventar | kein zentraler Bestand | Snipe-IT |
| Betrieb | punktuelle Prüfung | zentrales Monitoring |
Die Architektur folgt fünf Prinzipien:
- Eine Identität: Berechtigungen hängen an Gruppen. Dadurch werden On- und Offboarding einfach und prüfbar.
- Zentrale Geräteverwaltung: Fleet zeigt Bestand, Versionen und Handlungsbedarf an einer Stelle.
- Getrennte Bausteine: Jeder Dienst ist einzeln austauschbar. Das kostet anfangs mehr Integrationsaufwand, senkt aber später das Wechselrisiko.
- Infrastructure as Code: Die Konfiguration dokumentiert sich selbst und ist reproduzierbar. Das ist die Basis für kontrollierte Änderungen und schnelle Wiederherstellung.
- Sichtbarer Betrieb: Wir überwachen die Dienste und erkennen Fehler möglichst, bevor Nutzer sie bemerken.
Migration bei laufendem Betrieb
- Fundament: Zuerst haben wir Private Cloud, pfSense, Authentik und Monitoring aufgebaut, noch bevor ein Arbeitsplatz umgestellt wurde.
- Pilot: Eine Person arbeitete vorab in der neuen Umgebung und deckte technische Fehler sowie Reibungen im Alltag auf.
- Rollout in Wellen: Wir haben in kleinen Gruppen umgestellt, jeweils mit Ansprechpersonen und Kurzhilfen. Die Erklärungen haben wir vor jeder Welle verbessert.
- Koexistenz: Alt und Neu liefen eine begrenzte Zeit parallel. Klare Regeln legten fest, welches System führend ist und wie lange die Übergangszeit dauert.
- Rückbau: Die Altsysteme haben wir erst abgeschaltet, nachdem die Nutzung geprüft war und Sicherungen und Dokumentation abgeschlossen waren.
Für jede kritische Umschaltung gab es einen Rollback-Plan. Er legte fest: den letzten sicheren Zustand, die Abbruchkriterien, die Verantwortlichen, die nötigen Sicherungen, die Reihenfolge der Rückschritte und ein maximales Zeitfenster. Backups allein reichen dafür nicht, denn Wiederherstellungen müssen getestet werden.
Die fünf Stunden Downtime sind keine Garantie für andere Projekte. Übertragbar ist die Methode: parallel aufbauen, im Kleinen testen, in Wellen umstellen und erst nach einem Nutzungsnachweis abschalten.
Der Faktor Mensch
Migrationen stocken selten an der Technik. Sie stocken, wenn Menschen zu spät erfahren, warum sich etwas ändert. Bei Wodara erklärte die Geschäftsführung die Umstellung als Unternehmensentscheidung. Diese Rolle können wir als Dienstleister nicht glaubwürdig übernehmen.
Die Pilotperson übersetzte zwischen Projekt und Alltag. Statt Tagesschulungen gab es kurze, rollenbezogene Einheiten zu den Aufgaben, die am nächsten Tag anstanden: anmelden, Dateien teilen, Passwörter ablegen und Supportfälle melden. Jedes Feedback bekam eine sichtbare Antwort, notfalls ein begründetes Nein.
Selbstkritisch halten wir fest: Die Begleitung der Mitarbeitenden hätte früher beginnen sollen. Gute Technik macht Akzeptanz wahrscheinlicher, erzeugt sie aber nicht automatisch.
Ergebnisse
- Kosten: Über fünf Jahre sinkt der Kostenindex von 100 auf 70. Die Einsparung entsteht aus standardisiertem Betrieb, zentraler Geräteverwaltung, weniger Handarbeit, Open-Source-Komponenten und neuer Infrastruktur. Microsoft 365 bleibt ein Kosten- und Abhängigkeitsfaktor. Berücksichtigt sind Migration, Betrieb, Lizenzen, Hosting, Wartung, interner Aufwand und Rückbau. Die 30 Prozent gelten nur für diesen Fall.
- Zufriedenheit: Die Bewertung stieg von 2,0 auf 4,5 Punkte. Gründe sind weniger Systembrüche, eine zentrale Anmeldung, eine moderne Dateiablage und ein klarer Supportweg.
- Betrieb: Aus dem Blindflug wurde ein Lagebild. Geräte, Tickets und Identitäten sind zentral nachvollziehbar, und Fehler fallen früher auf.
- Schwer messbar, aber wichtig: Die Umgebung ist erklärbarer, einzelne Bausteine sind austauschbar, und es gibt keine Abhängigkeit mehr von einem Server im Büro.
Was wir heute anders machen würden
- E-Mail: Wir würden die Varianten genauso sauber prüfen wie bei den anderen Bausteinen, einschließlich Mailcow. Maßstab wären Exit-Fähigkeit, Betriebsaufwand und Zustellbarkeit. Eigener Mailbetrieb bringt allerdings Verantwortung für Reputation, Spamabwehr und Updates mit sich.
- Umschaltfenster: Wir würden sie feiner planen, mit klareren Abbruchkriterien, vorab gemessenen Übertragungszeiten und einem Protokoll für jede Phase.
- Change-Management: Wir würden den Veränderungsplan parallel zum Architekturplan erstellen. Betroffene Rollen und Alltagsszenarien würden wir früh erfassen und Hilfen schon vor dem Rollout bereitstellen.
Die wichtigste Lehre: Der Erfolg kam nicht von mehr Open Source an sich. Er kam daher, dass wir Identitäten, Geräte, Rechte, Monitoring, Support und Migration als ein Betriebsmodell gedacht haben.
Ist dein Unternehmen bereit?
Selbsttest (Ja/Nein):
- Gibt es eine aktuelle Liste aller Geräte und Systeme?
- Hat jedes wichtige System eine verantwortliche Person?
- Sind die Abhängigkeiten zwischen den Systemen bekannt?
- Werden Updates regelmäßig eingespielt?
- Wurde in den letzten zwölf Monaten eine Wiederherstellung getestet?
- Gibt es ein Rollenmodell für neue Mitarbeitende?
- Werden Zugänge beim Austritt zentral entzogen?
- Erkennt Ihr Monitoring Störungen, bevor Nutzer sie melden?
- Lassen sich Daten in dokumentierten Formaten exportieren?
- Gibt es einen getesteten Rückweg für zentrale Systeme?
Auswertung:
- 0–3 Ja: Beginne mit Inventar, Zuständigkeiten und Sicherungen.
- 4–6 Ja: Priorisiere Abhängigkeiten, Identitäten und Restore-Tests.
- 7–10 Ja: Prüfe Kosten, Exit-Fähigkeit und Automatisierung.
Der Wodara-Weg passt nicht, wenn eine unverzichtbare Fachanwendung nur in einer lokalen Microsoft-Umgebung läuft. Er passt auch nicht, wenn niemand über Rollen und Abläufe entscheiden kann oder wenn Open Source nur als Sparmaßnahme gedacht ist.
Erster Schritt: In unserem IT-Check prüfen wir gemeinsam mit Ihnen Bestand, Abhängigkeiten, Risiken und Ziele. Erst danach lässt sich seriös sagen, was bleiben kann und wo sich eine Alternative lohnt. → Unverbindlichen IT-Check vereinbaren.
Über uns
Wir sind das Systemhaus von Frachtwerk und bieten standardisierten, betreuten IT-Betrieb mit Cloud- und Open-Source-Lösungen an, inklusive Monitoring, Support und Leistungspaketen zum Fixpreis. Wir betreiben selbst, was wir empfehlen, darunter Seafile/Nextcloud, Vaultwarden, Mattermost, Jitsi, Authentik, Zammad, Paperless-ngx, Snipe-IT und Mailcow.
