Dataverse for Teams vs SharePoint-Listen: So migrierst du

Microsoft stellt Dataverse for Teams ein. Ab dem 15. November 2026 können keine neuen Dataverse-for-Teams-Umgebungen mehr erstellt werden – nicht einmal für die erste App oder den ersten Agenten eines Teams. Umgebungen, die nicht aktualisiert werden, werden am 15. September 2027 gesperrt und am 30. October 2027 gelöscht. Wenn du den vollständigen Zeitplan und die Kosten für das Upgrade wissen möchtest, lies dir als Erstes unseren Leitfaden zur Einstellung durch.

‍

In diesem Artikel geht es um die Alternative, die sich viele Admins im Moment ansehen: Dataverse for Teams vs SharePoint-Listen und wie du Teams-Apps in SharePoint-Listen verschiebst. Du bezahlst SharePoint bereits als Teil von Microsoft 365, deine Daten bleiben in deinem Tenant und du vermeidest eine Premium-Lizenz für alle Nutzer:innen.

‍

Unten findest du einen ehrlichen Vergleich zwischen Dataverse for Teams und SharePoint-Listen, einen Migrationsprozess in 5 Schritten sowie eine Übersicht, mit welchen Tools du deine Apps neu erstellen kannst.

‍

{{Ad-1}}

‍

Warum SharePoint-Listen das natürliche neue Zuhause für Dataverse-for-Teams-Apps sind

Bereits lizenziert und im Einsatz

SharePoint ist in jeder Microsoft-365-Business-Lizenz enthalten. Deine Nutzer:innen kennen es, deine Admins verwalten es und deine Compliance- sowie Backup-Richtlinien decken es bereits ab. Das Verschieben von Daten aus Dataverse for Teams in SharePoint-Listen fügt kein neues System hinzu.

‍

Keine Lizenz pro Nutzer:in für die Daten

Ein Upgrade einer Dataverse-for-Teams-Umgebung bedeutet, dass alle Nutzer:innen eine Power-Apps-, Power-Automate- oder Copilot-Studio-Lizenz benötigen. Daten in SharePoint-Listen erfordern das nicht. Dieser Unterschied ist der Hauptgrund, warum SharePoint für einfache, weit verbreitete Apps in der engeren Auswahl steht.

‍

Für die Ewigkeit gebaut

Listen und Bibliotheken sind seit über zwanzig Jahren der Kern von SharePoint. Microsoft hat viele Tools rundherum ersetzt – von InfoPath bis hin zu SharePoint-Designer-Workflows –, aber die Listen selbst sind geblieben. Für Daten, die du jahrelang behalten möchtest, spielt das eine Rolle. Wenn du dir nicht sicher bist, ob Listen deine Daten tragen können, zeigt unser Leitfaden zur Nutzung von SharePoint als Datenbank, was funktioniert und wo die Grenzen liegen.

‍

Dataverse for Teams vs SharePoint-Listen: ein ehrlicher Vergleich

SharePoint-Listen sind kein 1:1-Ersatz für Dataverse. Für die meisten Teams-Apps sind sie mehr als genug, aber du solltest die Unterschiede kennen.

‍

‍

Wo SharePoint-Listen etwas Pflege brauchen

• Ansichten mit über 5.000 Elementen: SharePoint hat einen Grenzwert für Listenansichten. Indexiere die Spalten, nach denen du filterst und sortierst, dann bleiben grosse Listen schnell.
• Komplexe Datenmodelle: Many-to-Many-Beziehungen und tiefere Hierarchien lassen sich mit Nachschlagespalten schwerer modellieren. Plane deine Listen, bevor du migrierst.
• Hohes Transaktionsvolumen: Apps mit Tausenden von Änderungen pro Minute gehören in eine echte Datenbank und nicht in eine Liste. Teams-Apps funktionieren nur selten so.

‍

Wenn eine App an eines dieser Limits stößt, kann es die richtige Entscheidung sein, genau diese App auf Dataverse hochzustufen. Für den Rest funktionieren Listen gut. Bevor du migrierst, hilft es zu planen, wie deine Listen miteinander verknüpft sind. Unser Leitfaden zu SharePoint-Listen als Datenbank zeigt dir, wie du diese Beziehungen modellierst.

‍

So migrierst du von Dataverse for Teams zu SharePoint-Listen

Schritt 1: Exportiere deine Daten

Beginne mit den Daten, nicht mit der App. Exportiere für jede Tabelle in der Dataverse-for-Teams-Umgebung die Zeilen, zum Beispiel nach Excel oder CSV, oder nutze einen Power-Automate-Flow, der die Tabelle ausliest und Elemente in der neuen Liste erstellt. Behalte den Export auch nach der Migration als Fallback.

‍

Überprüfe Anhänge und Bilder separat. Oft sind sie anders gespeichert und werden am ehesten vergessen.

‍

Schritt 2: Baue das Datenmodell als Listen neu auf

Erstelle eine SharePoint-Liste pro Tabelle. Ordne jede Spalte dem passendsten SharePoint-Spaltentyp zu: Text, Zahl, Datum, Auswahl, Person, Ja/Nein. Ersetze Beziehungen durch Nachschlagespalten und füge Indizes für die Spalten hinzu, nach denen du filtern wirst.

‍

‍

Das ist auch ein guter Moment, um aufzuräumen. Spalten, die niemand ausfüllt, und Tabellen, die niemand nutzt, müssen nicht umziehen.

‍

Schritt 3: Baue Formulare und Logik neu auf

Als Nächstes kommt die Benutzeroberfläche: die Formulare, die Menschen ausfüllen, die Ansichten, mit denen sie arbeiten, und die Regeln dahinter. Welche Felder sind Pflichtfelder, welche sind nur in bestimmten Fällen sichtbar, welche Werte werden berechnet?

‍

Schreibe dir diese Regeln auf, bevor du sie neu erstellst. In Teams-Apps sind sie oft in Formeln versteckt, die niemand dokumentiert hat.

‍

‍

Schritt 4: Genehmigungen und Benachrichtigungen neu aufbauen

Die meisten Teams-Apps sind mit einem Prozess verknüpft: Eine Führungskraft genehmigt eine Anfrage, die anfragende Person erhält eine E-Mail, ein Team wird bei Änderungen benachrichtigt. Liste jeden Flow auf, was ihn auslöst und wer daran beteiligt ist, und baue ihn dann auf den neuen Listen nach.

‍

‍

Schritt 5: Testen, ausrollen und die alte App abschalten

Lass ein paar echte Nutzer:innen die neue App mit realen Fällen testen. Migriere dann die restlichen Daten, verknüpfe den Teams-Tab mit der neuen App und schalte die alte ab. Warte nicht darauf, dass Microsoft das im September 2027 für dich übernimmt.

‍

‍

Wir migrieren seit Jahren InfoPath- und Nintex-Lösungen zu SharePoint. Auf Wunsch schauen wir uns deinen Migrationsplan vor dem Start an und weisen dich auf Dinge hin, die man leicht übersehen kann.

‍

Hol dir eine zweite Meinung →

‍

Ein konkretes Beispiel: Die App zur Problemmeldung

Um die Schritte greifbar zu machen, nehmen wir eine typische Teams-App: eine App zur Problemmeldung basierend auf einer Microsoft-Vorlage. Mitarbeiter melden eine defekte Maschine oder ein Sicherheitsproblem, ein Teamleiter weist es zu, und der Melder wird benachrichtigt, wenn es behoben ist. Rund 200 Leute nutzen sie.

‍

Das Datenmodell

In Dataverse for Teams verwendet die App drei Tabellen: Probleme, Kategorien und Standorte. In SharePoint werden daraus drei Listen. Die Problemliste erhält Nachschlagefelder (Lookup-Spalten) für Kategorien und Standorte, eine Personenspalte für den Bearbeiter und eine Auswahlliste für den Status (neu, in Bearbeitung, gelöst). Fotos wandern in eine Bilderspalte oder eine verknüpfte Dokumentenbibliothek.

‍

Das Formular und der Prozess

Das Formular benötigt dieselben Regeln wie zuvor: Kategorie und Standort sind Pflichtfelder, das Bearbeiterfeld ist nur für Teamleitungen sichtbar, und der Status kann erst dann auf „gelöst“ gesetzt werden, wenn ein Lösungskommentar vorhanden ist. Der Prozess bleibt überschaubar: eine Benachrichtigung an die Teamleitung, wenn ein neues Problem eingeht, und eine an die meldende Person, wenn es gelöst ist.

‍

‍

Der Kostenunterschied

Auf Dataverse hochgestuft, benötigt diese App für alle ihre 200 Nutzer:innen eine Lizenz. Zum Listenpreis von Power Apps Premium sind das rund 4.000 US-Dollar im Monat und ab Januar 2027 dann 4.400 US-Dollar, wenn Microsoft den Preis auf 22 US-Dollar pro Nutzer:in anhebt. Bei SharePoint-Listen kostet die Datenbasis selbst keinen Cent extra. Du bezahlst für das Tool, mit dem du neu baust. Mit skybow ist das genau eine skybow-Lizenz pro Nutzer:in für Formulare, Workflows und Automatisierung. In unserem veröffentlichten Beispiel mit 500 Nutzer:innen kostet skybow rund 1.500 US-Dollar im Monat, verglichen mit 6.000 US-Dollar oder mehr bei Power Apps.

‍

Häufige Migrationsfehler und wie du sie vermeidest

1. Zuerst die App bauen statt an die Daten denken

Eine neu gebaute App bringt dir nichts, wenn die Hälfte der Daten auf der Strecke geblieben ist. Migriere und prüfe zuerst die Daten, bevor du darauf aufbaust.

‍

2. Alles eins zu eins migrieren

Teams-Apps sind oft über die Zeit gewachsen. Felder, die niemand ausfüllt, Status, die niemand nutzt, und Masken, die niemand öffnet, können getrost zurückbleiben. Eine Migration ist der ideale und günstigste Zeitpunkt, um aufzuräumen.

‍

3. Die versteckte Logik vergessen

Validierungsregeln, Standardwerte und berechnete Felder stecken oft in Formeln, die für Nutzer:innen unsichtbar sind. Gehe die alte App Bildschirm für Bildschirm durch und schreibe jede Regel auf, bevor du sie abschaltest.

‍

4. Berechtigungen ignorieren

In Dataverse for Teams war der Zugriff an die Teammitgliedschaft geknüpft. In SharePoint bestimmst du das selbst. Richte die Berechtigungen für die neuen Listen bewusst ein – besonders dann, wenn bestimmte Elemente nur für ausgewählte Personen sichtbar sein sollen.

‍

5. Alles bis zum Sommer 2027 aufschieben

Alle Organisationen, die abwarten, werden zur gleichen Zeit nach derselben Hilfe suchen. Plane die Migration spätestens in der ersten Jahreshälfte 2027, dann kannst du Partner und Tempo selbst wählen.

‍

Mit welchem Tool solltest du neu bauen?

Sobald die Daten in SharePoint-Listen liegen, brauchst du etwas, um Formulare und Prozesse darauf aufzubauen. Dafür gibt es im Wesentlichen zwei Wege.

‍

Power Apps und Power Automate mit Standard-Connectors

Canvas-Apps und Flows, die ausschliesslich Standard-Connectors wie SharePoint verwenden, laufen mit den in Microsoft 365 enthaltenen Rechten für Power Apps und Power Automate. Wenn dein Team bereits mit Power Apps vertraut ist, liegt das nahe.

‍

Behalte zwei Dinge im Hinterkopf: Der Neuaufbau bedeutet, dass du Power-Fx-Formeln und Flows komplett neu schreiben musst, was Zeit und Know-how erfordert. Und sobald auch nur eine App einen Premium-Connector benötigt, braucht jeder Nutzer dieser App eine Premium-Lizenz. Wenn du auch andere Tools in Betracht ziehst, findest du in unserer Übersicht der Power Apps-Alternativen einen direkten Vergleich der wichtigsten Optionen.

‍

Eine SharePoint-native Plattform wie skybow Studio

skybow Studio baut Formulare, Workflows und Business-Logik direkt auf SharePoint-Listen und -Bibliotheken auf – ganz ohne Code. Genehmigungen, Benachrichtigungen und die Generierung von Dokumenten sind Teil desselben Tools, sodass es kein zweites Produkt gibt, das lizenziert oder gepflegt werden muss.

‍

Dieser Weg eignet sich ideal für Organisationen, bei denen Fachanwender:innen ihre Apps selbst erstellen und anpassen sollen, während die IT die Kontrolle über die Plattform behält. Typische skybow-Lösungen gehen nach 2 Tagen bis 5 Wochen live. Du bezahlst eine skybow-Lizenz pro Nutzer:in; in unserem Beispiel mit 500 Nutzer:innen sind das etwa 1.500 US-Dollar pro Monat. Der Vergleich skybow vs Power Apps stellt Funktionen und Kosten direkt gegenüber.

‍

Wichtigste Erkenntnisse

• SharePoint-Listen sind bereits lizenziert, bereits im Einsatz und ein stabiles Zuhause für die meisten Daten aus Teams-Apps.
• SharePoint-Listen sind kein vollständiger Dataverse-Ersatz: Plane den Grenzwert von 5.000 Elementen in Listenansichten und komplexe Beziehungen entsprechend ein.
• In fünf Schritten migrieren: exportieren, Datenmodell neu aufbauen, Formulare neu erstellen, Prozesse neu anlegen, testen und abschalten.
• Vermeide die klassischen Fehler: Zuerst die Daten, unterwegs entrümpeln, versteckte Regeln dokumentieren, Berechtigungen bewusst vergeben.

‍

Die Frist steht fest, aber die Arbeit ist absolut machbar, wenn du frühzeitig beginnst und App für App vorgehst. Starte mit den Apps, die täglich genutzt werden, und lege die still, die niemand vermissen würde.

‍

Möchtest du Hilfe beim Verschieben deiner Teams-Apps? Wir unterstützen dich vom Datenexport bis zur fertigen Lösung in SharePoint, und das erste Gespräch ist kostenlos.

‍

Kostenloses Erstgespräch buchen →