SharePoint ersetzen: Was ein selbstgehostetes Intranet wirklich kostet

Ausgangslage

SharePoint ist als Infoportal in vielen Unternehmen gesetzt, weil es mit Microsoft 365 einfach da ist. Für einen Fertigungsbetrieb mit zwei Standorten haben wir zuvor selbst eine ganze Reihe von Automatisierungen rund um SharePoint gebaut: Newsseiten per Graph API erzeugen, ein SPFx-Webpart für Ereignisse, OneDrive-Ordner synchronisieren. Das funktionierte, aber jede Erweiterung fühlte sich an wie ein Kampf gegen die Plattform. Dazu kommt die Lizenzlogik: Jede Person, die das Portal auch nur lesen soll, braucht einen Sitz – auch Mitarbeitende in der Produktion, die sonst kein Office brauchen.

Wir haben uns deshalb entschieden, das Infoportal als eigene Anwendung zu bauen: Dashboard, Newsfeed, Dateiablage, Eventkalender mit Feiertagen beider Standorte, Teamseite, Administration und ein Login mit Rollen. Dieser Artikel ist unsere ehrliche Bilanz.

Der Technologie-Stack – und warum Windows Server

Die Anwendung läuft auf Next.js 15. Das war keine Modeentscheidung: Wir wollten Server-Rendering, ein solides Routing und eine Codebasis, die auch in zwei Jahren noch jemand versteht. Gehostet wird auf einem bestehenden Windows Server, weil der da ist, gesichert wird und die IT ihn kennt. Ein zusätzlicher Linux-Host hätte einen weiteren Betriebsprozess bedeutet, den niemand wollte.

Was das konkret heisst:

• Node.js als Dienst auf Windows, Reverse-Proxy davor
• Dateibasierte Ablage für News, Events und Dokumente statt einer separaten Datenbank – bewusst, weil Backup und Wiederherstellung damit trivial sind
• Konfiguration über Umgebungsvariablen, keine Geheimnisse im Repository

Die dateibasierte Ablage war die Entscheidung, über die wir am längsten diskutiert haben. Sie skaliert nicht ins Unendliche, aber ein Infoportal für ein Unternehmen dieser Grösse braucht das nicht. Dafür kann jeder Administrator die Daten mit dem Explorer nachvollziehen.

AD-Synchronisation per PowerShell

Ein Intranet ohne aktuelle Personen- und Gerätedaten ist wertlos. Statt die Anwendung direkt gegen das Active Directory sprechen zu lassen, haben wir einen PowerShell-Job gebaut, der die Organisationsstruktur, Benutzer und Geräte exportiert und der Anwendung als Datei übergibt. Vorteile:

• Die Webanwendung braucht keine AD-Berechtigungen
• Der Sync lässt sich einzeln testen und manuell auslösen
• Die IT kann das Skript lesen und anpassen, ohne die Anwendung zu verstehen

Das Gerätemodul – Computer, Laptops, Mobiltelefone beider Standorte mit Volltextsuche, Filtern, Statistiken und Excel-Export – lebte zuerst als eigene Anwendung und wurde später ins Intranet integriert. Das war rückblickend der richtige Weg: erst das Modul isoliert stabilisieren, dann einbauen.

Graph-Integration als Ergänzung, nicht als Fundament

Wir haben Microsoft 365 nicht abgeschaltet. Kalender, Mail und Dokumente bleiben dort. Die Graph-Integration im Intranet ist eine Ergänzung: Sie holt, was sinnvoll ist, und die Anwendung funktioniert auch dann, wenn Graph gerade nicht antwortet. Diese Trennung hat uns mehrfach gerettet, etwa wenn Token abliefen oder Berechtigungen im Tenant angepasst wurden.

Deployment über einen self-hosted GitHub Runner

Der Teil, den wir am stärksten unterschätzt hatten, war nicht der Code, sondern die Auslieferung. Ein manuelles Deployment auf einen Windows Server ist fehleranfällig und hängt an einer Person. Wir haben deshalb einen self-hosted GitHub Runner auf dem Server eingerichtet: Push auf den Hauptzweig, Build, Tests, Dienst neu starten. Das kostete uns am Anfang ein paar Tage, spart aber seither jede Woche Zeit und Nerven.

Was es wirklich kostet

Die ehrliche Rechnung besteht aus drei Posten:

1. Initialer Aufbau. Mehrere Wochen Entwicklung, verteilt über einige Monate neben dem Tagesgeschäft.
2. Betrieb. Ein Windows Server, der ohnehin existiert, plus Aktualisierungen von Node und Abhängigkeiten – realistisch ein paar Stunden pro Monat.
3. Wissen. Jemand muss die Anwendung verstehen. Das ist der eigentliche Preis, und er wird oft verschwiegen.

Dagegen steht: keine Sitzlizenz für Leseberechtigte, keine Grenzen durch die Plattform, und ein Portal, das genau die Prozesse abbildet, die das Unternehmen hat – nicht die, die SharePoint vorsieht.

Fazit

Ein selbstgehostetes Intranet ist kein Sparprogramm, sondern eine Entscheidung für Kontrolle. Es lohnt sich, wenn viele Personen lesen, aber wenige Lizenzen brauchen, und wenn das Unternehmen bereit ist, Wissen über die eigene Anwendung aufzubauen. Wer nur eine Newsseite braucht, bleibt besser bei SharePoint.

Aus diesem Projekt ist unser Produkt Atrium entstanden – das Intranet als wiederverwendbare Basis, statt jedes Mal bei null zu beginnen.