Mit dem STACKIT Managed VPN stellt STACKIT einen Managed‑Service für sichere Site‑to‑Site‑VPN‑Verbindungen bereit. Der Dienst befindet sich aktuell in der Beta‑Phase, ist kostenlos nutzbar, jedoch derzeit ausschließlich per API verfügbar. Eine grafische Oberfläche existiert aktuell noch nicht.
Für Umgebungen, die bereits auf Infrastructure‑as‑Code setzen, ist das Managed VPN dennoch gut nutzbar und sauber in bestehende Automatisierungsprozesse integrierbar.
Das Managed VPN kann nur in Verbindung mit einer STACKIT Network Area genutzt werden. Die Network Area fungiert als zentrales Routing‑Konstrukt und ermöglicht es, Netzwerke, Projekte und deren virtuelle Netze übergreifend miteinander zu verbinden.
Das VPN Gateway erhält eine zentrale IP‑Adresse aus der Network Area, und über statische Routen werden die CIDR‑Ranges weiterer Netzwerke dorthin geleitet. Dadurch eignet sich der Service besonders gut für Hub‑and‑Spoke‑Architekturen.
Das STACKIT Managed VPN unterscheidet zwischen zwei Ressourcentypen:
Das VPN Gateway bildet den zentralen Einstiegspunkt und definiert die grundlegenden Eigenschaften der VPN‑Anbindung:
Für jede angegebene Availability Zone wird automatisch ein eigenes Tunnel Interface erzeugt. Dadurch entstehen immer zwei Tunnel, was eine hochverfügbare Anbindung ermöglicht.
Ein VPN Gateway kann mit einer oder mehreren VPN Connection‑Ressourcen verknüpft werden.
In diesen Objekten wird die eigentliche Site‑to‑Site‑Verbindung definiert:
STACKIT unterstützt alle gängigen modernen Verschlüsselungs‑ und Integritätsalgorithmen, was eine sehr gute Interoperabilität mit gängigen Gegenstellen ermöglicht.
Die Hochverfügbarkeit ist integraler Bestandteil des Designs:
Das erhöht zwar minimal den Konfigurationsaufwand, sorgt aber für eine ausfallsichere Verbindung.
Die Konfiguration erfolgt aktuell ausschließlich über die STACKIT API. In der Praxis lässt sich das sehr gut mit Terraform umsetzen, beispielsweise über Local Blocks und den offiziellen STACKIT Terraform Provider. Auch Beta‑Ressourcen werden unterstützt. Es ist nur eine Frage der Zeit, bis der das Managed VPN vollwertig mit eigenen STACKIT Terraform Resource-Blocks unterstützt wird.
Für IaC‑getriebene Umgebungen ist das Managed VPN dadurch gut reproduzierbar und versionskontrolliert betreibbar.
Unsere bisherigen Erfahrungen mit dem STACKIT Managed VPN sind sehr positiv. Der Tunnelaufbau funktionierte in mehreren Szenarien problemlos und auch über längere Zeiträume hinweg zeigte sich die Verbindung stabil. Die Unterstützung moderner IPsec‑Algorithmen sorgt für eine saubere und zuverlässige Konnektivität.
Der aktuell größte Nachteil ist das fehlende Benutzerinterface. Die komplette Konfiguration muss per API erfolgen, was nicht für jede Zielgruppe ideal ist. Als Ausgleich ist der Service in der Beta‑Phase jedoch kostenlos nutzbar.
Das STACKIT Managed VPN ist bereits in der Beta ein technisch ausgereifter Dienst:
Sobald eine GUI verfügbar ist, dürfte der Service auch für weniger IaC‑affine Teams interessant werden. Für automatisierte und hybride Architekturen ist das Managed VPN jedoch bereits heute eine sehr solide Lösung.
Viele Unternehmen starten ihren Weg in die Cloud mit einem Wunsch: schnelle Migration, günstige Umsetzung und unkomplizierter Einstieg. Alle Workloads sollen einfach in die Cloud übertragen werden und schon ist die Migration abgeschlossen. Danach folgt dann jedoch oft die Ernüchterung: Die Kosten steigen, die Systeme laufen langsamer als erwartet und wirklich flexibel ist das neue Modell auch nicht. Hintergrund dafür ist oft die Migration nach dem Lift & Shift Ansatz. Was es damit auf sich hat, wo der Ansatz an seine Grenzen kommt und wie eine durchdachtere Strategie aussehen kann, erklären wir in diesem Artikel.
Die Lift & Shift Methode beschreibt eine Cloud-Migrationsstrategie, bei der bestehende IT-Systeme ohne größere Änderungen aus der On Premises Umgebung in die Cloud übertragen werden. Das System bleibt wie es ist und wird einfach verschoben. Damit ist dieser Ansatz der unkomplizierteste und schnellste in der Cloud-Migration. In einigen Szenarien ist es durchaus sinnvoll, Workloads mit dem Lift & Shift Ansatz zu migrieren:
Vor allem als temporäre Lösung oder bei sehr simplen Workloads kann Lift & Shift sinnvoll sein. Als dauerhafter Zustand entstehen dadurch jedoch fast immer Probleme. Die Cloud ist kein eins zu eins Ersatz für ein Rechenzentrum, sondern zeigt ihre Vorteile dann, wenn Cloud-native Ansätze zum Einsatz kommen.
Verschieben Unternehmen ihre IT-Infrastruktur unverändert in die Cloud, verschieben sie auch alle Probleme mit. In der Cloud können diese Probleme jedoch deutlich teurer werden als noch zuvor in der On Premises Umgebung.
Im eigenen Rechenzentrum läuft der Server rund um die Uhr, die Kosten dafür sind in der Regel fix. In der Cloud sind die Kostenmodelle meist komplexer: Oft handelt es sich um Pay-as-you-go-Modelle oder monatliche Abonnements, deren Kosten von der tatsächlichen Nutzung abhängen. Systeme, die nicht auf die Cloud ausgelegt sind, lassen sich jedoch nicht abhängig von der Nutzung skalieren und laufen dauerhaft auf Hochtouren. Daraus ergibt sich am Monatsende eine höhere Rechnung als die vorherige Servermiete.
Cloud-Umgebungen bieten zahlreiche Möglichkeiten: automatisches Hoch- und Runterskalieren bei Lastspitzen, integrierte Sicherheitsfunktionen und einfaches Testen neuer Features. Übertragen Unternehmen ihre Infrastruktur per Lift & Shift jedoch unverändert in die Cloud, entfallen häufig einige der zentralen Vorteile:
Zwar erscheint der Lift & Shift Ansatz anfangs oft günstiger als Neuentwicklungen oder Anpassungen, der Weg sorgt allerdings häufig für höheren Kosten und dafür, dass Vorteile der Cloud nicht ausgeschöpft werden können.
Eine funktionierende Cloud-Migrationsstrategie beginnt mit einer Frage: Was soll die Cloud für das Unternehmen leisten? Je nach Antwort unterscheiden sich die nächsten Schritte stark.
In der Praxis kommen meist verschiedene Wege zum Einsatz, abhängig vom jeweiligen Workload und den Zielen. Diese drei finden besonders häufig Anwendung.
Welcher Weg der richtige ist, hängt vom jeweiligen System, dem Zeitrahmen und dem Budget ab. Nicht jede Anwendung muss vollständig neu gebaut werden, aber Unternehmen sollten jede Anwendung bewusst einordnen.
Unabhängig vom gewählten Migrationspfad braucht es einige Grundlagen, damit die Cloud langfristig Vorteile schafft:
Lift & Shift ist grundsätzlich kein falscher Ansatz, sondern ein guter Weg für simple Anwendungen oder den ersten Start in der Cloud. Grundsätzlich gilt aber: Verschieben Unternehmen Systeme einfach in die Cloud, ohne ihre Eignung zu prüfen und sie anzupassen, entgehen ihnen die Vorteile nativer Cloud-Anwendungen und die Kosten können in die Höhe schnellen. Für eine bedachte Migration sollten Systeme deshalb immer bewusst eingeordnet, klare Ziele definiert und Schritt für Schritt modernisiert werden. Dieser Weg braucht zwar Planung, sorgt aber am Ende für eine saubere Cloud-Infrastruktur, in der die Vorteile voll ausgenutzt werden können.
2026 verschärft Microsoft die Standards für Kerberos in Active Directory: Die veraltete RC4-Verschlüsselung wird schrittweise deaktiviert. Ziel ist es, bekannte Risiken zu reduzieren und die Sicherheitslücke CVE-2026-20833 zu adressieren. Mit den Sicherheitsupdates des ersten Halbjahres im Jahr 2026 wird das Standardverhalten am Key Distribution Center (KDC) phasenweise angepasst. Ohne saubere Vorbereitung kann das zu Authentifizierungsfehlern und Zugriffsproblemen führen.
Der Artikel gibt Ihnen einen kompakten Überblick und zeigt, wie Sie Ihr Unternehmen rechtzeitig dafür prüfen und vorbereiten können.
Um die Änderung einordnen zu können, lohnt sich ein Blick ins Jahr 2022: Damals hat Microsoft ein grundlegendes Standardverhalten definiert. Microsoft steuert die zulässigen Kerberos-Verschlüsselungsalgorithmen über zwei Registry-Einträge: Der eine steuert das domänenweite Standardverhalten (DefaultDomainSupportedEncTypes) und der andere (msds-SupportedEncryptionTypes) steuert das Verhalten dezidiert für Computer und Serverdienste. Mit den Updates aus 2022 und 2026 ändert sich jeweils der implizite Standardwert von DefaultDomainSupportedEncTypes. Wenn man einen anderen Wert möchte, muss man ihn explizit setzen. Der KDC orientiert sich immer dann an DefaultDomainSupportedEncTypes, wenn msds-SupportedEncryptionTypes entweder nicht gesetzt oder 0 entspricht. Beide Werte bestimmen den genutzten Verschlüsselungsalgorithmus für die Kerberos Anmeldung. Das Key Distribution Center ist die Steuerzentrale für das Active Directory und übernimmt die Rolle eines Türstehers, der den Einlass kontrolliert.
Vereinfacht gesagt: vor 2022 akzeptierte der KDC entweder RC4 oder AES – je nachdem, was angefragt wurde. Seit 2022 gilt implizit ein Default von 0x27. Ab 2026 wird der Standardwert auf 0x18 gesetzt.
| Wert | Übersetzung | Bewertung |
| 0x18 | AES-128, AES-256 | ✅ |
| 0x27 | DES, RC4, AES-256-SK | ❌ |
| 0x1C | RC4, AES-128, AES-256 | ⚠️ |
| 0x1F | DES, RC4, AES-128, AES-256 | ❌ |
Wird der Standard auf 0x18 gesetzt, können ältere Systeme oder alte Konfiguration scheitern, wenn Sie auf RC4 angewiesen sind. Der KDC erlaubt nur Algorithmen, die effektiv erlaubt sind.
| Betriebssystem | DES_CBC_CRC | DES_CBC_MD5 | RC4_HMAC_MD5 | AES128_HMAC_SHA1 | AES256_HMAC_SHA1 |
| Windows 2003, Windows XP und älter |
Supported | Supported | Supported | No support | No support |
| Windows Vista | Supported | Supported | Supported | Supported | Supported |
| Windows 2008 | Supported | Supported | Supported | Supported | Supported |
| Windows 2008R2 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 7 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2012 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2012R2 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 10 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2016 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2022 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 11 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2025 | No support | No support | Deactivated | Supported | Supported |
Die automatische Umsetzung wird über den im Januar 2026 eingeführten Wert RC4DefaultDisablementPhase gesteuert. Je nachdem, wie dieser eingestellt ist, werden RC4 Versuche zugelassen, blockiert oder protokolliert.
Bei aktiviertem RC4DefaultDisablementPhase wird AES zum Standard und setzt damit DefaultDomainSupportedEncTypes implizit auf den Wert 0x18. Bei einem aktivierten Audit Wert werden Meldungen generiert, die die fehlende Unterstützung kenntlich machen.
Eine vorzeitige Überprüfung Ihrer Umgebung ist daher dringendst zu empfehlen. Nach Abschluss der Umstellung wird RC4 für Kerberos in einer Active Directory Umgebung deaktiviert und daher erstmal nicht mehr nutzbar sein.
Microsoft unterteilt die Umstellung in drei Phasen:
Visualisierung der drei Update Phasen für Kerberos Änderung
Die erste Phase ist die Audit Phase. In dieser Phase werden zusätzliche Telemetriedaten und Events eingeführt, um Probleme zu identifizieren, bevor die Durchsetzung greift. Ziel ist es, die RC4-Abhängigkeiten sichtbar zu machen und erforderliche Anpassungen rechtzeitig umzusetzen. Optional kann die Deaktivierung von RC4 bereits in dieser Phase manuell vorgezogen werden. Eine vorzeitige Deaktivierung sollte dennoch unbedingt vorab geprüft werden, da sie ansonsten zu Authentifizierungsabbrüchen und damit zu Dienstunterbrechungen führen kann. Für die Auswertung der Events bietet sich eine zentrale Stelle zur Protokollanalyse an (bspw. über Windows Eventlog Forwarding oder SIEM). Die Event ID’s 201-209, 4768-4769 sind zu prüfen.
In der zweiten Phase wird der Standard von RC4 auf AES automatisch gesetzt. Diese Umstellung kann noch rückgängig gemacht werden. Diese Phase ist die letzte Phase, in der Administratoren noch die Flexibilität haben, RC4DefaultDisablementPhase zurückzudrehen. Bevor es zur dritten Phase geht, sollte sichergestellt werden, dass kein Gerät mehr auf RC4 angewiesen ist, da ansonsten die Authentifizierung fehlschlägt.
Die dritte Phase ist die letzte Phase. In dieser Phase gibt es kein einfaches Entrinnen mehr. Die Durchsetzung greift ein und deaktiviert RC4. Eine Reaktivierung über RC4DefaultDisablementPhase ist dann nicht mehr möglich. Wenn Sie diese Phase überstanden haben und Ihre Serverdienste weiterhin laufen, haben Sie gute Arbeit geleistet.
Beides sind weitverbreitete Verschlüsselungsalgorithmen. RC4 war lange Bestandteil von vielen Softwares, da es im Vergleich zu AES effizienter und eine größere Abwärtskompatibilität gewährleistet.
Der Rivest Cipher 4 (RC4) Verschlüsselungsalgorithmus ist kryptografisch unsicher und kann durch sogenannte „Roasting Attacken“ wie dem Kerberoasting ausgenutzt werden. Hierbei fordert ein Angreifer ein Kerberos Ticket an und „brute forced“ offline das Passwort des Authentifizierungstickets. Gelingt es, das Passwort zu knacken, sind u.a. weitergehende Ticket-Manipulation wie dem Silver Ticket möglich, um sich Zugriff auf Dienste zu verschaffen.
Sie müssen handeln, wenn Sie eine Active Directory oder Hybrid-Umgebung nutzen. Sobald sich ein Legacy Gerät im Netzwerk befindet und das Update eingespielt wird, schlägt die Kerberos Authentifizierung fehl und es kommt zu einem Fallback zu NTLM. Bei NTLM gibt es ganz andere Angriffsvektoren, die zu beheben sind. Wenn Sie NTLM bereits erfolgreich unterbunden haben, schlägt die Anmeldung grundlegend fehl. Ggf. müssen Sie regulatorische Anforderungen (wie NIS2, DORA, ISO/IEC 27001 etc.) nachkommen und wollen daher beim Audit glänzen. Das können Sie nur, wenn Sie RC4 deaktivieren und AES die Bühne geben.
Um obiges kurz und knapp zusammenzufassen, hier eine Handlungsempfehlung zu der bevorstehenden technischen Umstellung seitens Microsofts. Es ist wichtig, dass Sie sich unbedingt vorab ein Bild Ihrer Umgebung machen. Die Umstellung findet automatisch statt und kann im schlimmsten Fall den Zugriff auf Serverdienste einschränken.
Bei Fragen oder Anregen zum Thema Active Directory oder Kerberos Authentfizierung stehen wir Ihnen gerne beratend zur Seite. Wir freuen uns auf Ihre Kontaktaufnahme.
SAP hat angekündigt, SAP Build Apps als eigenständiges Standalone‑Produkt zum 30. September 2026 einzustellen.
Für viele Unternehmen ist das mehr als eine übliche Produktabkündigung. Bestehende Anwendungen lassen sich nicht einfach „umstellen“. Sie müssen neu gedacht und in vielen Fällen manuell neu aufgebaut werden.
Genau deshalb ist eine Build Apps Migration kein reines Technikprojekt. Sie ist eine geplante Transition, die mehrere Ebenen betrifft: das Applikationsportfolio, die Architektur, den Betrieb und nicht zuletzt die benötigten Skills.
Dieser Artikel ordnet die Entscheidung der SAP ein, beschreibt die wichtigsten technischen Konsequenzen und zeigt realistische Handlungsoptionen auf. Dazu zählen der Wechsel in das neue SAP Build Angebot, ein Neubau mit SAPUI5 und CAP sowie der Einsatz von Drittanbieter‑Plattformen.
Die Zielgruppe sind IT‑Leitungen, Enterprise‑ und Solution‑Architekt:innen, Product Owner sowie Verantwortliche für SAP BTP, die bestehende Build‑Apps‑Anwendungen absichern und eine tragfähige Nachfolgestrategie entwickeln müssen.
Um die Tragweite der Abkündigung zu verstehen, hilft ein kurzer Blick in die Vergangenheit: SAP übernahm AppGyver im Februar 2021 und integrierte die No‑Code‑/Low‑Code‑Plattform später als SAP Build Apps in die SAP BTP. Der Ansatz passt zur propagierten Clean‑Core‑Strategie, da so Erweiterungen außerhalb des S/4HANA‑Kerns ermöglicht wurden.
Bereits zuvor gab es erste Einschnitte. Die AppGyver Community Edition verlor ihren Support zum 30. September 2024. Im April 2025 folgte schließlich der Launch des Unified SAP Build Ansatzes. Apps, Prozesse und Work‑Zone‑Themen wurden stärker zusammengeführt und in eine gemeinsame Lobby integriert.
Die Abkündigung der Standalone‑Variante ist eine Weiterführung dieser Konsolidierung. SAP möchte die Werkzeuge für Anwendungen, Prozessautomatisierung und Portale in einem integrierten Angebot bündeln.
Auf dem Papier wirkt das vereinfachend. Für Bestandskunden bedeutet es jedoch einen harten Schnitt. Das frühere Standalone Build Apps basiert technologisch auf anderen Grundlagen als das neue Unified‑Umfeld.
Die wichtigste technische Aussage lässt sich klar zusammenfassen: Für Frontend‑Projekte existiert kein automatisierter Migrationspfad.
Konkret bedeutet das, dass Seiten, Datenbindungen, Logikflüsse, Navigationen und individuelle Komponenten in der Zielumgebung manuell neu aufgebaut werden müssen.
Was viele Teams an Build Apps überzeugt hat – die visuelle Modellierung von Logikflüssen – wird in der Transition zur größten Herausforderung. Es gibt kein Werkzeug, das visuelle Logikdiagramme automatisiert in die neue Architektur überführt. Der Grund hierfür liegt in den unterschiedlichen Grundlagen der Systeme. Während das ursprüngliche Build Apps unter anderem auf steroids.js und AngularJS basierte, orientiert sich das neue Unified‑Angebot an SAP‑Standards wie SAPUI5 und dem Cloud Application Programming Model (CAP).
Das bedeutet nicht, dass ein Migrationspfad grundsätzlich unmöglich gewesen wäre. SAP hat sich jedoch bewusst dagegen entschieden, auch für Standardszenarien einen solchen bereitzustellen.
In der Praxis müssen bestehende Anwendungen daher zunächst sauber dokumentiert und anschließend neu implementiert werden. Betroffen sind unter anderem Variablenbindungen, Formeln, Event‑Handler, Navigationslogik sowie Custom‑JavaScript‑Komponenten.
Für Backend‑Projekte beschreibt SAP zumindest einen rudimentären Weg, Daten zu übernehmen. Dieser Ansatz ist jedoch eher eine manuelle Datenrettung als eine Migration im klassischen Sinn.
Entitäten werden einzeln aus dem Datenbrowser als CSV‑Dateien exportiert. In der Zielumgebung – idealerweise in einem CAP‑Projekt – müssen passende Tabellen manuell angelegt werden. Anschließend erfolgt der Import der CSVs.
Nicht automatisch übernommen werden dabei Beziehungen zwischen Entitäten, Metadaten, Berechtigungsstrukturen und weitere implizite Regeln. Genau diese Aspekte sind in produktiven Anwendungen häufig kritisch. Zusätzlich entsteht ein Integrationsrisiko: Wenn bestehende Frontends Services konsumieren, sollten neue CAP‑Services möglichst kompatible API‑Signaturen bereitstellen, um den Anpassungsaufwand im Frontend zu begrenzen.
Wenn Sie SAP Build Apps produktiv einsetzen, sollten Sie die Situation nicht als „ein Projekt“ betrachten, sondern als Portfolio‑Entscheidung.
Nicht jede Anwendung benötigt denselben Zielpfad.
Ein strukturiertes Application‑Portfolio‑Management hilft, Prioritäten zu setzen. Typische Kriterien sind strategische Relevanz, technische Komplexität und Änderungsdynamik.
SAP garantiert den weiteren Betrieb bis zum Ende laufender Verträge. Das gilt unabhängig vom Lizenzmodell. SLAs und Wartungszusagen bleiben bestehen.
Diese Option ist jedoch mit Einschränkungen verbunden. Für die Standalone‑Version sind keine neuen Funktionen vorgesehen. Neue Sicherheitsstandards oder Innovationen wie die tiefere Integration von Joule fließen primär in das Unified Offering.
Zudem wird es zunehmend schwieriger, qualifizierte Fachkräfte für eine auslaufende Technologie zu finden.
Abwarten kann daher sinnvoll sein, wenn Anwendungen stabil sind oder ohnehin vor September 2026 abgelöst werden. Für alle anderen stellt es meist nur einen zeitlichen Aufschub dar.
Der offizielle SAP‑Pfad ist der Umstieg auf das vereinheitlichte SAP Build Angebot.
Der Mehrwert liegt nicht in einer automatisierten Migration, sondern in einer konsolidierten Entwicklungsumgebung. Low‑Code, Pro‑Code und KI‑gestützte Funktionen sind zentral gebündelt.
Viele Unternehmen nutzen den Neubau gezielt, um technische Schulden abzubauen. Anwendungen werden auf einer moderneren Architektur neu aufgesetzt – mit klarer Trennung von Frontend, Services und Datenmodell.
Gleichzeitig sollte kritisch geprüft werden, ob und in welchem Umfang Investitionen in ein weiteres SAP‑Innovationsprodukt sinnvoll sind, dessen langfristige Stabilität sich erst bewähren muss.
Für geschäftskritische Anwendungen ist der Einschnitt ein Anlass, wieder stärker auf Pro‑Code zu setzen.
CAP und SAPUI5 gelten als strategische SAP‑Standards. Sie bieten langfristige Wartbarkeit und reduzieren die Abhängigkeit von kurzfristigen Tool‑Entscheidungen.
CAP strukturiert die Service‑Entwicklung und etabliert bewährte Enterprise‑Patterns. UI5 – ergänzt durch Fiori Elements – kann die Entwicklung standardisierter Oberflächen beschleunigen.
Der höhere Schulungsaufwand ist real, rechnet sich aber häufig über den Lebenszyklus zentraler Anwendungen.
Einige Unternehmen evaluieren bewusst Alternativen außerhalb des SAP‑Portfolios. Das ist insbesondere dann sinnvoll, wenn Fachbereiche stark eingebunden sind, Time‑to‑Market im Fokus steht oder mobile Szenarien besondere Anforderungen stellen.
Plattformen wie Simplifier, Neptune DXP oder Mendix adressieren unterschiedliche Schwerpunkte – von schneller Fiori‑Entwicklung über ABAP‑nahe Architekturen bis hin zu komplexen, systemübergreifenden Anwendungen.
Gleichzeitig erhöht ein Drittanbieter die Abhängigkeiten, beeinflusst Lizenzkosten und steigert die Komplexität der Landschaft. Dieser Weg sollte daher gut abgewogen sein.
Die größte Gefahr in solchen Umbruchphasen ist Aktionismus: Einzelne Apps werden hektisch neu gebaut, während das Gesamtportfolio unklar bleibt. Besser ist ein klarer Ablauf, der technische und organisatorische Arbeitspakete verbindet.
Der erste Schritt ist eine vollständige Inventarisierung Ihrer SAP Build Apps Lösungen:
Daraus entsteht eine Priorisierung nach strategischer Relevanz und technischer Komplexität. So vermeiden Sie, dass knappe Kapazitäten in Apps fließen, die ohnehin abgelöst werden.
Zum Schluss entscheidet die Umsetzungsgeschwindigkeit oft über Erfolg oder Stillstand. Deshalb ist es sinnvoll, frühzeitig Pilot‑Apps auszuwählen: eine einfache, eine mittelkomplexe und eine kritische App. Auf dieser Basis können Sie Standards für Architektur, Security, Naming, Transport/Deployment und Tests definieren und diese Standards danach konsequent für die restliche Build Apps Migration anwenden.
SAP setzt stark auf generative KI, um den Neubau zu beschleunigen. Joule soll in SAP Build Code und Build Apps helfen, Anforderungen schneller in umsetzbare Strukturen zu übersetzen. Der Trend geht damit von reinem Low‑Code stärker in Richtung „KI‑assistierter“ Entwicklung, bei der Menschen Ergebnisse prüfen, integrieren und absichern.
Wichtig ist hier aber die Erwartungshaltung: KI kann Zeit sparen, sie ersetzt aber nicht die Kernarbeit der Transition – also saubere Zielarchitektur, klare Verantwortlichkeiten, Sicherheitskonzept, Tests und Betriebsprozesse.
Cloud-Umgebungen wachsen oft schneller als Teams sie manuell verwalten können. Zwar sind sie in kleinen Infrastrukturen noch überschaubar, können allerdings schnell zum Problem werden, sobald die Infrastruktur komplexer wird. Änderungen dauern zu lange, Fehler können sich einschleichen und Entwickler warten auf Ressourcen, um weiterarbeiten zu können. Um sowohl Entwicklern als auch dem Platform-Team die Arbeit zu erleichtern, können verschiedene Prozesse automatisiert werden. In diesem Artikel geben wir einen Überblick, wie Automatisierung im Cloud Platform Engineering aussehen kann und welche Vorteile sie Unternehmen bringt.
Ohne Automatisierung ist Cloud Platform Engineering komplex: Jede Entwicklungsumgebung muss manuell aufgesetzt werden. Dadurch können sich Releases verzögern, Umgebungen inkonsistent sein und eine aufwendige Koordination ist nötig. Auch das Fehlerpotenzial ist entsprechend höher: Je mehr manuelle Eingriffe ein Prozess erfordert, desto wahrscheinlicher wird ein Versehen und desto schwerer lässt sich das Problem im Nachhinein nachvollziehen.
In der Praxis bedeutet das: Tickets stapeln sich, Teams verschieben Deployments und das Platform-Team wird zum Flaschenhals, weniger zum Enabler. Gerade beim Aufsetzen der Umgebungen gibt es jedoch zahlreiche wiederkehrende und regelbasierte Aufgaben, die sich an Anforderungen und Compliance-Richtlinien des Unternehmens orientieren. Um das Platform-Team zu entlasten und verlässlich und schnell Umgebungen aufsetzen zu können, kann Automatisierung auf verschiedenen Wegen umgesetzt werden.
Im Cloud Platform Engineering gibt es nicht die eine Automatisierung oder das eine Automatisierungs-Tool. Vielmehr können Unternehmen in mehreren Bereichen Tools und Konzepte einsetzen, die sich gegenseitig ergänzen. Dabei kann es beispielsweise um die Bereitstellung der Infrastruktur gehen, die eigenständige Arbeit der Entwickler oder den permanenten Blick auf den Betrieb.
Bei CI/CD-Pipelines handelt es sich um einen automatisierten Prozess, der Änderungen am Code kontinuierlich integriert (Continuous Integration), testet und bereitstellt (Continuous Deployment). Das Prinzip dahinter, Infrastructure as Code, sorgt dafür, dass Umgebungen nicht mehr per Hand konfiguriert werden müssen. Stattdessen entstehen sie durch reproduzierbare, beschreibbare Vorlagen.
In einer automatisierten Pipeline durchläuft jede Änderung an der Infrastruktur mehrere Schritte, bevor sie in den Release geht: automatische Validierung, Sicherheitschecks und Testläufe. Fehler werden so früh erkannt und nicht erst dann, wenn sie bereits Auswirkungen haben. So entstehen konsistentere Umgebungen, weniger manuelle Eingriffe und deutlich kürzere Durchlaufzeiten bei Änderungen.
Die wichtigsten Vorteile auf einen Blick:
Gerade in wachsenden IT-Teams entsteht oft die gleiche Herausforderung: Entwickler müssen auf Ressourcen warten, weil jede Anfrage über das Platform-Team läuft. Mit Self-Service-Portalen können Unternehmen dieses Problem lösen, indem sie standardisierte Bausteine bereitstellen, die Entwickler eigenständig nutzen können. Dafür brauchen sie kein technisches Spezialwissen und sparen sich Wartezeiten.
Die Plattform dabei stellt sicher, dass alles, was über das Portal geschieht, den internen Standards für Sicherheit und Compliance entspricht. Entwickler arbeiten schneller und unabhängiger. Das Platform-Team wiederum gewinnt Zeit im Arbeitsalltag.
Die wichtigsten Vorteile auf einen Blick:
Neben dem Rollout gibt es auch im laufenden Betrieb Möglichkeiten zur Automatisierung. Vom Monitoring bis zur automatischen Reaktion auf Probleme können Unternehmen verschiedene Automatisierungen umsetzen.
Wichtig ist vor allem der Unterschied zwischen klassischem Monitoring und moderner Observability: Monitoring zeigt auf, dass etwas nicht stimmt, Observability hingegen gibt Aufschluss darüber, warum etwas nicht stimmt. Durch automatisierte Alarme, strukturierte Protokolle und nachvollziehbare Metriken können Teams proaktiv handeln. Teilweise gibt es bereits Systeme, die bekannte Probleme selbstständig korrigieren können, ohne dass ein Mensch eingreifen muss.
Die wichtigsten Vorteile auf einen Blick:
Die Wirkung von Automatisierung im Cloud Platform Engineering zeigt sich auf verschiedenen Ebenen, von der Geschwindigkeit bis zur Kosteneffizienz.
Automatisierung ist ein wichtiger und grundlegender Bestandteil im Cloud Platform Engineering. Durchdachte Automatisierungsstrukturen schaffen die Voraussetzungen für schnellere Entwicklung, höhere Zuverlässigkeit und Cloud Plattformen, die mit den Anforderungen des Unternehmens wachsen können. Zwar lohnt es sich schon von Anfang an, Automatisierung in die Cloud Infrastruktur zu integrieren, aber auch nachträglich können Tools und Konzepte integriert werden. Dabei ist es am sinnvollsten, mit den Bereichen zu beginnen, die den größten Engpass verursachen und von dort aus strukturiert weiterzubauen. So entsteht mit der Zeit eine zuverlässige Automatisierungsstruktur.
Nachdem wir im im ersten Teil unserer Blogreihe das Extensibility-Modell grundlegend betrachtet haben, widmen wir uns nun der praktischen Anwendung bei der Erweiterung von SAP S/4HANA. Die fundamentale Systementscheidung für eine Architektur auf der SAP Business Technology Platform (BTP) gegenüber einem On-Stack-Ansatz definiert maßgeblich die Performance, Wartbarkeit und Skalierbarkeit künftiger Entwicklungen. Eine klare S/4HANA Erweiterungsstrategie hilft dabei, die Vorteile beider Welten effizient zu nutzen. Während direkte Erweiterungen im ERP-Kern einen tiefgreifenden Zugriff auf lokale Geschäftsprozesse bieten, eröffnet die Cloud neue Wege für die Integration von Drittsystemen und externen Nutzergruppen. Dieser Artikel bietet konkrete Entscheidungskriterien für technische Projektleiter, Enterprise-Architekten und leitende SAP-Entwickler.
Die Entwicklung direkt im S/4HANA-System stellt die engste Form der Systemerweiterung dar. Sie unterteilt sich heute in zwei primäre Bereiche, wobei die Key User Extensibility vor allem Anwender mit tiefem Prozessverständnis anspricht. Diese können über integrierte Wizard-Tools benutzerdefinierte Felder, einfache Validierungen oder analytische Ansichten generieren, ohne tiefgehende Programmierkenntnisse zu besitzen. Mit dem Release S/4HANA 2025 FPS01 hat SAP diesen Bereich funktional deutlich aufgewertet. Es ist nun möglich, vollwertige Fiori-Elements-Anwendungen für benutzerdefinierte Geschäftsobjekte mit wenigen Klicks zu erstellen und die Verhaltenssteuerung für SAP-eigene Objekte nahtlos anzupassen.
Sobald die fachlichen Anforderungen komplexer werden, kommt die Developer Extensibility zum Einsatz. Sie stellt professionellen Entwicklern das moderne ABAP Cloud Modell zur Verfügung. Der entscheidende architektonische Vorteil dieses On-Stack-Ansatzes liegt in der physischen und logischen Nähe zu den Geschäftsdaten. Dadurch bleiben die transaktionale Integrität und hohe Ausführungsgeschwindigkeiten gewahrt, da keine externen Schnittstellenaufrufe notwendig sind.
Im Gegensatz dazu steht die Side-by-Side Extensibility auf der SAP BTP, bei der Applikationen vollständig außerhalb des ERP-Kerns entwickelt und betrieben werden. Die Kommunikation erfolgt ausschließlich über lose gekoppelte, freigegebene Remote-APIs oder asynchrone Ereignisse über den Event Mesh. Dieses Modell eignet sich besonders für Applikationen, die für externe Endnutzer wie Lieferanten oder Endkunden gedacht sind. Die BTP fungiert hierbei als sichere, isolierte Zone, die den internen ERP-Kern schützt. Zudem ist dieses Muster ideal für Partner, die eigenständige und mandantenfähige Software-as-a-Service Lösungen entwickeln möchten.
Bei der Wahl des Programmiermodells innerhalb der S/4HANA Erweiterungsstrategie stehen das SAP Cloud Application Programming Model (CAP) und das ABAP RESTful Application Programming Model (RAP) im Fokus. Während Entwicklungen über das RAP-Modell On-Stack meist keine zusätzlichen Lizenzkosten verursachen, erfordert die ABAP Environment auf der BTP eine eigene Subskription. Im Vergleich dazu bieten CAP-Anwendungen auf Cloud Foundry ein granulareres Preismodell, was je nach Projektumfang wirtschaftlicher sein kann.
Die Entscheidung zwischen On-Stack und Side-by-Side erfordert eine genaue Analyse der Datenströme, da eine Lösung auf der BTP nicht automatisch effizienter ist. Ein kritischer Faktor bleibt die physikalische Bindung von Daten an ihren Ursprungsort. Wenn Millionen von Datensätzen über OData-Schnittstellen übertragen werden, entstehen unweigerlich Performance-Engpässe, sofern der BTP-Subaccount und das S/4HANA-System nicht geografisch und infrastrukturell optimal aufeinander abgestimmt sind.
Neben den Latenzen stellt die sogenannte Principal Propagation eine administrative Hürde dar. Sie erfordert eine komplexe Konfiguration des SAP Cloud Connectors sowie den Import von Zertifikaten und regelbasierte Mappings im System. On-Stack-Erweiterungen punkten hier durch die native Nutzung lokaler Berechtigungskonzepte, was die Stabilität erhöht. Cloud-Szenarien verlangen hingegen eine exakte Synchronisation der Identitätsdaten zwischen dem lokalen System und dem Cloud-Identitätsanbieter.
Um Ihnen die Navigation durch diese komplexen Abwägungen zu erleichtern, bietet die folgende Infografik eine grobe Entscheidungsgrundlage, welche die wichtigsten Kriterien von der Datenlast bis hin zum Nutzerkreis visualisiert.
Da keine der beiden Varianten isoliert alle modernen Anforderungen abdeckt, liegt die optimale Lösung für komplexe Szenarien häufig in einer hybriden Architektur. Hierbei werden datenintensive Kernprozesse performant On-Stack mittels ABAP Cloud abgewickelt, während kundenorientierte Frontends oder die Integration von Drittsystemen flexibel über die BTP realisiert werden. Die Wahl der Bereitstellungsform beeinflusst langfristig sowohl die Backend-Performance als auch die Flexibilität Ihrer Systemlandschaft. Im dritten Teil dieser Serie analysieren wir, wie sich diese Faktoren künftig auf Benutzeroberflächen und die Integration von künstlicher Intelligenz auswirken.
Gerne unterstützen wir Sie bei diesen komplexen Fragestellungen durch detaillierte Machbarkeitsstudien, um die perfekte Balance zwischen Cloud-Innovation und ERP-Stabilität für Ihr Unternehmen zu finden. Kontaktieren Sie uns für ein unverbindliches Beratungsgespräch oder lesen Sie unsere weiteren Blogartikel zu den Themen Clean Core und SAP BTP Integration.
Die Architektur von Unternehmenssoftware durchläuft einen fundamentalen Wandel. Historisch gewachsene ERP-Landschaften zeichnen sich durch tiefgreifende, monolithische Strukturen aus. Kundenindividueller Code greift häufig in Form von Modifikationen oder User Exits direkt und ungeschützt in den Kern des Systems ein. Diese über Jahrzehnte übliche Praxis führt heute zu erheblicher technischer Schuld, bremst die Agilität von Unternehmen, und macht Systemupgrades komplex und kostenintensiv. Um in einem dynamischen Marktumfeld wettbewerbsfähig zu bleiben, ist die Umsetzung einer Clean Core Strategie unerlässlich. Diese fordert eine strikte technologische Entkopplung von Standardsoftware und individuellen Anpassungen. Unser erster Beitrag dieser dreiteiligen Blogreihe richtet sich gezielt an Enterprise Architekten, leitende SAP-Entwickler und IT-Strategen, die eine performante, wartbare und zukunftssichere Systemlandschaft konzipieren möchten.
Der Begriff des „sauberen Kerns“ wird in der globalen Entwicklergemeinschaft intensiv diskutiert und oft missverstanden. Kundenindividueller Code muss nicht vollständig vermieden werden. „Clean Core“ bedeutet Erweiterung technologisch so zu entkoppeln und zu standardisieren, dass der eigentliche SAP-Standard unangetastet bleibt. Dadurch lassen sich künftige Releases ohne manuellen Anpassungsaufwand einspielen. Das Ziel ist es, Upgrades reibungslos zu gestalten, Altlasten abzubauen und neue Technologien wie Künstliche Intelligenz nahtlos zu integrieren. Für einen dauerhaft effizienten Betrieb stützt sich dieses Architekturkonzept auf fünf Kernprinzipien: durchgängige Prozesse, nahtlose Integration, verlässliche Datenqualität, effiziente Operations und eine standardisierte Erweiterbarkeit.
Im Bereich der Erweiterbarkeit hat die SAP ihre Vorgaben zuletzt stark an die Realität historisch gewachsener Systeme angepasst. Ursprünglich wurde der Entwickler-Community ein striktes Drei-Tier-Modell vorgegeben. Dieses unterschied zwischen Cloud-konformen Erweiterungen (Tier 1), Brückenlösungen (Tier 2) und klassischen, modifizierenden Anpassungen (Tier 3). Dieses binäre System aus „erlaubt“ und „verboten“ erwies sich jedoch in der Migrationspraxis als viel zu restriktiv. Als Lösung führt die SAP ein differenziertes Modell mit vier Leveln ein, das die Kompatibilität von Erweiterungen wesentlich granularer bewertet und einen realistischeren Transformationspfad aufzeigt.
Das sogenannte A-D Extensibility Modell klassifiziert den individuellen Code anhand seiner technischen Umsetzung und der genutzten Schnittstellen in folgende vier Kategorien beziehungsweise Stufen:
Level A (ABAP Cloud Readiness): Die sauberste Form der Erweiterung nutzt exklusiv offiziell freigegebene SAP-APIs sowie das ABAP Cloud Entwicklungsmodell. Diese Stufe garantiert höchste Upgrade-Stabilität ohne manuellen Anpassungsaufwand und ist vollständig Cloud-ready.
Level B (Classic SAP APIs): Auf dieser Ebene nutzt der Code klassische, gut dokumentierte SAP-APIs wie BAPIs oder freigegebene BADIs und folgt den etablierten Best Practices für die klassische ABAP-Entwicklung. Diese Stufe bietet eine sehr hohe Stabilität, erfordert bei Upgrades in der Regel nur marginale funktionale Prüfungen und gilt im Rahmen von Private Cloud Deployments oder On-Premise-Szenarien als valide und zukunftssichere Basis.
Level C (Unreleased SAP Objects): Diese Stufe umfasst die Nutzung interner SAP-Objekte, die nicht offiziell für Kunden freigegeben wurden. Die Stabilität ist hier nur bedingt gegeben, da vor jedem Upgrade eine zwingende technische Verifizierung der genutzten Objekte über das Changelog erforderlich ist.
Level D (Modifications & Technical Debt): Diese kritische Stufe umfasst die Nutzung explizit nicht empfohlener Objekte, direkte Kernmodifikationen des SAP-Standards oder veraltete, invasive Techniken wie implizite Enhancements. Code auf diesem Level erzeugt massive technische Schulden, verhindert reibungslose Upgrades und muss im Rahmen der Transformation zwingend in höhere Level refaktoriert werden.
Die rein theoretische Definition dieser vier Level reicht für eine erfolgreiche und nachhaltige Architektur-Transformation jedoch bei Weitem nicht aus. Es bedarf einer strengen Governance, um sicherzustellen, dass Entwicklungsteams diese Leitplanken im Arbeitsalltag konsequent einhalten. Die technische Einhaltung dieser strikten Vorgaben wird durch das ABAP Test Cockpit (ATC) unterstützt, welches den Code automatisiert auf seine ABAP Cloud Readiness prüft und detaillierte Fehler oder Warnungen ausgibt, sobald ein Entwickler den im System definierten Clean Core Standard verlässt. Um Entwicklern den Übergang zu erleichtern, stellt die SAP den SAP Extensibility Explorer sowie das Cloudification Repository zur Verfügung. So können Sie bereits in der Designphase freigegebene Schnittstellen identifizieren und neue Erweiterungen direkt konform zu Level A entwickeln.
Trotz dieser klaren strategischen Ausrichtung gibt es in der realen Projektpraxis weiterhin erhebliche Herausforderungen. Die Deutschsprachige SAP-Anwendergruppe (DSAG) hat diese kritische Situation bereits auf den Technologietagen 2025 unter dem Motto „Strategy Royale: Call, Raise or Fold?“ intensiv diskutiert. Die mit Abstand größte technische Hürde bei der Umsetzung der Clean Core Paradigmen ist derzeit die mangelnde Verfügbarkeit von Level-A-kompatiblen, freigegebenen Schnittstellen.
Wie sich diese theoretischen Vorgaben in der Praxis umsetzen lassen und welche Kriterien die architektonische Entscheidung zwischen On-Stack-Erweiterungen und Side-by-Side-Bereitstellungen beeinflussen, beleuchten wir im zweiten Teil dieser Blogreihe.
Eine fundierte Entscheidung bildet hier das Rückgrat Ihrer digitalen Transformation. Unser Expertenteam begleitet Sie gerne bei der strategischen Neuausrichtung Ihrer Systemlandschaft. Wir führen tiefgreifende Code-Analysen Ihres S/4HANA-Systems mittels ATC durch und erarbeiten einen belastbaren Refactoring-Plan, um Ihre historischen Modifikationen sicher in die Level A und B zu überführen. Nehmen Sie Kontakt mit uns auf, um Ihre individuelle Roadmap für einen Clean Core zu definieren.
Mobile Endgeräte sind fester Bestandteil im Arbeitsalltag zahlreicher Unternehmen geworden. Smartphones, Tablets und Laptops ermöglichen flexibles Arbeiten – ob im Büro, im Homeoffice oder unterwegs. Je mehr Geräte allerdings im Umlauf sind, desto komplexer wird ihre Verwaltung. Mobile Device Management bietet Unternehmen die technische Grundlage, um alle Geräte zentral zu steuern, abzusichern und zu überwachen. Die rein technische Umsetzung reicht jedoch noch nicht aus. Auch alle Mitarbeitenden müssen wissen, wie sie mit ihren Geräten umgehen sollen und welche Richtlinien warum gelten. Deshalb lohnen sich MDM-Schulungen für alle Mitarbeitenden im Zuge der Einführung des Mobile Device Managements. Warum diese Schulungen wichtig sind, welche Inhalte sie vermitteln sollten und welche Formate sich eignen, erklären wir in diesem Artikel.
Zahlreiche Sicherheitsvorfälle entstehen durch menschliche Fehler, weniger durch technische Schwachstellen. Mitarbeitende, die nicht wissen, welche Apps sie auf ihrem Dienstgerät installieren dürfen oder wie sie mit Unternehmensdaten auf privaten Geräten umgehen sollen, machen eines der größten Risiken für die IT im Unternehmen aus. Mit MDM-Lösungen können entsprechende Sicherheitsrichtlinien umgesetzt werden, erfordern allerdings Verständnis und Akzeptanz der User, das durch Schulungen entsteht. Andernfalls entstehen verschiedene Risiken:
An dieser Stelle sind auch Anforderungen der DSGVO und der NIS2-Richtlinie relevant. Beide fordern, dass Unternehmen neben technischen Maßnahmen für die IT-Sicherheit auch organisatorische Maßnahmen etablieren. Dazu zählen auch Mitarbeiterschulungen, die das Team über richtige Verhaltensweisen und Schutzmaßnahmen aufklären.
Eine gute MDM-Schulung geht einerseits auf technisches Grundwissen ein und schafft andererseits ein Verständnis für den Sinn hinter verwalteten Geräten und Sicherheitsmaßnahmen. Verstehen alle Teams, warum Regeln gelten, steigt die Akzeptanz und Mitarbeitende halten sich daran. Wichtig ist dabei auch: Passen Sie die Inhalte auf die jeweilige Zielgruppe an. Für IT-Administratoren sind andere Grundlagen und Themen wichtig als für Mitarbeitende im Vertrieb oder Kundenservice.
Für alle Mitarbeitenden eignen sich diese Inhalte:
Für IT-Verantwortliche und Administratoren kommen weitere Themen hinzu, etwa die Konfiguration von Geräteprofilen, das Management von App-Berechtigungen oder die Auswertung von Compliance-Reports. Durch eine klare Unterscheidung dieser Zielgruppen stellen Sie sicher, dass die Schulungen effizient sind und die Informationen wirklich relevant sind.
Natürlich ist es wichtig, was Teams im Zuge der MDM-Schulungen lernen. Zentrale Frage ist aber auch, wie sie die nötigen Infos vermittelt bekommen. Dafür können Unternehmen verschiedene Wege wählen:
Den Erfolg der MDM-Schulungen können Sie beispielsweise durch kleine Wissenstests nach einzelnen Einheiten überprüfen. Holen Sie sich außerdem Feedback ein, ob an den Schulungen etwas verbessert werden kann, um für zukünftige Einheiten zu lernen.
Wichtig ist auch: MDM-Lösungen entwickeln sich ständig weiter. Deshalb reicht eine einmalige Schulung meist nicht aus. Neue Gerätetypen, aktualisierte Unternehmensrichtlinien oder neue gesetzliche Vorgaben erfordern regelmäßige Updates. Sinnvoll ist es daher, MDM-Schulungsinhalte jährlich aufzufrischen und zusätzliche Schulungen einzuplanen, wenn es größere Änderungen gibt.
Oft werden MDM-Schulungen als notwendige Compliance-Maßnahme angesehen. Dabei sorgen sie dafür, dass alle Teams die Regeln und Vorgaben rund um die Geräteverwaltung verstehen und akzeptieren und reduzieren somit die Sicherheitsrisiken für die IT des gesamten Unternehmens. Je besser Mitarbeitende nämlich verstehen, warum Regeln gelten, desto weniger fühlen sie sich kontrolliert und desto eher halten sie sich an sie. Unternehmen schaffen so die Grundlage für sichere Remote-Arbeit.
Ein Termin wird kurzfristig abgesagt.
Familiärer Krankheitsfall.
Keine Vertretung.
Alles hängt an einer Person.
Was im Alltag nachvollziehbar ist, wird in der IT zum Risiko:
– Ein Single Point of Failure
Die entscheidende Frage lautet:
Wie viele solcher Abhängigkeiten gibt es in Ihrem Unternehmen, ohne dass Sie es wissen?
Kritisches Wissen liegt bei einzelnen Personen
Systeme sind nicht einheitlich abgesichert
Prozesse sind nicht ausreichend dokumentiert
Vertretungsregelungen existieren nur auf dem Papier
Solange alles läuft, bleibt das unsichtbar.
Doch im Ernstfall führt genau das zu:
Mit NIS2, ISO 27001 und neuen regulatorischen Anforderungen verändert sich IT-Sicherheit grundlegend:
Weg von Einzelmaßnahmen
Hin zu nachweisbarer Resilienz
Unternehmen müssen heute zeigen können:
Welche Risiken bestehen
Welche Maßnahmen umgesetzt wurden
Wie Systeme abgesichert sind
Wie Ausfälle abgefangen werden
„Wir haben das im Griff“ reicht nicht mehr.
Moderne IT-Sicherheit basiert auf zwei Säulen:
System Hardening (IT-Härtung)
Sichere Konfigurationen
Zugriffskontrollen
Monitoring & Logging
Klare Verantwortlichkeiten
Dokumentierte Prozesse
Vertretungsregelungen
Notfall- und Wiederanlaufpläne
Erst die Kombination macht Ihr Unternehmen wirklich widerstandsfähig.
Wir setzen genau dort an, wo die größten Risiken entstehen:
Analyse Ihrer Systeme, Prozesse und Abhängigkeiten
Identifikation von Schwachstellen (z. B. Single Points of Failure)
Welche Ausfälle hätten welche Auswirkungen?
Wo besteht akuter Handlungsbedarf?
Technisch (Hardening, Zugriffskonzepte)
Organisatorisch (Vertretung, Prozesse, Richtlinien)
Einführung sicherer Standards (z. B. CIS Benchmarks)
Strukturierte Umsetzung statt Insellösungen
Dokumentation für Audits (ISO 27001, NIS2)
Kontinuierliche Verbesserung
Ergebnis: Sicherheit, die funktioniert und geprüft standhält
Was passiert bei Ihnen, wenn morgen eine Schlüsselperson ausfällt?
Läuft alles weiter?
Oder steht ein Teil Ihres Unternehmens still?
Lassen Sie uns gemeinsam herausfinden, wo Ihre größten Risiken liegen und wie Sie diese strukturiert beseitigen.
Jetzt unverbindlich anfragen:
Kontaktieren Sie uns für eine erste Einschätzung
Rewion – Ihr Partner für IT-Härtung, ISO 27001 & NIS2-Compliance
Lesen sie auch: Warum ISO 27001 und NIS2 keine Bedrohung, sondern eine strategische Chance sind.
Auch interessant alle Themen und Informationen beim: BSI
Phishing beschreibt den Versuch, Menschen über gefälschte E‑Mails, Nachrichten oder Webseiten dazu zu bringen, vertrauliche Informationen preiszugeben oder schädliche Aktionen auszuführen wie zum Beispiel etwa das Öffnen eines Links, das Eingeben von Zugangsdaten oder das Freigeben von Zahlungen.
2026 ist Phishing besonders kritisch, weil:
Der Mensch ist damit mehr denn je das primäre Angriffsziel.
Künstliche Intelligenz wirkt bei Phishing als Multiplikator. Sie ersetzt keine Angreifer, sondern macht sie schneller, präziser und skalierbarer.
Moderne KI generiert fehlerfreie, realistisch klingende Texte, angepasst an Branche, Rolle und Tonfall. Eine E‑Mail vom „CFO“ klingt heute exakt so, wie man es erwartet.
KI wertet öffentlich verfügbare Informationen aus:
So entstehen Nachrichten, die inhaltlich exakt zum Arbeitskontext passen.
Neben Text kommen 2026 zunehmend KI‑generierte Stimmen und Videos zum Einsatz. Gefälschte Anrufe oder Meetings mit vermeintlichen Führungskräften sind keine Ausnahme mehr, sondern Realität.
KI ermöglicht tausende individualisierte Angriffe in kürzester Zeit. Ebenso Varianten‑Tests, um die erfolgreichste Version zu identifizieren.
Technologie allein reicht nicht mehr aus. Wirksamer Schutz entsteht nur durch das Zusammenspiel von Technik, Prozessen und Menschen.
Klassische Spamfilter stoßen an ihre Grenzen. Notwendig sind:
Viele erfolgreiche Angriffe nutzen Zeitdruck und Autorität aus. Deshalb braucht es:
Awareness‑Trainings müssen sich weiterentwickeln. Es geht nicht mehr um Rechtschreibfehler, sondern um:
KI‑gestütztes Phishing ist Teil des täglichen Bedrohungsszenarios geworden. Unternehmen, die weiterhin nur auf klassische Schutzmechanismen setzen, laufen Gefahr, systematisch ausgetrickst zu werden. Die gute Nachricht: Mit der richtigen Kombination aus Technologie, Prozessen und Beratung lässt sich das Risiko deutlich reduzieren.
Wir unterstützen Sie dabei, Ihre Organisation auf diese neue Bedrohungslage auszurichten. Pragmatisch, realistisch und nachhaltig. Prüfen Sie gerne auch wie sie mit Zero Trust ihr Unternehmen besser schützen.
Der klassische Weg, ein Legacy-Upgrade oder kurzweilige Koexistenz unterschiedlicher Exchange-Versionen, ist für größere Organisationen oder langsame Migrationsphasen oft der sinnvollste Weg. Sie nehmen einen neuen Exchange SE-Server in Ihre Organisation auf und migrieren Postfächer dorthin. Das ist Pflicht, wenn Sie noch auf Exchange 2016 sind, aber optional bei 2019.
Das In-Place-Upgrade ist die spannende Neuheit: Sie installieren Exchange SE einfach über Ihre bestehende 2019-CU15-Installation und machen daraus direkt einen SE-Server. Der Vorgang verhält sich wie eine normale CU-Installation. Weitere Einblicke gibt es hier.
Microsoft betitelt das In-Place Upgrade als „Low-Risk“. Früher waren neue Exchange-Versionen echte Monster-Updates.
Neue Anforderungen, Produktkeys und Features wurden eingearbeitet. Für die IT-Admins unter Ihnen hieß das: Side-by-Side-Migration, endlose Tests, Kompatibilitätschecks, Team-Schulungen, Skripte umbauen (oder Mut zur Lücke). Kein Wunder, dass viele früher lieber auf ein CU1 gewartet haben, bevor es produktiv ging.
Microsoft Exchange Server SE ist unter der Haube ein Exchange 2019. Der Code ist 1:1 der gleiche. Microsoft hat nur den Produktnamen und die EULA geändert. Keine neuen Features, keine geänderten Hardware-Anforderungen, keine neuen Keys oder Code-Überarbeitungen.
Das In-Place Upgrade klingt gut, passt aber nicht pauschal zu jeder Umgebung. Die meisten von Ihnen betreiben Exchange 2019 wahrscheinlich noch auf älteren Windows-Servern. In diesem Zusammenhang wäre ein In-Place Upgrade vermutlich die falsche Lösung. Hier wäre das Legacy-Upgrade am sinnvollsten, um dem neuen Exchange SE ein zukunftssicheres Zuhause zu bieten. Mit einem modernen Windows Server 2025 profitieren Sie von Security-Fixes, längerer Supportlaufzeit und Hotpatching.
Das „Sollen“ muss eher durch „Müssen“ ersetzt werden. Microsoft baut die Lizenzierung für die Zukunft um – und die Exchange-On-Premises-Welt leidet mit. Da der Support für Exchange 2019 im Oktober 2025 geendet ist, müssen Sie auf SE upgraden.
Aber die neue SE Version bietet auch interessante Features, wie bspw. ein fortlaufendes Update-Modell, das stärker an Windows Server und Azure Stack angelehnt ist. Statt großer, seltener CUs wird es künftig kleinere, kontinuierliche Updates geben, die weniger Risiko erzeugen und Ihre Wartungsfenster verkürzen. Ihre Organisation profitiert dadurch von einer stabileren Plattform, planbareren Updatezyklen und schneller verfügbaren Security-Fixes.
Microsoft Exchange SE gibt es nun seit einigen Monaten auf dem Markt, Exchange 2016 und 2019 haben seit dem 14. Oktober 2025 ihr Support-Ende erreicht. Microsofts Goodie, die Extended Security Updates (ESU), wurden ins Leben gerufen, um gegen Einwurf von Münzen weiterhin kritische Sicherheitsupdates (SUs) und generellen Support zu gewährleisten.
Doch alles hat ein Ende – der Extended Support läuft am 14. April 2026 aus. Dann sind Exchange Server 2016 und 2019 offiziell „tot“ und werden nicht weiter von Microsoft berücksichtigt. Es ist also Zeit zum Handeln, falls Sie noch alte Exchange Server in Ihrer Organisation betreiben.
Microsoft passt das Koexistenz-Verhalten der Exchange Server an. Früher konnte man noch ältere, sogar nicht mehr unterstützte Versionen neben neueren Versionen koexistieren lassen. Diese Flexibilität endet nun in zwei Schlüsselpunkten.
Die Installation von Exchange Server 2019 CU15 oder Exchange Server SE RTM verweigert die Koexistenz mit Exchange Server 2013. Ein Zwischenschritt auf 2019 Cu14 im klassischen Legacy Upgrade Pfad ist von Nöten. Anschließend muss nach der Postfachmigration der alte 2013 Server entfernt werden, bevor mittels In-Place Upgrade auf Exchange SE RTM aktualisiert werden darf.
Migrationspfad EX 2013
Möchten Sie von einem Exchange Server 2016 CU23 zum Exchange SE RTM migrieren, ist der Zwischenschritt auf 2019 CU15 relevant. Anschließend ist eine langsame Migrationsphase inklusive Koexistenz mit einem neu hinzugefügten Exchange Server SE RTM möglich. Die Option direkt vom Exchange 2019 CU15 via In-Place Upgrade zum Exchange SE ist ebenfalls möglich.
Sollte später bereits das CU1 für Exchange SE vorhanden sein, ist eine Koexistenz mit Exchange 2019 Cu15 technisch noch machbar, aber offiziell nicht supported. Wenn gegen Ende 2026 Exchange SE CU2 veröffentlich wird, ist erneut keine Koexistenz mit Exchange 2019 CU15 möglich. Hier müssen Sie vor dem CU2 Update den letzten Exchange 2019 CU15 aus der Organisation entfernen.
Migrationspfad EX 2016
Einfacher sieht es für den Schritt vom Exchange Server 2019 CU15 zum Exchange Server SE RTM aus. Die Optionen zum In-Place Upgrade oder Koexistenz mit einem neu hinzugefügten Exchange Server SE RTM sind möglich. Ebenfalls unterstützen die in Zukunft erscheinenden Exchange SE CU1 und CU2 Versionen keine weiteren Koexistenz-Szenarien mit Exchange 2019 Cu15.
Migrationspfad EX 2019
Sicherheit in der Cloud ist keine Zusatzfunktion, die sich nachträglich einbauen lässt. Sie muss von Beginn an Teil der Architektur sein. Diesen Grundsatz verfolgt der Cloud Security by Design Ansatz. Sicherheitsmechanismen werden bereits in der Planungsphase berücksichtigt und in jede Schicht der Infrastruktur integriert. So schützen Unternehmen ihre Cloud-Infrastruktur zuverlässig vor bekannten Bedrohungen und schaffen die Grundlage für künftige Anforderungen. Wir erklären in diesem Artikel die Hintergründe des Security by Design Ansatzes, gehen auf Umsetzungsmöglichkeiten ein und geben Tipps für den sicheren Aufbau der Cloud-Infrastruktur.
Cloud Security by Design steht für den Grundsatz, Sicherheit von Beginn an als zentralen Bestandteil der Cloud-Architektur zu verstehen, statt das Thema wie ein Add-on zu behandeln. Statt Sicherheitsmaßnahmen reaktiv nach Vorfällen einzuführen, werden Schutzmechanismen von Anfang an in Design-Entscheidungen eingebettet. Konkret können das verschiedene Mechanismen sein:
Ziel ist es, Schwachstellen zu minimieren, die Reaktionszeiten bei Angriffen zu verkürzen und sicherzustellen, dass Compliance-Anforderungen automatisch erfüllt werden. Wichtig ist auch, dass Entwicklungsteams, Platform Engineers und Sicherheitsexperten eng zusammenarbeiten, um gemeinsam eine sichere und resiliente Cloud-Umgebung zu schaffen.
Für eine erfolgreiche Umsetzung von Cloud Security by Design braucht es eine Kombination aus technischen Maßnahmen, organisatorischen Prozessen und kulturellem Wandel. Unternehmen können in der Entwicklung ihrer Cloud-Infrastruktur verschiedene Maßnahmen implementieren.
Zero-Trust-Ansatz
Das Prinzip „Never trust, always verify“ gilt als Fundament moderner Cloud-Sicherheit. Anders als traditionelle Netzwerkmodelle, die innerhalb des eigenen Netzwerks Vertrauen voraussetzen, behandelt Zero Trust jede Anfrage, unabhängig von ihrer Herkunft, als potenziell gefährlich. Jeder Zugriff wird einzeln validiert, Nutzer und Geräte werden kontinuierlich überprüft und Zugriffsrechte werden auf das absolute Minimum beschränkt. Dieser Ansatz verhindert laterale Bewegungen von Angreifern innerhalb der Infrastruktur und minimiert so den Schaden im Falle einer Kompromittierung.
Identity & Access Management (IAM)
Die richtige Verwaltung von Identitäten und Zugriffsrechten ist unumgänglich für den Aufbau einer sicheren Cloud-Umgebung. IAM-Systeme stellen sicher, dass nur autorisierte Personen und Services auf bestimmte Ressourcen zugreifen können. Durch rollenbasierte Zugriffskontrollen erhalten Nutzer genau die Berechtigungen, die sie für ihre Aufgaben benötigen. Multi-Faktor-Authentifizierung fügt eine zusätzliche Sicherheitsebene hinzu, zudem reduzieren zeitlich begrenzte Zugriffstoken das Risiko kompromittierter Zugänge.
Automatisierte Sicherheitsprüfungen
Manuelle Sicherheitsüberprüfungen sind fehleranfällig und können mit der Geschwindigkeit moderner Cloud-Deployments kaum Schritt halten. Automatisierte Sicherheitstests sollten daher fester Bestandteil jeder CI/CD-Pipeline sein. Tools scannen Code auf Schwachstellen, überprüfen Konfigurationen auf Fehleinstellungen und identifizieren unsichere Abhängigkeiten noch vor dem Deployment. Regelmäßige Penetrationstests und Schwachstellenscans ergänzen diese kontinuierlichen Prüfungen und stellen sicher, dass auch produktive Systeme laufend auf Sicherheitslücken untersucht werden.
Compliance-Anforderungen
Regulatorische Vorgaben wie die DSGVO oder ISO 27001 setzen klare Standards für den Umgang mit Daten und Sicherheitsprozessen. Cloud Security by Design berücksichtigt diese Anforderungen bereits in der Architekturphase, sodass Compliance nicht nachträglich zum Problem wird. Dazu gehören Mechanismen zur Datenverschlüsselung, Protokollierung von Zugriffen, Löschkonzepte und Dokumentation von Sicherheitsmaßnahmen. Durch die Integration dieser Anforderungen von Beginn an vermeiden Unternehmen teure Nachbesserungen und potenzielle Strafen.
CSPM (Cloud Security Posture Management)
CSPM-Tools überwachen die Cloud-Umgebung kontinuierlich auf Fehlkonfigurationen, Compliance-Verstöße und Sicherheitsrisiken. Sie erkennen beispielsweise öffentlich zugängliche Speicher-Buckets, übermäßig permissive Firewalls oder veraltete Verschlüsselungsstandards. Durch automatisierte Warnungen und Empfehlungen helfen CSPM-Lösungen IT-Teams dabei, den Sicherheitsstatus der Cloud-Infrastruktur hoch zu halten und Schwachstellen zu schließen, bevor sie ausgenutzt werden können.
Neben den grundlegenden Sicherheitskonzepten gibt es noch einige konkrete Maßnahmen, die IT-Teams im Aufbau ihrer Cloud-Infrastruktur umsetzen können, um ihre Umgebung abzusichern.
Arbeiten Unternehmen im Aufbau ihrer Cloud-Infrastruktur nach dem Security by Design Ansatz, folgen sie damit einer heute notwendigen Grundhaltung. Indem sie Sicherheit von Anfang an in Planung und Umsetzung integrieren, minimieren sie Risiken, erfüllen Compliance-Anforderungen und sparen langfristig Kosten. Eine Kombination aus automatisierten Sicherheitsprüfungen, IAM und kontinuierlichem Monitoring legt ein sicheres Fundament. Wichtig ist, dass Unternehmen Sicherheit zum zentralen Bestandteil jeder Cloud-Lösung machen, statt sie als nachträglichen Gedanken zu vernachlässigen.
„Wir müssen in die Cloud, und zwar sofort.“ Dieser Satz fällt mittlerweile in vielen Unternehmen. Darauf folgt jedoch häufig Verunsicherung. Was geschieht mit den bestehenden Systemen? Wie gehen wir mit sensiblen Daten um? Muss wirklich alles in die Cloud? Ein radikaler Umzug ist meist weder nötig noch wirklich ratsam. Beim Weg in die Cloud geht es vielmehr um eine strukturierte Transformation statt um die rein technische Umsetzung. Umso wichtiger ist es also, diesen Weg detailliert zu planen und Schritt für Schritt zu gehen. Welche Möglichkeiten es für einen schrittweisen Einstieg in die Cloud gibt, welche Workloads in die Cloud gehören und welche auch On Premises bleiben können, zeigen wir in diesem Artikel.
Ist die Entscheidung für die Cloud gefallen, stehen Unternehmen vor der Frage, ob die bestehende IT-Infrastruktur komplett in die Cloud verlagert werden soll oder ob On-Premises Systeme bestehen bleiben können. Hybride Lösungen sind hier oft ein sinnvoller Weg, um erste Schritte zu gehen, ohne komplizierte Neuentwicklungen anstoßen zu müssen. Bei dieser Variante arbeiten lokale Server und Cloud-Dienste parallel und ergänzen sich gegenseitig.
In der IT-Infrastruktur bedeutet das konkret: Kritische Anwendungen und Daten bleiben On Premises unter direkter Kontrolle. Gleichzeitig werden flexible Cloud-Ressourcen dort eingesetzt, wo sie das Unternehmen wirklich voranbringen, etwa bei der Skalierung von Rechenleistung in Spitzenlastzeiten oder bei der unkomplizierten und ortsunabhängigen Zusammenarbeit im Team. Übliche Bedenken rund um Datensicherheit und Kontrollverlust können so gezielt thematisiert werden, weil die Hoheit über sensible Systeme lokal erhalten bleibt.
Nicht jede Anwendung ist gleichermaßen sinnvoll für den Betrieb in der Cloud. Wichtig ist deshalb, zuerst zu bewerten, ob die Auslagerung in die Cloud sinnvoll ist. Es geht weniger darum, ob ein Umzug in die Cloud grundsätzlich möglich ist – technisch lassen sich die meisten Workloads abbilden, sinnvoll ist das aber nicht immer. Grundsätzlich sind gerade für den Einstieg verschiedene Workloads gut für die Cloud geeignet:
Auf der anderen Seite gibt es einige Bereiche, in denen ein lokaler Betrieb nach wie vor die bessere Wahl sein kann. Dazu zählen vor allem Anwendungen mit hohen Compliance-Anforderungen, etwa in der Medizin, im Finanzwesen oder in Behörden. Hier gelten strenge gesetzliche Vorgaben für Datenhaltung und -zugriff. Auch Systeme mit extrem niedrigen Latenzanforderungen wie zum Beispiel Steuerungssoftware in der Produktion sind häufig besser On Premises aufgehoben. Gleiches gilt für sehr große Datenmengen, bei denen die Übertragungskosten und -zeiten in die Cloud wirtschaftlich keinen Sinn ergeben.
Wichtig ist, dass es keine universelle Antwort gibt. Welcher Weg für ein Unternehmen passend ist, hängt von der Branche, der bestehenden Infrastruktur und den regulatorischen Rahmenbedingungen ab. Eine fundierte Bestandsaufnahme ist deshalb der erste sinnvolle Schritt.
Haben Unternehmen noch keine Erfahrungen mit der Cloud, lohnt sich ein Einstieg mit möglichst geringem Risiko, aber dennoch hohem Nutzen – ein Quick Win. Gut geeignet dafür ist Backup und Disaster Recovery. Die Logik dahinter ist einfach: Backups sind ohnehin grundsätzlich von den produktiven Systemen getrennt, sodass ein ideales Testfeld für die Cloud entsteht, ohne dass kritische Abläufe davon betroffen sind. Gleichzeitig löst der Umstieg auf Cloud-Backups ein häufiges Problem: Lokale Backups sind anfällig für dieselben physischen Risiken wie die Primärsysteme, etwa Feuer, Wasserschäden oder Hardwareausfälle. Ein Cloud-Backup liegt geografisch getrennt und ist im Ernstfall unabhängig verfügbar. Für Unternehmen entstehen also mehrere Vorteile:
Grundsätzlich gilt der Umstieg auf Cloud-Backups als guter Einstieg in die Cloud, der das Vertrauen in die Technologie im Unternehmen stärkt. So kann die Basis für weitere Migrationsprojekte entstehen, die auf Zustimmung im Unternehmen trifft.
Die Cloud bietet Unternehmen große Chancen – der Einstieg sollte aber unbedingt durchdacht sein. Ein schrittweiser Einstieg sorgt für mehr Klarheit und Sicherheit, vermeidet Risiken und ist weitsichtig. Durch hybride Modelle schaffen Unternehmen Flexibilität, ohne aber bewährte Strukturen zu opfern. Wichtig ist eine klare Unterscheidung zwischen Workloads, die in die Cloud gehören und solchen, die weiterhin On Premises betrieben werden können. So vermeiden Unternehmen unnötige Kosten und Komplexität und profitieren gleichzeitig von Cloud-Vorteilen.
Eine starke Unternehmenskultur entsteht nicht über Nacht. Vielmehr wächst sie mit gelebten Werten und Wertschätzung sowie durch ein Arbeitsumfeld, in dem Menschen sich gesehen und gehört fühlen. Umso mehr freut es uns, dass Rewion auch im Jahr 2026 erneut mit dem kununu Top Company-Siegel ausgezeichnet wurde. Nach der Auszeichnung im Jahr 2025 zählt Rewion damit ein weiteres Mal zu den attraktivsten Arbeitgebern Deutschlands. Wer sagt das? Die wichtigsten Stimmen: unsere Mitarbeitenden selbst. Diese Auszeichnung zeigt uns, dass unser Anspruch an ein modernes, vertrauensvolles und gemeinschaftliches Arbeitsumfeld wirklich gelebt wird.
Der kununu Top Company-Award wird jährlich auf Basis unabhängiger Bewertungen von aktuellen und ehemaligen Mitarbeitenden vergeben. Anders als viele andere Arbeitgebersiegel ist er damit nicht käuflich und basiert nicht auf Informationen von Unternehmen selbst. Für uns heißt das: Er ist besonders glaubwürdig.
Jährlich erhalten nur rund fünf Prozent aller auf kununu gelisteten Unternehmen diese Auszeichnung. Voraussetzung dafür ist eine überdurchschnittlich hohe Zufriedenheit der Mitarbeitenden sowie kontinuierlich positives Feedback. Dass Rewion diese Kriterien 2026 erneut erfüllt, ist für uns ein starkes Zeichen und vor allem ein großes Kompliment an unser gesamtes Team.
kununu CEO Nina Zimmermann fasst die Bedeutung des Awards perfekt zusammen:
„Ein starkes Zeichen an Talente, die nach ihrem idealen Arbeitgeber suchen.“ Genau dieses Signal möchten wir senden. Rewion schafft einen Arbeitsplatz, an dem Menschen gerne arbeiten, sich entwickeln können und gemeinsam erfolgreich sind.
Die kununu-Auszeichnung zeigt uns, dass wir als Arbeitgeber den richtigen Weg gehen. Ein wertschätzender Umgang, Vertrauen in unsere Mitarbeitenden und ein starkes Gemeinschaftsgefühl machen unseren Arbeitsalltag aus. Wir sind der Meinung, dass gute Arbeit dort entsteht, wo Menschen sich wohlfühlen, Verantwortung übernehmen dürfen und ihre Ideen einbringen können. Grundsätzlich finden aber auch feste Standorte langweilig und haben deshalb drei Standorte in Stuttgart, Köln und Zürich aufgebaut. Genauso gerne arbeitet unser Team aber auch beim Kunden oder im eigenen Wohnzimmer.
Zusammengefasst gibt es mehrere Punkte, die unser Arbeitsverständnis ausmachen:
Dass unsere Mitarbeitenden dieses Modell so positiv bewerten, macht uns stolz und motiviert uns zeitgleich, diesen Weg auch in Zukunft weiterzugehen.
Die kununu Top Company-Auszeichnung 2026 ist für uns auch ein Ansporn. Wir möchten gemeinsam mit Menschen weiter wachsen, die unsere Werte teilen und Lust haben, die IT-Welt aktiv mitzugestalten. Du suchst einen Arbeitgeber, bei dem Unternehmenskultur mehr ist als ein Versprechen? Dann lerne uns bei Rewion kennen. Schau dich in unseren offenen Stellen um und werde Teil eines Teams, das zu den besten Arbeitsumfeldern Deutschlands zählt.
Willkommen bei unserem exklusiven Support für Bestandskunden. Hier finden Sie alle nötigen Informationen, um schnell und unkompliziert Hilfe bei technischen Anfragen zu erhalten.
Für eine direkte Unterstützung per Fernwartung, laden Sie bitte unser TeamViewer-Modul herunter:
Bitte beachten Sie: Dieser Kanal ist speziell für technische Anfragen unserer Bestandskunden vorgesehen. Für allgemeine Anfragen, Informationen zu unseren Dienstleistungen oder eine Erstberatung nutzen Sie bitte unser Kontaktformular oder schreiben Sie eine E-Mail an [email protected].
