Microsoft Power Apps an der Grenze? Wann du auf echte Software umsteigst

“Das haben wir uns intern selbst gebaut. In zwei Wochen.” Der Satz kommt meistens mit einer Mischung aus Stolz und Unbehagen. Stolz, weil es funktioniert hat. Unbehagen, weil inzwischen 200 Leute damit arbeiten und niemand so genau weiß, was passiert, wenn der Kollege aus dem Controlling kündigt, der das Ding gebaut hat.

Power Apps ist ein gutes Werkzeug. Für Formulare, Genehmigungen und einfache Datenerfassung ist Low-Code der schnellste Weg von der Idee zur laufenden Lösung. Die Frage ist nicht, ob es taugt. Die Frage ist, wo die Power Apps Grenzen liegen und ab wann Individualsoftware die ehrlichere Antwort ist.

Dass Low-Code überhaupt so attraktiv wurde, hat einen nüchternen Grund. Laut Bitkom fehlten im August 2025 rund 109.000 IT-Fachkräfte in Deutschland, eine offene Stelle blieb im Schnitt 7,7 Monate unbesetzt. Wer keine Entwickler bekommt, baut eben selbst. Das ist keine Schwäche, das ist Pragmatismus.

Wenn aus dem Prototyp eine Systemlast wird

Der Übergang passiert leise. Eine App löst ein Problem, die Nachbarabteilung will sie auch, jemand hängt eine Excel-Liste dran, dann noch einen Flow. Nach 18 Monaten hast du keinen Prototyp mehr. Du hast ein System, an dem Umsatz hängt.

Nur wurde es nie wie ein System behandelt. Getestet wird nicht. Test Studio gibt es, aber es lässt Komponenten, verschachtelte Galerien und Mediensteuerelemente außen vor, und im Fachbereich rührt es praktisch niemand an. Es gibt keine saubere Versionierung, weil die Formelsprache in einer Datei steckt, die kein Mensch im Diff lesen will. Und es gibt selten Application Lifecycle Management, also getrennte Umgebungen für Entwicklung, Test und Produktion mit kontrollierten Übergängen. Microsoft liefert das Werkzeug dafür mit. Nur nutzt es fast niemand, der aus dem Fachbereich kommt und einfach ein Formular bauen wollte.

Dazu kommt der Wildwuchs. Citizen Development heißt in der Praxis oft: Sieben Abteilungen bauen sieben Apps auf sieben Datenmodellen, und drei davon pflegen dieselbe Kundenliste. Wer schon einmal versucht hat, in einem gewachsenen Tenant herauszufinden, welche App auf welche Datenquelle zeigt, kennt das Gefühl.

Und dann der teuerste Punkt, der in keinem Budget steht. Der Kollege, der die App betreut, macht das neben seinem Job. Laut Destatis lag die durchschnittliche Arbeitsstunde in Deutschland 2025 bei 45,00 €. Sechs Stunden pro Woche für Fehlersuche und kleine Änderungen sind, auf 46 Arbeitswochen gerechnet, grob überschlagen rund 12.400 € im Jahr. Bezahlt aus dem Controlling-Budget, sichtbar in keiner Lizenzabrechnung.

Die technischen Grenzen, die Microsoft selbst dokumentiert

Hier wird es konkret. Alle folgenden Zahlen stehen so in der offiziellen Dokumentation, Stand Juli 2026. Microsoft ändert sie regelmäßig, prüf sie vor jeder Entscheidung nach.

Delegation, das 500-Zeilen-Problem. Power Fx, die Formelsprache hinter Power Apps, versucht Filter und Sortierung an die Datenquelle weiterzureichen. Das nennt sich Delegation: Die Datenbank arbeitet, die App zeigt nur das Ergebnis. Klappt das nicht, holt Power Apps laut Delegation-Dokumentation vom Januar 2026 nur die ersten 500 Datensätze und rechnet lokal weiter. Im App-Setting lässt sich das auf maximal 2.000 hochsetzen.

Das Tückische ist nicht das Limit. Das Tückische ist, dass die App keinen Fehler wirft. Sie liefert ein falsches Ergebnis. Microsoft schreibt selbst, dass Nutzer eine Teilantwort für die vollständige Antwort halten können. Genau deshalb passt eine Auswertung im Vertrieb plötzlich nicht mehr zum ERP, und niemand findet den Grund. Nicht delegierbar sind unter anderem If, Multiplikation, Division, Textfunktionen wie Left und Len, Concat, GroupBy und Collect. Wer eine echte Auswertung baut, landet fast zwangsläufig in dieser Liste.

Request-Limits, gleich zwei davon. Microsoft dokumentiert 40.000 Power Platform Requests pro Premium-Lizenz und Nutzer je 24 Stunden, Stand März 2026. Über Pay-as-you-go oder eine Microsoft-365-Lizenz sind es 6.000. Davon getrennt greifen die Service-Protection-Limits von Dataverse, der Datenbank hinter der Power Platform: 6.000 Requests pro Nutzer in einem gleitenden Fünf-Minuten-Fenster je Webserver, dazu 20 Minuten kombinierte Ausführungszeit im selben Fenster und maximal 52 gleichzeitige Anfragen. Wer drüber geht, bekommt einen HTTP-429-Fehler mit Retry-After-Header, das nennt sich Throttling. Beide Limits werden getrennt bewertet. Und Microsoft weist ausdrücklich darauf hin, dass Batch-Operationen die 40.000er-Grenze nicht umgehen: Jede CRUD-Operation zählt einzeln, egal ob sie im Batch steckt. Beim Fünf-Minuten-Fenster hilft dir ein Batch zwar bei der Zahl der Requests, dafür läufst du in die Ausführungszeit.

Für die tägliche Urlaubsantrag-App ist das komplett egal. Für die nächtliche Synchronisierung von 400.000 Artikelpositionen ist es die Wand, gegen die du fährst.

Speicher. Jede Premium-Lizenz bringt 250 MB Dataverse-Datenbank und 2 GB Dateispeicher, gepoolt über den ganzen Tenant. Rutscht der Tenant in die Überkapazität, lassen sich laut Microsoft keine neuen Umgebungen mehr anlegen, kopieren oder wiederherstellen. Das trifft dann nicht die eine App, die zu viel frisst. Das trifft alle.

Power Apps Grenzen: Individualsoftware rechnet sich später, als dir lieb ist

Jetzt der kaufmännische Teil, und der ist unbequemer, als die Verkaufspräsentationen meiner Branche behaupten.

Zu den Preisen. Microsoft listet Power Apps Premium auf der deutschen Seite mit 17,30 € pro Nutzer und Monat bei jährlicher Zahlung, ab 2.000 Lizenzen mit 10,40 €. Die US-Liste nennt 20 US-Dollar und 12 US-Dollar. Das ist keine Umrechnung, das sind zwei getrennte Listenpreise. Wenn du in einem Blog “20 €” liest, hat dort jemand nur das Dollarzeichen getauscht.

Der billige Einstieg ist übrigens weg. Microsoft hat zum 2. Januar 2026 den Verkauf des Per-App-Plans für Neukunden eingestellt, das waren 5 US-Dollar pro Nutzer, App und Monat. Bestandskunden im Enterprise Agreement laufen weiter, CSP-Kunden sind nicht betroffen, MPSA-Kunden bekommen nach Vertragsende 60 Tage für den Wechsel. Für alle anderen bleiben Premium pro Nutzer oder der Pay-as-you-go-Zähler über Azure mit 10 US-Dollar pro aktivem Nutzer, App und Monat.

Rechnen wir ein Beispiel. 120 Leute in der Lagerlogistik, eine App: 120 mal 17,30 € mal 12 Monate sind 24.912 € im Jahr. Jedes Jahr, ohne dass die App eine einzige neue Funktion bekommt.

Fairerweise gehört dazu, warum wir mit Premium rechnen. Über den Pay-as-you-go-Zähler wären es bei einer einzigen App rund 14.400 US-Dollar, also grob die Hälfte. Premium ist die Lizenz für unbegrenzte Apps, der Zähler dagegen bringt laut Microsoft nur 6.000 Requests pro Nutzer, App und Tag mit statt der 40.000 aus der Premium-Lizenz. Bei einer Lager-App, die nachts synchronisiert, fährst du damit in die nächste Wand. Wer die Requests nicht braucht, rechnet mit Pay-as-you-go, und dann trägt sich Individualsoftware über gesparte Lizenzen praktisch nie.

Jetzt die Gegenrechnung, die selten jemand sauber macht. Eine passende Individualsoftware für 60.000 € kostet dich in der Wartung erfahrungsgemäß 15 bis 25 % der Entwicklungskosten pro Jahr, also 9.000 bis 15.000 €. Setz die Mitte an. Im ersten Jahr zahlst du 72.000 € statt 24.912 €. Der Gleichstand kommt erst irgendwo im fünften Jahr.

Hand aufs Herz: Wer dir vorrechnet, dass sich Individualsoftware allein über gesparte Lizenzen nach einem Jahr trägt, rechnet dir was vor. Der Umstieg lohnt sich fast nie wegen der Lizenzkosten. Er lohnt sich, wenn die Lizenzkosten, die technische Wand und die Wartbarkeit zusammenkommen. Dann aber deutlich.

Ein Faktor gehört noch dazu, den Entscheider gern übersehen. Der Bitkom Cloud Report vom Juni 2026 zeigt, dass 59 % der Unternehmen Lock-in-Effekte als größte Wechselhürde sehen und nur rund ein Drittel je den Anbieter gewechselt hat, 26 % einmal und 8 % mehrfach. 64 % hatten 2025 gestiegene Cloud-Betriebskosten. Eine Anwendung, die tief in Dataverse, Flows und Connectoren steckt, ist kein Vertrag, den du zum Quartalsende kündigst. Das ist eine Umzugskiste, die jedes Jahr schwerer wird.

Wo Power Apps die richtige Wahl bleibt

Bleib bei Power Apps, wenn dein Fall so aussieht: überschaubare Nutzerzahl, Abfragen, die deutlich unter der Delegationsgrenze bleiben oder sauber delegierbar sind, ein Prozess, der ohnehin komplett in Microsoft 365 lebt, und keine Integration, die nachts große Datenmengen schaufelt. Urlaubsanträge, Schadensmeldungen, Inventuraufnahme, Freigabe-Workflows. Für so etwas eine eigene Anwendung bauen zu lassen, wäre Geldverbrennung.

Power Apps ist außerdem ein hervorragendes Werkzeug, um eine Idee zu testen, bevor du Geld in Entwicklung steckst. Zwei Wochen Bauzeit gegen drei Monate Konzeptdiskussion, das ist kein fairer Kampf. Wir empfehlen das selbst, wenn noch keiner weiß, ob der Prozess in der Praxis überhaupt angenommen wird.

Und wenn deine App seit drei Jahren läuft, 15 Leute nutzen sie, die Lizenz kostet dich 3.000 € im Jahr und niemand beschwert sich: Fass sie nicht an. Ein Umstieg, der kein Problem löst, ist verbranntes Geld. Die ehrlichen Warnsignale sind andere. Delegationswarnungen, die jemand weggeklickt hat. Nutzer, die Zahlen aus der App gegen Excel prüfen, weil sie ihr nicht mehr trauen. Eine Lizenzrechnung, die schneller wächst als die Zahl der gelösten Probleme. Wie man solche Signale systematisch liest, haben wir im Beitrag zu den Grenzen von Standardsoftware aufgeschrieben, und wenn du zwischen Kaufen und Bauen schwankst, hilft dir die Make-or-Buy-Entscheidung weiter.

Wenn du gerade an einem dieser Punkte stehst, schau dir an, wie wir Software entwickeln. Oder hol dir in einer Fokus-Session eine ehrliche Einschätzung zu deiner konkreten App. Kein Verkaufsgespräch. Eine Stunde, in der wir gemeinsam draufschauen und dir auch sagen, wenn du bei Power Apps bleiben solltest.