Von Power Apps zu React und Azure Functions: warum Testbarkeit den Ausschlag gab

Der SMI e.V. (Standard Motor Interface) zertifiziert die Antriebe seiner rund 30 Mitgliedsunternehmen nach einem gemeinsamen Standard. Gemeinsam mit der Agentur Vertical Meters betreue ich die Digitalisierung dieses Prozesses seit Jahren. Erst als Power-Platform-Lösung aus Canvas Apps und Flows, seit diesem Sommer als eigene Web-App. Den ganzen Bogen vom Papierprozess bis heute erzählt die Fallstudie zum Projekt. Auf denselben Stammdaten setzt auch der automatisierte Rechnungslauf auf.

Dieser Bericht handelt von der Entscheidung dazwischen: wann eine funktionierende Low-Code-Lösung abgelöst gehört, und woran man das festmacht. Die kurze Antwort vorweg: nicht an der Technik, sondern daran, was eine Änderung kostet.

Was die Canvas-Welt gut konnte, und wo sie aufhörte

Power Apps war zum Startzeitpunkt die richtige Wahl. Die Lösung stand schnell, brauchte kein eigenes Hosting, lebte im vertrauten Microsoft-365-Umfeld und wurde von der Geschäftsstelle mitgetragen. Sie hat rund 100 Personenstunden im Jahr eingespart und die Fehlerquote bei Zertifizierungen um etwa zwei Drittel gesenkt (Angaben: Vertical Meters). Das ist kein Projekt, das man nachträglich zum Fehler erklärt.

Der Bruch kam nicht durch die Technik, sondern durch Wachstum. Aus einem Formular wurden Assistenten mit sieben, neun und fünf Schritten. Aus einer Registrierung wurden Einzel- und Serienregistrierungen, dazu OEM-Fälle mit eigenem Datensatz, Logo und Zusatzdokumenten. Und mit jeder Runde wuchs die Duplikation: Ein rund 300 Zeilen langer Aufrufblock zur Datenblatt-Erzeugung existierte in vier fast identischen Kopien, die Wizard-Mechanik dreimal, acht praktisch gleiche Upload-Flows nebeneinander.

Duplikation ist in jeder Codebasis unangenehm. In der Canvas-Welt ist sie teurer, weil es die üblichen Gegenmittel nicht gibt. Es gibt keine lokale Ausführung, keinen Diff, kein Review, keinen automatisierten Test. Jede Änderung ist Handarbeit im Studio, und jede Prüfung ist ein Mensch, der sich durch neun Wizard-Schritte klickt.

Dazu kommen die Details, die man erst im Betrieb sieht. Flows nehmen ihre Argumente positionsbasiert entgegen (text, text_1, text_2), die Reihenfolge ist der Vertrag. Wer einen Parameter in der Mitte einfügt, verschiebt still die Bedeutung aller folgenden. Die Vergabe fortlaufender IDs zählte vorhandene Listeneinträge, was nach einer Löschung doppelte IDs erzeugt und bei parallelen Einreichungen ohnehin ein Rennen ist. Und der Zertifizierungs-Submit hatte kein Rollback: Brach er in der Mitte ab, blieb ein halber Datensatz zurück.

Ein Fehlermodus aus dem Betrieb zeigt das Muster besonders klar. Nach dem Anlegen neuer SharePoint-Spalten arbeitete die Admin-App weiter mit einem eingefrorenen Schema-Snapshot ihres Connectors. Die Daten waren da, die App kannte sie schlicht nicht. Kein Fehler im Code, kein Log, keine Meldung. Nur Felder, die es aus Sicht der App nicht gab. Unlösbar ist so etwas nie, aber das Schema-Wissen liegt in einem Artefakt, das niemand versioniert und niemand testet.

Der Grund: die nächste Runde wäre wieder Handarbeit gewesen

Den Ausschlag gab kein einzelner Vorfall, sondern eine Rechnung über die kommenden Runden. Auf dem Plan stand unter anderem die Aufspaltung der Registrierungsarten, und dafür hätte der größte Assistenten-Screen im Studio ohnehin restrukturiert werden müssen. Fachlich war das ein Teil-Rebuild, nur ohne Diff, ohne Review und ohne Test. Danach wäre die nächste Runde wieder genauso gelaufen, und die übernächste auch. Wartbarkeit war damit kein weiches Argument mehr, sondern der Posten, der jede künftige Anforderung verteuert.

Der zweite Punkt hat mit der Plattform gar nichts zu tun, sondern mit dem, was sich beim Schreiben von Code verändert hat. Der Vorsprung von Low-Code lag immer dort: Klicken war schneller als Tippen. Mit KI-gestützter Entwicklung stimmt diese Rechnung nicht mehr. Dieselbe Fachlichkeit entsteht heute schneller und verlässlicher als Code, als sie sich im Studio zusammenklicken lässt, und sie entsteht in einer Form, die man lesen, prüfen und versionieren kann. Genau so steht es auch im Entscheidungsdokument: Der Bau der Anwendung war der Teil, der schnell geht, und die Zeit ging für Tenant-Setup, Abnahme und Cutover drauf.

Der dritte Punkt ist der, den man in Low-Code gar nicht erst versucht. Es gibt keinen automatisierten Test, also ist jede Prüfung ein Mensch mit einer Checkliste, und genau dieses manuelle Testen war im Projektverlauf die verlässlichste Quelle für Terminüberschreitungen. Eine Plattform, auf der sich Regressionstests nicht automatisieren lassen, verlangt bei jeder Änderung denselben manuellen Aufwand wie bei der ersten.

Der Aufwand für den Umstieg selbst war dabei nicht das Argument, das viele vermuten. Der Rebuild hat ein bis zwei Wochen gedauert, dazu einen Tag für einen Proof of Concept, der die beiden echten Unbekannten vorab klären sollte: den Token-Fluss für Gastkonten und Lookup-Spalten über Graph. Der Power-Apps-Pfad hätte ungefähr genauso lange gebraucht, vermutlich eher etwas länger. Der Unterschied lag nicht in der Dauer, sondern in Mühsal und Verlässlichkeit: Studio-Handarbeit ohne Testnetz ist zäher und produziert mehr Fehler als dieselbe Fachlichkeit in Code.

Vier Wege, drei davon kosten pro Kopf

Vor der ersten Zeile neuen Codes stand ein Entscheidungsdokument mit vier Optionen. Es lohnt sich, sie kurz durchzugehen, weil die Absage jeweils einen anderen Grund hat.

Auf Canvas bleiben und umbauen. Der Weg aus dem vorigen Abschnitt. Er löst die Runde, die ansteht, und keine der folgenden: Die geplanten Umbauten waren fachlich fast ein Rebuild, nur eben ohne die Vorteile eines Rebuilds.

Dataverse mit Model-driven Apps. Scheitert am Datenspeicher. SharePoint ist dort nur über eingeschränkte virtuelle Tabellen erreichbar, ohne Anhang- und Personen-Spalten. Das hätte eine echte Datenmigration bedeutet, dazu einen kompletten Flow-Rebuild und Premium-Lizenzen für alle.

Power Apps Code Apps. Der naheliegendste Microsoft-Kandidat, seit Anfang 2026 allgemein verfügbar: echtes React, dazu die gewohnten Connectors. Die Absage kommt aus der Lizenzierung. Jeder Endnutzer braucht eine bezahlte Lizenz, Gäste eingeschlossen. Die Mitglieder arbeiten aber als B2B-Gastkonten im Tenant des Vereins, und genau das war bisher kostenlos.

Power Pages. Beginnt bei rund 200 $ im Monat für 100 authentifizierte Nutzer, unabhängig davon, ob die Seite genutzt wird.

Geblieben ist eine eigene Web-App: React mit Vite im Frontend, Azure Functions in TypeScript als API, beides zusammen deployt auf Azure Static Web Apps. Der Punkt, der diesen Weg überhaupt erst gangbar macht, ist eine Architekturentscheidung aus der Power-Apps-Zeit: Die Daten lagen in SharePoint, nicht in Dataverse. SharePoint ist über Microsoft Graph eine ganz normale REST-Datenquelle. Connectors sind am Ende Microsofts Verpackung um genau diese API, und eine eigene App ruft sie direkt auf.

Damit war die Migration ein Frontend- und Logik-Austausch, kein Datenprojekt. Kein einziger migrierter Datensatz, und die alten Apps blieben während der gesamten Umstellung auf denselben Listen lauffähig.

Was „lokal ausführbar“ im Alltag ändert

Die Dev-Experience, die daraus geworden ist, klingt banal, bis man sie wieder hat: Die Anwendung läuft auf dem eigenen Rechner. Ein Kommando startet Frontend und API, ein zweites setzt einen In-Memory-Mock von Microsoft Graph davor (MOCK_GRAPH=1). Kein Tenant, kein Testmandant, keine Anmeldung, keine geteilte Umgebung, in der zwei Leute sich gegenseitig die Testdaten überschreiben.

Das ist die Voraussetzung für alles Weitere. Ein Wizard-Schritt lässt sich in Sekunden ausprobieren statt in Minuten. Ein Fehlerfall lässt sich gezielt herbeiführen, statt auf ihn zu warten.

Der zweite Baustein ist ein gemeinsames Paket shared/ im Monorepo, die Single Source of Truth für die Domäne: SharePoint-Feldnamen, erlaubte Auswahlwerte, Geschäftsregeln als Zod-Schemas, Upload-Vorgaben und den Seed-Datensatz. Frontend, API, Mock und das Skript, das die Test-Site aufbaut, konsumieren alle dieselbe Quelle. Der eingefrorene Schema-Snapshot von oben kann in dieser Konstruktion nicht mehr entstehen, weil es kein zweites Schema gibt, das veralten könnte.

Und schließlich das Unspektakuläre, das in der Canvas-Welt komplett fehlte: Alles liegt in Git. Im Migrationszeitraum sind 204 Commits entstanden, jeder als Diff lesbar, jeder überprüfbar. Bei jedem Push läuft die CI und baut alles und führt alle Tests aus. Deployt wird bewusst manuell, mit getrennten Tokens und getrennten App-Registrierungen für Staging und Produktion.

Drei Ebenen Tests, eine davon im echten Tenant

Die Testbarkeit ist der Punkt, der sich am deutlichsten in Zahlen ausdrückt. Die Absicherung liegt heute auf drei Ebenen.

Rund 920 Unit- und API-Tests decken die Fachlogik ab. Der aufwendigste Teil davon ist ein erschöpfender Durchlauf durch die Pflichtfeld- und Sichtbarkeitsmatrix der Assistenten: 246 Kombinationen aus Produkttyp, Registrierungsart und OEM-Fall, jede einzeln geprüft. Dazu kommt gezielte Fehlerinjektion an jedem Schritt der Schreibpipeline, einschließlich des unangenehmsten Falls, bei dem auch das Rollback noch fehlschlägt. Datumsgrenzen werden mit injizierter Uhr getestet statt mit der echten Systemzeit.

44 lokale End-to-End-Tests mit Playwright fahren die kompletten Assistenten im Browser durch, gegen den Mock-Graph und mit einer Entwickler-Anmeldung. Wichtig dabei: Diese Anmeldung läuft durch dasselbe Autorisierungs-Gate wie ein echtes Token. Der Mock ist kein leeres Versprechen, sondern bildet Paging, 404- und 409-Verhalten und Konfliktfälle nach.

43 Staging-Tests laufen gegen die tatsächlich deployte Anwendung und eine echte SharePoint-Test-Site. Sie melden sich mit einem echten Entra-Konto an, inklusive MFA: Der zweite Faktor wird als TOTP im Test generiert. Sie laden echte Dateien hoch, erzeugen echte Word- und PDF-Dokumente und lösen echten Mailversand aus. Die Zusicherung, dass eine Bestätigungsmail angekommen ist, prüft der Test, indem er ein Postfach liest.

Zusammen sind das über 1.000 Tests, die vor jedem Release in Minuten durchlaufen. Vorher war der Regressionstest ein Mensch mit einer Checkliste.

Als Gegenprobe stand am Release-Kandidaten ein unabhängiger Audit, der den neuen Code gegen die alten Power-Fx-Quellen gedifft hat, Zeile für Zeile. Ergebnis: keine blockierenden Befunde, 31 bestätigte kleinere Punkte, alle am selben Tag behoben.

Der Preis dieser Entscheidung

Der erste Preis steht in keiner Erfolgsmeldung: Die Ablösung ist nicht vollständig. Eine dritte, kleinere Canvas App ist geblieben, über die Mitgliedsunternehmen neue Nutzer beantragen. Sie gehörte nie zum Zertifizierungsprozess und stand deshalb nicht im Migrationsumfang. Ihre Freigabeseite ist trotzdem mitgewandert, weil sie in der Geschäftsstelle neben allem anderen liegen sollte. Das Ergebnis ist ein Prozess, der heute über zwei Systeme läuft, und ein Verein, der zwei Welten betreibt statt einer: eine Web-App mit eigenem Deployment und eine Power App mit eigenen Flows. Zwei Welten sind teurer als eine, gleich welche beiden es sind. Ob die dritte App nachgezogen wird, ist eine offene Entscheidung.

Der zweite Preis ist die Abhängigkeit von Entwickler-Kapazität. Das übliche Gegenargument kenne ich, und es trägt nur die halbe Strecke: Eine Canvas App kann im Zweifel jemand mit Studio-Zugang und Geduld anpassen. Diese hier konnte das längst nicht mehr, dafür war sie zu groß, und die Duplikation aus dem ersten Abschnitt hätte jede Änderung an vier Stellen verlangt. Die niedrige Einstiegshürde war also schon vor der Migration verschwunden. Eine echte Verschiebung bleibt trotzdem: Wer heute etwas ändern will, braucht jemanden, der Code schreibt. Ein Lock-in ist das nicht, denn der Code liegt beim Verein, und jeder Entwickler kann ihn übernehmen. Aber jemand muss es tun, und der Kreis derer, die es können, ist ein anderer als vorher.

Der dritte Preis ist die Kehrseite genau des Arguments, das weiter oben für den Rebuild spricht. Wenn KI-gestützte Entwicklung das Schreiben billig macht, entsteht Code billig, aber er wird deshalb nicht billig verstanden. Die Bremse sitzt danach: im Review, im Test, in der Frage, ob das Geschriebene die Fachlichkeit wirklich trifft. Wer die eine Bremse löst und die andere nicht mitbaut, bekommt schneller Schulden statt schneller Software. Die drei Testebenen aus dem vorigen Abschnitt sind deshalb keine Kür, sondern die Bedingung, unter der dieses Tempo überhaupt zulässig ist.

Der vierte Preis ist ein Fehlermodus, den es vorher nicht gab. Aus einer Umgebung sind zwei geworden: Staging und Produktion, mit getrennten App-Registrierungen, getrennten Zugangsdaten und getrennten SharePoint-Sites. Das ist die Voraussetzung dafür, vor jedem Release gegen eine echte Umgebung zu testen, ohne echte Mitgliederdaten anzufassen. Es heißt aber auch, dass jede Einstellung zweimal existiert und die beiden Werte auseinanderlaufen können. Ein Beispiel aus diesem Projekt: Eine Einstellung, die in Staging bewusst hätte abweichen sollen, zeigt bis heute auf denselben Wert wie in Produktion, weil ihre Trennung nichts blockiert hat und deshalb liegen blieb. Konfigurationsdrift erzeugt keinen roten Test. Sie fällt im Betrieb auf, oder gar nicht.

Was es gebracht hat

Zwei Canvas Apps und 23 Flows sind heute durch 22 API-Endpunkte und 16 Screens ersetzt. Die acht fast identischen Upload-Flows sind eine parametrisierte Routine mit serverseitiger Prüfung von Dateityp, Größe und Seitenverhältnis, dort, wo vorher ein Hinweistext neben dem Feld stand, den niemand erzwungen hat. ID-Vergabe, Ordneranlage, Uploads und das Anlegen des Datensatzes sind eine Transaktion mit Wiederholversuch und vollständigem Rollback. Damit sind die doppelten IDs und der halbe Datensatz erledigt, und die Zertifizierung hat das Rollback bekommen, das sie nie hatte.

Nebenbei hat die Architektur ein Problem gelöst, das vorher als Anzeigeproblem behandelt wurde. Sichtbarkeitsregeln lebten in der Oberfläche, die Datenschicht kannte sie nicht. Heute spricht der Browser nicht mehr mit SharePoint. Die API ist das einzige Tor, sie arbeitet mit einer eigenen Identität nach dem Prinzip der geringsten Rechte auf genau einer Site, und die Zuordnung eines Aufrufers zu seinem Unternehmen passiert serverseitig. Aus einer Regel im Frontend ist eine Regel in der Architektur geworden.

Der Umstieg selbst war unspektakulär, und das war Absicht. Die Mitglieder-App ging live, indem eine Gruppe der Anwendung zugewiesen wurde, eine Aktion, die in Sekunden rückgängig zu machen ist. Die alten Apps wurden anschließend nicht gelöscht, sondern nur unveröffentlicht. Von der Systemanalyse bis zum vollständigen Cutover vergingen drei Wochen.

Und die laufenden Kosten: Die Anwendung liegt heute bei 0 € im Monat. Static Web Apps und Azure Functions bleiben in diesem Nutzungsprofil im kostenlosen Kontingent, und die Nutzung müsste um ein Vielfaches steigen, um es zu verlassen. Gastkonten kosten weiterhin nichts. Der Unterschied zu den verworfenen Optionen ist keine Rabattfrage, sondern eine Frage der Skalierung: Lizenzen skalieren pro Kopf, Hosting skaliert pro Nutzung. Bei einem Verein mit vielen registrierten und selten aktiven Nutzern gewinnt die Nutzungsskalierung immer.

Wann eine Power App die richtige Wahl bleibt

Für einen kleinen internen Nutzerkreis mit vorhandenen M365-Lizenzen, überschaubarer Änderungsfrequenz und Formularen, die im Wesentlichen Formulare bleiben, ist Canvas nach wie vor der schnellste Weg zu echtem Nutzen. Genau für diese Fälle ist die Plattform gebaut, und genau dafür wird sie beworben. Der Kipp-Punkt ist erreicht, wenn drei Dinge zusammenkommen: wiederkehrende Änderungsrunden, externe Nutzer mit Lizenzfragen und Sichtbarkeitsregeln, die eigentlich Zugriffsregeln sind. Beim SMI e.V. waren am Ende alle drei da.

Dazu kommt ein Faktor, der in keiner Produktbroschüre steht und sich erst mit der Größe der Anwendung bemerkbar macht: Das Studio selbst wird zum Kostenpunkt. Es hat Tage, an denen es nicht sauber arbeitet, und ein Teil der Oberflächen-Bausteine trägt eine Vorschau-Kennzeichnung und kann sich zwischen zwei Releases ändern. Bei einem Formular fällt das kaum ins Gewicht. Bei einem Assistenten mit neun Schritten, dessen Mechanik man dreimal gebaut hat, ist es die Sorte Reibung, die man beim Aufsetzen des Projekts nicht eingeplant hat.

FAQ