Themen-Page · Architektur · Strategie
Eine Idee, die viele in der IT-Diskussion gut finden, aber wenige bauen: alle Geschäftsanwendungen auf einer einzigen Datenbasis — ohne Schnittstellen-Wartung, ohne doppelte Daten, ohne die „wir kommen schon irgendwie ran"-Excel-Inseln. Microsoft Dataverse macht das im Mittelstand inzwischen tragfähig. Diese Themen-Page erklärt, warum — und unter welchen Bedingungen es funktioniert.
Problemstellung
In jedem zweiten Mittelstands-Projekt, das wir übernehmen, finden wir denselben Befund: das Unternehmen hat im Lauf der Jahre 8 bis 25 Geschäftsanwendungen angesammelt. CRM hier, ERP dort, Marketing-Tool separat, Ticket-System eigene Datenbank, HR auf einer weiteren Plattform, Field-Service-App mit eigenem Mobile-Backend, ein paar Power Apps und Excel-Tools für Self-Service-Themen. Jede Anwendung hat ihren eigenen Sinn — und jede Anwendung hat ihre eigene Datenbank.
Das funktioniert so lange, wie die Anwendungen nichts voneinander wissen müssen. Das ist im Mittelstand selten der Fall. Sobald eine vertriebliche Person im CRM die Lieferadresse aus dem ERP sehen will, ein Service-Techniker oder eine Service-Technikerin das Geräte-Verzeichnis aus dem ERP im Field-Service-Tool braucht, oder die Marketing-Automation den Lead-Status aus dem CRM kennen muss, beginnt die Schnittstellen-Arbeit.
Drei Realitäten von Schnittstellen, die niemand vor Vertragsabschluss zugibt:
Die Insel-Variante davon — „wir verzichten halt auf die Schnittstelle" — ist nicht besser. Sie produziert manuelle Excel-Brücken, doppelte Dateneingabe, asynchrone Wahrheiten und Compliance-Risiken. Ein Stammdaten-Satz, der in drei Systemen leicht unterschiedlich gepflegt ist, ist nicht nur unsauber — er ist DSGVO-relevant und auditierbar.
Die Idee in einem Absatz
Die Idee ist nicht neu. Mainframe-Architekten haben in den 70er-Jahren genau so gedacht. SAP hat es in den 90er-Jahren als Konzern-Lösung kommerziell verwirklicht. Was neu ist: Es funktioniert mittlerweile auch im Mittelstand, mit moderner Web-Architektur, ohne dass dafür ein 12-monatiges SAP-S/4-Projekt nötig wäre. Der Stack heißt Microsoft Dataverse.
Dataverse ist die Geschäftsdaten-Plattform unter Microsoft Power Platform und Microsoft Dynamics 365. Sie ist nicht einfach eine SQL-Datenbank in der Cloud. Sie ist ein Business-Datenmodell mit eingebauten Berechtigungen, Audit-Trail, Validierungsregeln, Workflow-Triggern, Multi-Language-Metadaten und einer einheitlichen REST-API. Power Apps, Power Automate, Dynamics 365 Sales, Customer Service, Field Service, Project Operations, Copilot Studio, Teams-Integrationen und SharePoint-Verknüpfungen arbeiten auf demselben semantischen Modell.
Das hat eine Konsequenz, die viele Architekten erst nach dem ersten produktiven Einsatz wirklich begreifen: Eine neue Geschäftsanwendung zu bauen, ist nicht mehr "Daten-Schema designen, dann Frontend bauen, dann mit den anderen Systemen integrieren". Es ist "Dataverse-Tabellen anlegen oder bestehende erweitern, dann Frontend bauen". Die Integration ist schon da, weil alle anderen Apps schon auf derselben Datenbasis lesen und schreiben.
Wie es konkret aussieht
Die Theorie klingt schön — die Frage ist, was das in der Praxis bedeutet. Vier Pattern aus unseren Mandaten der letzten Jahre:
Klassischer Anwendungsfall: Dynamics 365 Sales und Dynamics 365 Customer Service arbeiten auf demselben Account- und Contact-Stamm. Wenn der Vertriebsmitarbeiter einen Account anlegt, sieht der Service-Mitarbeiter ihn sofort. Wenn der Service einen Ticket-Verlauf dokumentiert, sieht der Vertrieb beim nächsten Anruf, wo der Schuh gerade drückt. Keine Schnittstelle. Beide Apps lesen denselben Account.
Statt das Marketing-Team eine Excel-Liste pflegen zu lassen, in der Kampagnen-Status und CRM-Lead-Zuordnung manuell synchronisiert werden, baut man eine Power App. Sie nutzt direkt die CRM-Lead-Tabelle in Dataverse, schreibt nur eine Custom-Spalte für "Kampagne". Eine App, eine Datenbasis, kein Schnittstellen-Aufwand — und der CRM-Vertriebsmitarbeiter sieht die Kampagnen-Zuordnung direkt.
Dynamics 365 Field Service nutzt dieselbe Account- und Asset-Datenbank wie das CRM und Service. Der Mobile-Techniker sieht beim Anfahren die offenen Tickets aus Customer Service, die Wartungs-Historie und die letzten Vertriebs-Aktivitäten. Eine Mobile-App, dieselbe Datenbasis — keine Mobile-Synchronisation, keine "letzter Stand"-Probleme im Offline-Modus.
Selbst Custom-Software (etwa ein Kunden-Portal oder eine Branchen-spezifische Web-App) kann Dataverse als Backend nutzen. Über die offizielle Dataverse-Web-API oder Power Pages kommen Eigenentwicklungen an dieselbe Datenbasis. Auch Eigenbau-Software lebt auf demselben Daten-Stamm — ohne dass ein separates Backend gepflegt werden muss.
Ehrliche Abgrenzung
Wir verkaufen die Single-Database-Architektur nicht als Allheilmittel. Drei Konstellationen, in denen wir aktiv von der vollen Konsolidierung abraten:
In allen anderen Fällen — und das ist der Großteil der Mittelstands-Landschaften, die wir sehen — gewinnt die Single-Database-Architektur deutlich. Wer auf 80 % seiner Geschäftsdaten auf einer gemeinsamen Plattform liegt, hat einen strukturellen Wartungs-Vorteil gegenüber demjenigen, der seine 80 % auf zwölf separaten Datenbanken hält.
Unsere eigenen Apps · Dataverse-nativ
Wir glauben nicht nur an die Single-Database-Architektur — wir haben unsere eigenen Software-Lösungen konsequent darauf gebaut. Jede der folgenden Apps läuft auf Power Platform und Dataverse. Sie können einzeln gekauft und betrieben werden — und sie lesen alle auf demselben Account-, Contact- und Asset-Stamm, wenn Sie sie kombinieren.
Kursverwaltung, Teilnehmer-Tracking, Zertifikats-Generierung — auf demselben Account- und Contact-Stamm wie Ihre anderen CRM-Anwendungen.
Ansehen →
Branchen-App · VerbändeMitgliederverwaltung, Beitragsabrechnung, Veranstaltungs-Management — auf Dataverse, integriert mit Microsoft 365 Outlook und Teams.
Ansehen →
P&SMProjekt-Steuerung mit Service-Ticket-Anbindung — Resource-Capacity, Forecast, Time-Tracking auf gemeinsamer Datenbasis mit Dynamics 365 Sales und Customer Service.
Ansehen →
Modulare ERPKaufmännische Funktionen — Aufträge, Rechnungen, Stammdaten — als modulare Power-Platform-Apps statt monolithisches ERP-System. Für Mittelständler, denen SAP zu groß und Excel zu wenig ist.
Ansehen →
Trading CompaniesMehrere Geschäftseinheiten auf einem Tenant — Belege, Rechnungen, Lagerbestände konsolidiert. Eine Datenbank, mehrere Mandanten — ohne klassische ERP-Multi-Tenant-Komplexität.
Ansehen →
CRM in TeamsDynamics 365 als Teams-Tab — Account-Stamm, Ticket-Verläufe, Vertriebsopportunities direkt in der Microsoft-Teams-Oberfläche. Eine Datenbasis, zwei Frontends.
Ansehen →
licenses.arades.deLizenz-Kalkulation für Power Platform und Dynamics 365 — pro Audience-Gruppe, mit NCE-Preisen und ROI-Hochrechnung. Web-App, die uns selbst zeigt, was die Dataverse-Architektur an Lizenzen tatsächlich kostet.
Ansehen →
Power Platform GovernancePower-Platform-Tenant-Audit, Solution-Catalog-Hygiene, DLP-Policy-Konfiguration. Unverzichtbar, sobald Self-Service Power Apps in größerem Maßstab gebaut werden.
Ansehen →
BeratungSie haben eine bestehende Insel-Landschaft und wollen prüfen, ob der Übergang auf Dataverse sinnvoll ist? Festpreis-Workshop in drei Formaten — Festpreis je nach Tiefe.
Ansehen →
Wie der Übergang läuft
Der größte Fehler beim Übergang aus einer Insel-Landschaft ist der Versuch, alles auf einmal zu migrieren. Realistischer Pfad in drei Wellen über 12 bis 36 Monate:
Welle 1 — Kern-Stamm migrieren (3 bis 6 Monate). Sie wählen eine zentrale Geschäftsdomäne — typisch CRM-Daten (Accounts, Contacts, Opportunities) oder Service-Daten (Tickets, Asset-Stamm). Diese Domäne ziehen Sie nach Dataverse, bauen darauf die erste produktive App (typisch Dynamics 365 Sales oder Customer Service) und etablieren das Daten-Modell als Single Source of Truth. Bestehende Insel-Systeme bekommen Lese-Synchronisationen aus Dataverse.
Welle 2 — Angrenzende Apps konsolidieren (6 bis 12 Monate). Excel-Insel-Tools, einfache Drittsystem-Verträge, kleinere Spezial-Anwendungen werden als Power Apps neu gebaut — direkt auf der Dataverse-Datenbasis aus Welle 1. Die Marketing-Automation greift jetzt direkt auf den Account-Stamm, der Field-Service-Techniker sieht die Service-Historie aus demselben Dataverse-Modell, das Vertrag-Management läuft auf denselben Contact-Daten.
Welle 3 — Spezial-Systeme integrieren oder ablösen (12 bis 24 Monate). Bestehende Spezial-Systeme — ERP, MES, branchen-spezifische Drittlösungen — bleiben entweder mit klar definierter Schnittstelle zum Dataverse-Stamm bestehen (über Dataverse Virtual Tables oder Connectors) oder werden in der Roadmap ersetzt. Hier sind die Entscheidungen typisch fallspezifisch und brauchen Geschäftsführer-Mitarbeit.
Was diesen Pfad funktionieren lässt: klares Commitment der Geschäftsführung ab Welle 1. Wer die Idee nur "in der IT-Abteilung" verfolgt, bleibt nach Welle 1 stecken — und dann ist die neue Dataverse-Instanz nur eine weitere Insel.
Häufige Fragen
Dataverse ist mehr als eine Tabellen-Datenbank. Es ist ein Business-Daten-Modell mit eingebauten Berechtigungen, Audit-Trails, Validierung, Workflow-Triggern, Multi-Language-Metadaten und einer einheitlichen API. Power Apps, Power Automate, Dynamics 365, Copilot Studio und Teams-Integration arbeiten auf demselben semantischen Modell — ohne dass Entwickler für jede neue App eine neue Daten-Schicht designen müssen.
Ja — und das muss man bewusst entscheiden. Wer auf Dataverse setzt, bindet sich an das Microsoft-Ökosystem. Die Frage ist nicht, ob das Lock-in existiert, sondern ob die strategischen Vorteile (gemeinsame Datenbasis, Lizenz-Hebel, AI-Anbindung) den Preis rechtfertigen. Für Mittelstand mit Microsoft-Schwerpunkt typisch ja. Für Häuser mit starkem Open-Source-Drang oder regulatorischer Souveränitäts-Anforderung typisch nein — dann eher hybrid mit klar abgegrenzten Dataverse-Inseln.
Die Lizenzierung läuft über Power-Apps-User-Licenses (ab 8,40 €/User/Monat für Premium Power Apps, höhere Tiers bei Dynamics-365-Lizenzen). Zusätzlich Kapazitäts-Lizenzen für Database (10 GB inkl., Erweiterung ab 36,90 €/GB/Monat). Bei einer realistischen Mittelstands-Kalkulation für 100 User mit moderater Datenmenge liegen Sie bei ca. 1.500 € bis 2.800 €/Monat — Lizenz-Auditing über unseren License Cost Calculator zeigt die genaue Kalkulation pro Audience-Gruppe.
Stand der Preise: Microsoft passt Listenpreise regelmäßig an (Currency-Adjustments, NCE-Aktualisierungen, Plan-Restructurings). Die hier genannten Beträge sind Orientierungs-Werte aus Mai 2026. Aktuelle Preise inkl. arades-CSP-Konditionen abrufen Sie tagesaktuell im License Cost Calculator (licenses.arades.de) ↗.
Drei Szenarien rechtfertigen Insel-Lösungen: erstens hochspezialisierte Domänen-Software (Maschinen-Steuerung, OT-Systeme, branchen-spezifische ERP wie SAP S/4HANA mit eigener Daten-Tiefe). Zweitens regulatorische Trennung (Compliance-getrennte Bereiche, etwa Finanz- vs. Vertriebs-Daten in regulierten Branchen). Drittens organisatorische Trennung (M&A-Übergangsphasen, Joint Ventures mit eigener IT). In allen anderen Fällen — und das ist der Großteil im Mittelstand — gewinnt die Single-Database-Architektur.
Realistisch 12 bis 36 Monate, in Wellen geplant. Erste Welle: Eine zentrale Domäne nach Dataverse migrieren (typisch CRM-Daten oder Service-Tickets, 3-6 Monate). Zweite Welle: Angrenzende Apps konsolidieren — Self-Service Power Apps statt Excel-Insel-Tools (6-12 Monate). Dritte Welle: Bestehende Spezial-Systeme entweder integrieren (Dataverse Virtual Tables, Connectors) oder ablösen. Ein realistischer Pfad braucht ein klares strategisches Commitment der Geschäftsführung — sonst bleibt es bei der ersten Welle und der Rest bleibt im Insel-Zustand.
Verwandte Themen
Power Apps, Power Automate, Power BI, Power Pages — die Frontends auf Dataverse.
Daten-PlattformDie Backbone-Datenbank, auf der alles aufsetzt — Modellierung, Berechtigungen, Performance.
CRM & ERPSales, Customer Service, Field Service, Project Operations, Business Central — alle auf Dataverse.
Architektur-WorkshopFestpreis-Workshop zur Bewertung Ihrer bestehenden Landschaft — gegen die Single-Database-Idee gespiegelt.
MigrationWelche Insel kommt in welcher Reihenfolge? Migrations-Strategien für 7 typische Ausgangslagen.
GovernanceWenn alle Apps auf einer Plattform sind, braucht es Governance. Tenant-Hygiene mit devonso.
45 Min · ergebnisoffen
Bringen Sie Ihre Insel-Landschaft ins Architektur-Gespräch. Wir prüfen ehrlich, ob der Übergang auf Dataverse sinnvoll wäre — oder welche Inseln Sie aus guten Gründen behalten sollten.
