Management Summary

FW Systems baute die neue Umgebung parallel auf und migrierte sie schrittweise. Der alte Windows-Dateiserver wich Seafile. Geräte werden heute zentral mit Fleet verwaltet. Authentik bündelt Anmeldung und Berechtigungen. Der lokale Server wurde durch eine Private-Cloud-Instanz ersetzt, die Firewall durch pfSense. Vaultwarden, Paperless-ngx, Zammad und Snipe-IT ergänzen die Umgebung. Beim E-Mail-System fiel die Entscheidung zunächst für Microsoft 365. Gerade diese bewusste Ausnahme macht den Fall interessant: Digitale Souveränität entstand hier nicht durch einen radikalen Austausch, sondern durch klare Anforderungen und die daraus resultierenden Ziele.

Die Migration dauerte zwei Monate. Insgesamt fielen fünf Stunden Downtime an, davon eine Stunde innerhalb der Arbeitszeit. Die interne Fünfjahresbetrachtung weist gegenüber der Fortschreibung der alten Umgebung 30 Prozent geringere Gesamtkosten aus. Die Bewertung der IT durch die Mitarbeitenden stieg auf einer Fünfer-Skala von 2 auf 4,5 Punkte.

Die Kennzahlen

Kennzahl	Ergebnis
Projektdauer	2 Monate
Downtime während der Migration	5 Stunden
Davon innerhalb der Arbeitszeit	1 Stunde
Kostenveränderung über fünf Jahre	–30 %
Bewertung der IT	von 2,0 auf 4,5 von 5 Punkten

Was dieser Fall zeigt

Eine Modernisierung muss nicht mit einem Big Bang beginnen. Sie braucht ein Zielbild, einen brauchbaren Rückweg für jede kritische Umschaltung und Menschen, die verstehen, warum sich ihr Arbeitsalltag verändert. Die Technik ist nur ein Teil der Arbeit.

Wodara hat nicht jedes proprietäre System ersetzt. Das Projekt setzte Open Source dort ein, wo es für Wodara sinnvoll ist. Diese Mischung ist weniger spektakulär als ein vollständiger Bruch. Dafür ist sie näher an der Wirklichkeit vieler mittelständischer Unternehmen.

---

1. Die Ausgangslage: Der schleichende Stillstand

Ein Unternehmen, das draußen arbeitet und drinnen verlässlich funktionieren muss

Die Gebäudeservice Wodara GmbH ist ein familiengeführtes Handwerksunternehmen aus Berlin. Rund 175 Menschen arbeiten in Sondereinigung, Höhenarbeiten, Grünanlagenpflege, Hausservice und Winterdienst. Das Unternehmen wurde 2003 gegründet und ist Mitglied der Gemeinwohl-Ökonomie.[1]

Die tägliche IT-Arbeit reicht weit über den Schreibtisch hinaus. Mitarbeitende sind an verschiedenen Orten im Einsatz, Verwaltung und Disposition müssen Informationen schnell finden, neue Kolleginnen und Kollegen brauchen verlässliche Zugänge und die Geschäftsführung muss wissen, wer auf welche Daten zugreifen darf. Wenn die IT an dieser Stelle bremst, betrifft das keinen abstrakten Hintergrundprozess. Es betrifft den Arbeitstag.

Die bestehende Umgebung war über Jahre gewachsen. Ein Windows-Dateiserver, ein lokaler Exchange-Server, ein Server vor Ort und eine ältere Firewall bildeten den Kern. Geräte wurden weitgehend einzeln verwaltet. Benutzerkonten und Rechte lagen nicht in einem durchgängigen Modell. Manche Abhängigkeiten waren dokumentiert, andere steckten vor allem im Wissen einzelner Personen.

Das ist kein ungewöhnlicher Zustand. Kleine Entscheidungen lösen akute Probleme. Eine neue Freigabe wird eingerichtet, ein Gerät kommt hinzu, eine Anwendung braucht eine Ausnahme. Jede Entscheidung ist für sich nachvollziehbar. Nach einigen Jahren ist daraus eine Landschaft geworden, in der selbst kleine Änderungen Nebenwirkungen haben können und niemand mehr den Überblick hat.

Die Anatomie schlecht wartbarer IT

Schlecht wartbare IT erkennt man selten an einem großen roten Warnlicht. Sie zeigt sich in vielen kleinen Reibungen:

• Updates werden verschoben, weil niemand sicher sagen kann, was danach noch funktioniert.
• Neue Geräte brauchen unnötig viel Handarbeit.
• Rechte wachsen mit der Zeit, werden aber beim Rollenwechsel nicht zuverlässig angepasst.
• Dateien liegen an mehreren Orten oder sind nur über gewohnte Pfade auffindbar.
• Ein Server bleibt in Betrieb, weil die Folgen einer Abschaltung nicht sauber geprüft sind.
• Support beginnt mit der Frage, wie das betroffene System überhaupt aufgebaut ist.

Das BSI bezeichnet Softwareupdates als Grundpfeiler der IT-Sicherheit. Updates beheben Fehler und schließen bekannte Sicherheitslücken; dafür müssen Unternehmen zunächst wissen, welche Programme und Geräte sie einsetzen.[2] Genau dieser Überblick fehlte in der alten Umgebung an mehreren Stellen oder war mit zu viel Handarbeit verbunden.

Update-Stau ist ein Sicherheitsrisiko und zugleich ein Hinweis auf fehlende Wartbarkeit. Wenn eine Aktualisierung regelmäßig Angst auslöst, liegt das Problem oft tiefer: unklare Abhängigkeiten, uneinheitliche Konfigurationen, fehlende Tests oder kein belastbarer Rückweg.

Was der alte Zustand täglich kostete

Nicht jeder Preis steht auf einer Rechnung. Langsame Geräte kosten Minuten. Doppelte Ablagen kosten Suchzeit. Einzelne Passwörter und händisch gepflegte Rechte kosten Konzentration. Ein Neustart, den niemand auslösen möchte, bindet Aufmerksamkeit, obwohl noch gar nichts passiert ist.

Die direkte Folge ist reaktiver Betrieb. Erst meldet jemand ein Problem. Dann beginnt die Suche nach der Ursache. Bei einer kleinen IT-Mannschaft konkurriert diese Arbeit mit allem anderen, was eigentlich ansteht: Unterstützung der Mitarbeitenden, Prozessverbesserung, Sicherheit und Weiterentwicklung.

Wodara wollte aus dieser Lage heraus, ohne den Betrieb für Wochen auf eine Baustelle zu setzen. Mehr Open Source war Mittel und Ziel. Gesucht war eine IT, die sich aktualisieren lässt, deren Zustand sichtbar ist und deren Komponenten nicht untrennbar aneinanderhängen.

---

2. Die Entscheidung: Warum Open Source, und warum nicht einfach neues Microsoft?

Der naheliegende Weg

Die bestehende Umgebung war stark von Microsoft geprägt. Ein Upgrade innerhalb desselben Ökosystems hätte Vorteile gehabt: bekannte Oberflächen, eingespielte Dateiformate und weniger sichtbare Veränderung für Mitarbeitende. Dieser Weg wäre keineswegs automatisch falsch gewesen.

Er hätte aber ein zentrales Problem nicht gelöst. Neue Versionen machen eine Umgebung noch nicht wartbar. Wenn Geräte weiterhin einzeln gepflegt, Rechte verteilt verwaltet und Abhängigkeiten nur teilweise dokumentiert werden, zieht die alte Betriebsweise lediglich auf modernere Software um.

Die Entscheidung wurde deshalb nicht als Produktvergleich geführt. Im Mittelpunkt standen sieben Fragen:

1. Können Updates regelmäßig und kontrolliert eingespielt werden?
2. Ist die Umgebung nachvollziehbar dokumentiert?
3. Lassen sich Komponenten austauschen, ohne alles neu zu bauen?
4. Können Geräte, Konten und Rechte zentral verwaltet werden?
5. Wo liegen Daten und wer kontrolliert den Betrieb?
6. Welche Gesamtkosten entstehen über fünf Jahre?
7. Wie kommen wir weg aus der Abhängikeit von US-Amerikansichen Big Tec Firmen?

Zwei Wege im Vergleich

Kriterium	Modernisierung im bisherigen Ökosystem	Modulare Open-Source-/Hybridarchitektur
Vertrautheit	hoch	anfangs unterschiedlich je Anwendung
Einführungsaufwand	auf den ersten Blick geringer	höherer Planungs- und Migrationsaufwand
Wartbarkeit	einfache Wartbarkeit in der Microsoft Cloud	durch Standardisierung und Automatisierung einfach gehalten
Datenhoheit	Daten liegen in der Microsoft Cloud	die Daten liegen auf dein eigenen Servern in Deutschland
Austauschbarkeit	innerhalb des Ökosystems bequem, außerhalb sehr aufwendig	Schnittstellen und getrennte Komponenten sind Teil des Zielbilds Alles komuniziert über offene Standards
Geräteverwaltung	möglich, aber an Microsoft Plattform gebunden	mit Fleet zentral und plattformübergreifend aufgebaut
Kosten	planbar, aber lizenz- und paketabhängig	Mischung aus Migrationsaufwand, Betrieb und geringeren Lizenzabhängigkeiten
Veränderung für Mitarbeitende	zunächst geringer	muss aktiv begleitet werden

Die Tabelle ist keine allgemeingültige Bewertung beider Welten. Sie beschreibt die Kriterien, die im Wodara-Projekt wichtig waren. Ein Unternehmen mit anderer Fachsoftware, anderen Verträgen oder einem großen internen Microsoft-Team kann zu einem anderen Ergebnis kommen.

„Immer aktuell“ ist eine Architekturentscheidung

Aktualität entsteht nicht dadurch, dass jemand regelmäßig auf „Update“ klickt. Sie entsteht, wenn vier Bedingungen erfüllt sind:

• Der Istzustand ist bekannt.
• Konfigurationen sind reproduzierbar.
• Änderungen lassen sich überwachen und bei Bedarf zurücknehmen.
• Zuständigkeiten sind eindeutig.

Erst dann werden Updates vom Risiko zur Routine. Das BSI empfiehlt, Aktualisierungen zeitnah einzuspielen und automatische Verfahren dort zu nutzen, wo sie zuverlässig verfügbar sind.[2] Für Unternehmen kommt eine weitere Anforderung hinzu: Automatisierung braucht Kontrolle. Nach dem Start muss sichtbar bleiben, ob ein Update erfolgreich war. Kritische Dienste brauchen einen erprobten Rückweg.

Warum die Lösung hybrid blieb

Wodara ersetzte den lokalen Exchange-Server durch Microsoft 365. Das war keine Open-Source-Entscheidung. Es war eine pragmatische Projektentscheidung innerhalb einer größeren, deutlich offeneren Architektur.

Im Rückblick würde FW Systems diesen Teil heute anders planen und Mailcow als Alternative prüfen, da Wodara weniger im Microsoft Universum unterwegs ist wie zuerst angenommen.
Diese Erkenntnis gehört zur Fallstudie, weil sie eine Wahrheit zeigt: Digitale Souveränität ist kein Zustand, den ein Unternehmen nach einem Projekt für immer besitzt. Sie bleibt eine Folge konkreter Entscheidungen. Manche davon halten langfristig. Andere bewertet man mit neuer Erfahrung neu. Am Ende muss Digitale Souveränität immer eine gute Mischung aus Unabhängigkeit, Kosten und Nutzbarkeit sein.

---

3. Das Zielbild: Eine IT, die man verstehen und verändern kann

Vorher und nachher

Bereich	Vor der Migration	Nach der Migration
Dateiablage	Windows-Dateiserver vor Ort	Seafile in der neuen Umgebung
E-Mail	lokaler Exchange-Server	Microsoft 365
Passwörter	kein zentraler, verwalteter Standard	Vaultwarden
Geräteverwaltung	händische Einzelpflege	zentrale Verwaltung mit Fleet
Identitäten	verteilte Konten und Rechte	Authentik als zentrales SSO
Berechtigungen	teilweise einzeln gepflegt	gruppenbasiertes Rechtemodell
Serverbetrieb	physischer Server vor Ort	Private-Cloud-Instanz
Firewall	bisherige Appliance/Lösung	pfSense
Dokumente	verteilte Ablagen und Prozesse	Paperless-ngx
Kommunikation	mehrere Eingangskanäle und manuelle Zuordnung	Zammad
Inventar	kein durchgängiger zentraler Bestand	Snipe-IT
Betriebsüberblick	punktuelle Prüfung	zentrales Monitoring durch FW Systems

Architekturübersicht

Das Schaubild vereinfacht bewusst. Es zeigt nicht jedes Netzsegment und keine sicherheitsrelevanten Detailkonfigurationen. Für die Geschäftsentscheidung ist nur wichtig, dass Identität, Geräte, Dienste und Monitoring sind nicht länger voneinander getrennte Baustellen sind.

Die fünf Designprinzipien

1. Eine Identität, nachvollziehbare Rechte

Authentik bildet den zentralen Einstieg für die unterstützten Anwendungen. Mitarbeitende melden sich über Single Sign-on an. Berechtigungen hängen an Gruppen statt an vielen Einzelentscheidungen.

Das verändert vor allem On- und Offboarding. Eine neue Person erhält die Gruppen, die zu ihrer Rolle passen. Beim Wechsel der Aufgabe werden Gruppen angepasst. Beim Austritt wird der zentrale Zugang gesperrt. Die Arbeit verschwindet nicht vollständig, aber sie wird überschaubar und prüfbar.

2. Geräte zentral statt einzeln verwalten

Fleet schafft einen zentralen Überblick über die verwalteten Geräte. Richtlinien, Zustand und notwendige Maßnahmen lassen sich an einer Stelle bearbeiten. Die Alternative wäre, jeden Rechner einzeln anzufassen und darauf zu vertrauen, dass nichts übersehen wurde.

Die zentrale Verwaltung verkürzt Routineaufgaben und verbessert die Auskunftsfähigkeit: Welche Geräte sind im Bestand? Welche Versionen laufen? Wo besteht Handlungsbedarf?
Neue Software ist im Handumdrehen installiert und Probleme laufen an einer zentralen Stelle zusammen.

3. Dienste bleiben getrennt austauschbar

Dateiablage, Passwortverwaltung, Dokumentenmanagement, Tickets und Inventar sind eigene Bausteine. Sie arbeiten zusammen, sind aber nicht ein einziges untrennbares Paket. Das erhöht zunächst den Integrationsaufwand. Es senkt dafür das Risiko, dass ein späterer Wechsel das gesamte System betrifft.

Seafile ersetzte den Windows-Dateiserver. Vaultwarden etablierte eine zentrale Passwortverwaltung. Paperless-ngx, Zammad und Snipe-IT decken klar abgegrenzte Aufgaben ab. Nicht jedes Problem wird in dieselbe Plattform gedrückt.

4. Infrastruktur wird dokumentiert und reproduzierbar

Die Umgebung wird so weit wie sinnvoll als Code beschrieben. Dokumentation besteht dadurch nicht allein aus Anleitungen, die veralten können. Die Konfiguration selbst zeigt, wie sich ein System reproduzierbar aufbauen lässt.

Das ist die technische Grundlage für kontrollierte Änderungen und einen robusten Wiederherstellungsprozess im Ernstfall. Wer weiß, wie eine Umgebung erzeugt wurde, kann Abweichungen besser erkennen und einen Ersatz vorbereiten.

5. Der Betrieb ist sichtbar

FW Systems überwacht die zentralen Dienste. Monitoring soll Fehler melden, bevor sie im Arbeitsalltag auffallen. Das gelingt nicht bei jedem Vorfall. Es verkürzt aber den Weg zwischen einer technischen Auffälligkeit und der Reaktion darauf.

Das Angebot von FW Systems verbindet standardisierte Cloud- und Open-Source-Lösungen mit zentralem Monitoring und Support.[4] Bei FW Systems ist die Betriebsverantwortung Teil des Zielbilds, nicht etwas, das erst nach der Migration dazukommt.

---

4. Die Migrationsstrategie: Umbau bei laufendem Motor

Die neue Architektur war nur die halbe Aufgabe. Wodara musste während der Umstellung weiterarbeiten. Termine, Kundenaufträge und interne Abläufe richten sich nicht nach einem IT-Projekt.

FW Systems setzte deshalb auf Parallelbetrieb und klar getrennte Phasen. Die alte Umgebung blieb zunächst unangetastet. Erst wenn ein Teil der neuen Umgebung im Alltag funktionierte, folgte der nächste Schritt.

Phase 1: Das Fundament zuerst

Die Private-Cloud-Umgebung, pfSense, Authentik und das Monitoring wurden vorbereitet, bevor produktive Arbeitsplätze umgestellt wurden. Diese Reihenfolge klingt langsam, war aber der schnellste Weg zu einem kontrollierten Projekt.

Das Fundament musste drei Fragen beantworten:

• Können die neuen Dienste sicher erreicht werden?
• Funktionieren Identitäten und Gruppen wie geplant?
• Erkennt das Monitoring Fehler, bevor echte Nutzer betroffen sind?

Phase 2: Eine Pilotperson statt eines großen Knalls

Eine Person bekam früher Zugriff auf die neue Umgebung und arbeitete damit, während der Rest des Unternehmens unverändert weiterarbeitete. Dieser Pilot hatte zwei Aufgaben: technische Fehler finden und zeigen, wo eine technisch korrekte Lösung im Alltag trotzdem umständlich war.

Viele Probleme tauchen erst bei echter Arbeit auf. Ein Dateipfad ist unklar. Eine Berechtigung fehlt. Ein gewohnter Handgriff braucht in der neuen Oberfläche einen anderen Weg. Ein Pilot macht solche Reibungen sichtbar, solange sie noch günstig zu beheben sind.

Phase 3: Schrittweiser Rollout

Nach dem Pilot folgte der Rollout in überschaubaren Wellen. Die Umstellung wurde nicht als anonyme technische Änderung behandelt. Für die jeweiligen Gruppen gab es Ansprechpersonen und kurze Hilfen für die häufigsten Aufgaben.

Kleine Wellen senken das Risiko und liefern schnelles Feedback. Eine Erklärung, die beim ersten Mal nicht funktioniert, wird vor der nächsten Gruppe verbessert. Eine fehlende Berechtigung wird nicht hundertfach kopiert.

Phase 4: Koexistenz

Alt und Neu liefen für eine begrenzte Zeit nebeneinander. Diese Phase ist unbequem, weil zwei Welten betreut werden müssen. Sie ist trotzdem wichtig. Mitarbeitende verlieren nicht schlagartig den Zugriff, und das Projektteam kann prüfen, ob wirklich alle relevanten Daten und Abläufe angekommen sind.

Koexistenz braucht klare Regeln. Welches System ist für neue Daten führend? Wie lange bleibt die alte Ablage lesbar? Wer entscheidet, wann ein Bereich abgeschlossen ist? Ohne diese Regeln wird aus einer Übergangsphase ein Dauerzustand.

Phase 5: Kontrollierter Rückbau

Der alte Server wurde erst abgeschaltet, nachdem die Nutzung geprüft und der Rückweg geklärt war. Abschalten bedeutet dabei mehr als den Netzschalter zu drücken. Datenaufbewahrung, Sicherungen, Zugriffsrechte und Dokumentation müssen abgeschlossen sein.

Erst der Rückbau beendet die Migration. Solange Alt-Systeme still weiterlaufen, bleiben Kosten und Unsicherheit bestehen.

Fünf Stunden Downtime, davon eine im Arbeitstag

Über das gesamte Projekt summierten sich die geplanten Umschaltfenster auf fünf Stunden. Eine Stunde lag innerhalb der Arbeitszeit, vier Stunden lagen außerhalb. Der reguläre Arbeitstag war damit nur in einem begrenzten Umschaltfenster betroffen.

Diese Zahl sollte nicht als Garantie für andere Projekte gelesen werden. Die erreichbare Downtime hängt von Datenmenge, Leitung, Fachanwendungen, Abhängigkeiten und der Qualität des Ausgangszustands ab. Der übertragbare Teil ist die Methode: parallel aufbauen, mit kleiner Gruppe testen, in Wellen umstellen und das alte System erst nach einem Nutzungsnachweis abschalten.

Der Rollback-Plan

Für jede kritische Umschaltung braucht es eine vorher beantwortete Frage: Was tun wir, wenn die Prüfung fehlschlägt?

Ein brauchbarer Rollback-Plan nennt:

• den letzten sicheren Zustand,
• die Entscheidungskriterien für Abbruch oder Fortsetzung,
• die verantwortliche Person,
• die benötigten Sicherungen,
• die Reihenfolge der Rückschritte,
• das maximale Zeitfenster.

Backups allein reichen dafür nicht. Das BSI weist ausdrücklich darauf hin, dass eine vorhandene Datensicherung keine erfolgreiche Wiederherstellung garantiert. Wiederherstellungen müssen regelmäßig getestet werden.[3]

---

5. Der Faktor Mensch: Wie aus Betroffenen Beteiligte wurden

Eine neue Anmeldung, eine andere Dateiablage oder ein Passwortmanager wirken in einer Architekturzeichnung klein. Für die Person am Arbeitsplatz sind sie sehr konkret. Der Montagmorgen fühlt sich anders an. Gewohnte Handgriffe funktionieren nicht mehr genau wie vorher.

Technische Migrationen scheitern selten daran, dass niemand ein Handbuch geschrieben hat. Sie geraten ins Stocken, wenn Menschen zu spät erfahren, warum sich etwas ändert, und wenn Rückmeldungen im Projekt verschwinden.

Die Warum-Botschaft gehört zur Geschäftsführung

Die Geschäftsführung erklärte die Umstellung als Unternehmensentscheidung, nicht als isolierte IT-Maßnahme. Sie stellte den Zusammenhang her: weniger Update-Stau, nachvollziehbare Rechte, weniger Abhängigkeit von einzelnen Systemen und eine Umgebung, die mit dem Unternehmen weiterentwickelt werden kann.

Diese Botschaft kann ein externer Dienstleister unterstützen. Er kann sie nicht glaubwürdig ersetzen. Mitarbeitende wollen wissen, warum ihr Unternehmen die Veränderung anstößt und woran es den Erfolg misst.

Eine Pilotperson als Übersetzer

Die Pilotperson testete die neue Umgebung und übersetzte zwischen Projekt und Alltag. Technische Teams beschreiben oft Funktionen. Kolleginnen und Kollegen beschreiben Situationen: „Wo finde ich die Datei?“, „Wie teile ich das mit jemandem?“ oder „Warum muss ich mich hier noch einmal anmelden?“

Beide Perspektiven werden gebraucht. Ohne die technische Sicht bleibt das System unsauber. Ohne die Alltagssicht bleibt es unbenutzbar.

Kurze Schulungen für echte Aufgaben

Statt einer ganztägigen Schulung setzte das Projekt auf kurze, rollenbezogene Einheiten. Im Mittelpunkt standen die Handgriffe, die am nächsten Arbeitstag tatsächlich gebraucht wurden:

• anmelden und Zugang wiederherstellen,
• Dateien finden, bearbeiten und teilen,
• Passwörter sicher ablegen und freigeben,
• Supportfälle melden.

Kleine Formate haben einen praktischen Vorteil. Fragen tauchen näher an der tatsächlichen Nutzung auf. Eine Antwort lässt sich direkt ausprobieren.

Feedback muss eine sichtbare Folge haben

Eine Rückmeldung schafft erst dann Vertrauen, wenn etwas damit passiert. Das Projekt brauchte deshalb einen klaren Kanal und eine sichtbare Reaktion: Problem aufnehmen, einordnen, Lösung oder Entscheidung zurückmelden.

Nicht jeder Wunsch kann umgesetzt werden. Auch ein begründetes Nein ist besser als Schweigen. Wer versteht, warum eine Änderung nicht sinnvoll ist, kann damit arbeiten. Wer keine Antwort bekommt, sucht sich einen Umweg.

Was im Alltag leichter wurde

Die neue Umgebung reduzierte mehrere kleine Brüche:

• Single Sign-on vereinfachte den Zugang zu den angebundenen Diensten.
• Gruppen machten Berechtigungen nachvollziehbarer.
• Fleet ersetzte einen Teil der manuellen Gerätepflege.
• Seafile gab der Dateiablage ein modernes, zentral verwaltetes Zuhause.
• Vaultwarden schuf einen gemeinsamen Standard für Passwörter.
• Zammad bündelte Supportanfragen.

Die interne Bewertung der IT stieg von 2,0 auf 4,5 von fünf Punkten. Das sind 2,5 Punkte mehr. Der Wert beweist nicht, dass jede Person jede Änderung mochte. Er zeigt aber, dass die neue Umgebung im Alltag deutlich besser bewertet wurde.

Was wir beim nächsten Mal früher tun würden

Trotz des guten Ergebnisses blieb die Begleitung der Mitarbeitenden hinter dem zurück, was heute der eigene Anspruch von FW Systems wäre. Beim nächsten vergleichbaren Projekt würde die Kommunikations- und Schulungsplanung früher beginnen. Pilot, Hilfen und Feedbackkanal bekämen von Anfang an einen eigenen Arbeitsstrom.

Diese Erkenntnis ist unangenehm, aber nützlich. Gute Technik macht Akzeptanz wahrscheinlicher. Sie erzeugt sie nicht automatisch.

---

6. Die Ergebnisse nach der Migration

Zwei Monate statt Dauerbaustelle

Vom Kickoff bis zum Abschluss vergingen zwei Monate. Der begrenzte Zeitraum war möglich, weil Zielbild und Migrationsphasen klar getrennt waren. Parallelbetrieb kostet kurzfristig mehr Aufmerksamkeit, verhindert aber, dass ein einzelnes Problem das gesamte Vorhaben blockiert.

Kosten: Aus Index 100 wurde Index 70

Die Fünfjahresbetrachtung vergleicht die Fortschreibung der alten Umgebung mit Migration und Betrieb der neuen Architektur. Weil absolute Vertrags- und Betriebskosten nicht Teil dieses Whitepapers sind, werden die Werte indexiert dargestellt.

Betrachtung über fünf Jahre	Kostenindex
Alte Umgebung fortgeschrieben	100
Neue Umgebung einschließlich Migration	70
Veränderung	–30 %

Die Einsparung kommt nicht aus einer einzigen entfallenen Lizenz. Sie entsteht aus der Kombination von standardisiertem Betrieb, zentraler Geräteverwaltung, weniger manuellen Einzelschritten, Open-Source-Komponenten und einer anderen Infrastruktur. Microsoft 365 bleibt als Kosten- und Abhängigkeitsfaktor Teil der neuen Umgebung.

Eine TCO-Betrachtung muss mehr enthalten als Lizenzpreise. Zur Rechnung gehören mindestens:

• Migrationsaufwand,
• laufender Betrieb und Support,
• Lizenzen und Subscriptions,
• Hosting und Infrastruktur,
• Wartung und Updates,
• interner Zeitaufwand,
• Rückbau der Altumgebung.

Die 30 Prozent sind deshalb keine allgemeine Sparzusage. Sie beschreiben diesen Fall über den betrachteten Zeitraum.

Downtime: fünf Stunden, davon eine im Arbeitstag

Die geplanten Umschaltungen verursachten zusammen fünf Stunden Downtime. Eine Stunde davon lag in der regulären Arbeitszeit. Vier Stunden konnten in Zeitfenster außerhalb des Arbeitstags verlegt werden.

Das Ergebnis ist nicht allein der neuen Software zuzuschreiben. Es folgt aus dem Vorgehen: paralleles Fundament, Pilot, Wellen, Koexistenz und später Rückbau.

Zufriedenheit: von 2,0 auf 4,5

Vor der Umstellung wurde die IT intern mit 2,0 von fünf Punkten bewertet. Nach der Migration lag der Wert bei 4,5 Punkten. Der Anstieg um 2,5 Punkte passt zu den sichtbaren Veränderungen: weniger Systembrüche, zentralere Anmeldung, modernere Dateiablage und ein klarerer Supportweg.

Betrieb: Vom Blindflug zum Lagebild

Nach der Migration werden die zentralen Dienste durch FW Systems überwacht. Geräte sind in Fleet und Snipe-IT nachvollziehbar, Supportfälle laufen in Zammad zusammen und Identitäten werden zentral über Authentik gesteuert.

Das verändert den Support. Ein Problem muss nicht immer zuerst von einer betroffenen Person beschrieben werden. Technische Abweichungen können früher auffallen und mit mehr Kontext bearbeitet werden. Nicht jeder Fehler lässt sich unsichtbar beheben. Der Betrieb hat aber eine bessere Ausgangslage, weil Zustand und Zuständigkeiten klarer sind.

Was sich nicht in einer Kennzahl ausdrücken lässt

Drei Veränderungen sind schwerer zu messen, aber im Betrieb wichtig:

Erstens ist die Umgebung erklärbarer. Neue Dienstleister oder interne Verantwortliche müssen weniger verborgenes Wissen rekonstruieren.

Zweitens ist sie veränderbarer. Ein einzelner Baustein kann geprüft oder ersetzt werden, ohne automatisch das gesamte System auszutauschen.

Drittens ist sie weniger von einem physischen Server im Büro abhängig. Die Private Cloud verschiebt Verantwortung nicht ins Nirgendwo; sie macht Standort, Betrieb und Sicherung zu bewusst gestalteten Teilen der Architektur.

---

7. Ehrliche Bilanz: Was wir heute anders machen würden

Ein Projektbericht, in dem alles glattlief, ist entweder oberflächlich oder Werbung. Beim Wodara-Projekt gab es drei Entscheidungen, die FW Systems heute anders treffen würde.

E-Mail nicht vorschnell in das nächste geschlossene System verschieben

Der lokale Exchange-Server wurde zu Microsoft 365 migriert. Das löste das unmittelbare Modernisierungsproblem, schuf aber eine neue Abhängigkeit. Heute würde FW Systems Mailcow als ernsthafte Alternative prüfen und die Entscheidung stärker an Exit-Fähigkeit, Betriebsaufwand, Zustellbarkeit und internen Anforderungen ausrichten.

Das heißt nicht, dass Mailcow für jedes Unternehmen automatisch besser ist. Eigener oder betreuter Mailbetrieb bringt Verantwortung mit sich: Reputation, Spamabwehr, Updates, Monitoring und Wiederherstellung müssen zuverlässig funktionieren. Die Lehre ist deshalb nicht „Microsoft 365 war falsch“. Die Lehre ist: Eine strategische Zielarchitektur braucht für E-Mail dieselbe saubere Variantenprüfung wie für Dateiablage oder Identität.

Umschaltfenster noch genauer planen

Fünf Stunden Downtime, davon vier außerhalb der Arbeitszeit, sind ein gutes Ergebnis. Trotzdem würde FW Systems den Downtime-Plan heute feiner ausarbeiten. Dazu gehören klarere Abbruchkriterien, vorab gemessene Datenübertragungszeiten und ein noch genaueres Protokoll je Umschaltung.

Ein Gesamtwert ist für die Geschäftsführung hilfreich. Für die nächste technische Planung braucht das Team zusätzlich die Verteilung: Welche Phase verursachte wie viel Zeit? Wo lag Puffer? Welche Prüfung dauerte länger als erwartet?

Mitarbeitende früher und systematischer einbeziehen

Die Pilotperson, kurze Schulungen und Feedback halfen. Sie hätten früher geplant und breiter vorbereitet werden können. Beim nächsten Projekt würde der Veränderungsplan parallel zum Architekturplan entstehen.

Dazu gehören:

• Stakeholder und betroffene Rollen früh erfassen,
• Alltagsszenarien vor der technischen Konfiguration sammeln,
• Pilotkriterien gemeinsam festlegen,
• kurze Hilfen vor dem Rollout bereitstellen,
• Rückmeldungen mit Verantwortlichkeit und Termin bearbeiten.

Diese Arbeit wirkt im Projektplan zunächst wie zusätzlicher Aufwand. Später spart sie Support und Frust.

Die wichtigste Lehre

Die neue Umgebung war nicht erfolgreich, weil sie mehr Open Source enthielt. Sie war erfolgreich, weil die Bausteine in ein Betriebsmodell eingebettet wurden. Identitäten, Geräte, Rechte, Monitoring, Support und Migration wurden zusammen gedacht.

Open Source erweitert die Handlungsmöglichkeiten. Nutzen entsteht erst, wenn jemand diese Möglichkeiten verantwortungsvoll betreibt.

---

8. Ist Ihr Unternehmen bereit?

Vor einer Migration braucht es ein belastbares Bild der eigenen Lage.

Selbsttest: Zehn Fragen zur Wartbarkeit Ihrer IT

Beantworten Sie jede Frage mit Ja oder Nein.

1. Gibt es eine aktuelle Liste aller produktiv genutzten Geräte und Systeme?
2. Ist für jedes wichtige System eine verantwortliche Person oder Rolle benannt?
3. Können Sie erklären, welche Systeme voneinander abhängen?
4. Werden Sicherheitsupdates regelmäßig und nachvollziehbar eingespielt?
5. Wurde die Wiederherstellung aus einer Datensicherung in den letzten zwölf Monaten praktisch getestet?
6. Können neue Mitarbeitende über ein definiertes Rollenmodell eingerichtet werden?
7. Werden Zugänge beim Austritt zentral und vollständig entzogen?
8. Erkennen Sie kritische Störungen durch Monitoring, bevor mehrere Nutzer sie melden?
9. Können Sie Daten in einem dokumentierten Format aus Ihren wichtigsten Plattformen exportieren?
10. Gibt es für den Ausfall eines zentralen Systems einen getesteten Rückweg?

Auswertung

• 0 bis 3 Ja-Antworten: Die Umgebung hängt wahrscheinlich stark an Einzelwissen und reaktiver Arbeit. Beginnen Sie mit Inventar, Zuständigkeiten und Sicherungen.
• 4 bis 6 Ja-Antworten: Wesentliche Grundlagen existieren, aber einzelne Lücken können Änderungen riskant machen. Priorisieren Sie Abhängigkeiten, Identitäten und Restore-Tests.
• 7 bis 10 Ja-Antworten: Die Basis ist tragfähig. Prüfen Sie nun Kosten, Exit-Fähigkeit und Automatisierung, statt ohne Zielbild neue Werkzeuge einzuführen.

Der Test ist kein Sicherheitsaudit. Er zeigt, wo ein vertieftes Gespräch sinnvoll sein kann.

Für wen der Wodara-Weg nicht passt

Eine ähnliche Migration passt nicht zu jedem Unternehmen.

Sie ist keine gute Wahl, wenn eine unverzichtbare Fachanwendung ausschließlich in einer bestimmten lokalen Microsoft-Umgebung unterstützt wird und es keine tragfähige Integrationslösung gibt.

Sie passt auch nicht, wenn niemand im Unternehmen Entscheidungen zu Rollen, Daten und Abläufen treffen kann. Technik kann fehlende Verantwortung nicht ersetzen.

Und sie passt nicht, wenn „Open Source“ nur als kurzfristige Lizenzsparmaßnahme verstanden wird. Migration, Betrieb, Updates und Support kosten weiterhin Geld. Der Vorteil liegt in Kontrolle und Gestaltungsspielraum, nicht in kostenloser Arbeit.

Ein sinnvoller erster Schritt

FW Systems beginnt nicht mit einer Produktliste. Im IT-Check werden Bestand, Abhängigkeiten, Risiken und Ziele gemeinsam geprüft. Daraus entsteht eine Reihenfolge: Was muss zuerst stabilisiert werden? Was kann bleiben? Wo lohnt eine Alternative? Welche Veränderung wäre derzeit unnötig?

Erst danach lässt sich seriös sagen, ob eine Migration wie bei Wodara sinnvoll ist.

Nächster Schritt: Unverbindlichen IT-Check vereinbaren.

---

10. Über FW Systems

FW Systems ist das Systemhaus von Frachtwerk. Der Schwerpunkt liegt auf standardisiertem, betreutem IT-Betrieb mit Cloud- und Open-Source-Lösungen. Zum Angebot gehören zentrale Überwachung, Support und feste Leistungspakete zum Fixpreis.[4]

Wir betreiben selbst, was wir empfehlen. Dazu gehören unter anderem Seafile beziehungsweise Nextcloud, Vaultwarden, Mattermost, Jitsi, Authentik, Zammad, Paperless-ngx, Snipe-IT, Mailcow und weitere Open-Source-Dienste.

Das schützt nicht vor jeder Fehlentscheidung. Es verändert aber die Beratung. Wer ein System selbst aktualisiert, überwacht und wiederherstellt, spricht anders über dessen Alltagstauglichkeit als jemand, der nur eine Funktionsliste kennt.