Wer heute digitale Produkte auf Microsoft 365 baut, steht immer wieder vor derselben Frage: Reicht die Power Platform für Tempo, Sicherheit und Integration – oder braucht es ein „klassisches“ Web-Stack mit React/Next.js, Azure Functions und Microsoft Graph? Die gute Nachricht: Es ist selten ein Entweder-oder. In den meisten Projekten gewinnt ein bewusstes Sowohl-als-auch – Low-Code dort, wo es Geschwindigkeit bringt, Pro-Code dort, wo es Architektur und Skalierung verlangen.
Warum diese Entscheidung zählt
Low-Code senkt Time-to-Value, vereinfacht Governance und integriert nativ in M365. Pro-Code eröffnet vollständige Kontrolle über Frontend-UX, Rendering, API-Design, Performance-Tuning und Spezialanforderungen. Die Kunst liegt darin, Schnittstellen, Datenhaltung, Security und Betriebsmodell so zu kombinieren, dass beides zusammen eine belastbare Lösung ergibt. Genau hier setzt dieser Leitfaden an.
Was Low-Code heute kann
Die Power Platform ist längst erwachsen: Environments kapseln Apps, Flows und Daten – ideal, um Rollen, Zielgruppen und Sicherheitsanforderungen zu trennen. Data Loss Prevention (DLP)-Policies setzen Guardrails für Connector-Kombinationen, Managed Environments liefern zusätzliche Governance-Funktionen und Transparenz. Für Datensicherheit und Compliance sind das starke Ankerpunkte direkt im Tenantscope.
Dataverse wiederum ist mehr als ein „Datenbankservice“: Es bringt ein fein granuliertes Sicherheitsmodell mit Rollen, Spalten-/Zeilenberechtigungen sowie eine enge Verzahnung in Apps und Flows. Für Canvas-Apps empfiehlt Microsoft Dataverse explizit bei komplexen Daten- und Sicherheitsmodellen – inklusive Referenzarchitekturen.
Wo Low-Code an Grenzen stößt
Grenzen sind seltener „können wir nicht“, häufiger „sollten wir hier wirklich?“. Klassiker sind große Datenmengen und Filterlogik: Nicht delegierbare Abfragen ziehen Daten clientseitig und stoßen auf die 500-bis-2000-Record-Grenze; in SharePoint kommt die List-View-Threshold von 5.000 Items pro Abfrage hinzu. Solche Limits sind für viele Fachanwendungen völlig ok – für datenintensive Szenarien aber ein echtes Architektur-Signal.
Auch Prozessdauer und Kapazität sollten bewusst designt werden: Ein einzelner Cloud-Flow läuft maximal 30 Tage; danach timeouten wartende Schritte wie Approvals. Parallel begrenzen Request-Kontingente pro Lizenz die API-Nutzung über Power Apps/Automate hinweg – gute Gründe, lange Prozesse zu „segmentieren“ und stark frequentierte Logik serverseitig auszulagern.
Wann Pro-Code die bessere Wahl ist
Sobald Rendering, Performance-Optimierung und SEO steuerbar sein müssen, spielt ein moderner React-Stack seine Stärken aus. Next.js auf Azure Static Web Apps unterstützt Server-Side Rendering und API-Routes – ideal für Portale mit dynamischen Inhalten und sauberem Caching-/ISR-Verhalten.
Geschäftslogik gehört in vielen Fällen in Azure Functions: Event-getrieben, schlank, skalierend – und je nach Plan (Consumption, Premium, Dedicated) mit passender Kosten- und Netzwerkintegration, bis hin zu Private Endpoints. Das ergibt klare Schnittstellen, sauber testbares Verhalten und eine stabile Grundlage für Lastspitzen.
Architekturpatterns, die Low- & Pro-Code verbinden
Backend-for-Frontend (BFF) mit Azure Functions
Power Apps oder Power Pages sprechen über einen schlanken BFF-Layer in Azure Functions. HTTP-Trigger definieren die API, Bindings koppeln Dienste wie Storage, Queues oder Service Bus, ohne dass Ihr Code die SDK-Plumbing erledigen muss. So bleibt der Client simpel, während Regeln, Validierungen und Integrationen zentral und skalierbar laufen.
Pro-Code-Erweiterungen direkt in der Power Platform
PCF-Komponenten heben die UX von Formularen und Views auf das gewünschte Niveau; Custom Connectors kapseln Fremd-APIs wiederverwendbar; Dataverse-Plug-ins verankern Business-Regeln transaktional auf dem Server. Damit wächst Low-Code kontrolliert in Richtung Pro-Code – ohne die Plattform zu verlassen.
Events & Integrationen als First-Class-Citizen
Mit Triggers/Bindings reagieren Functions auf Timer, Storage-Events oder Webhooks – perfekt, um langlaufende Abläufe zu entkoppeln, Workloads zu drosseln oder rechenintensive Jobs asynchron zu fahren. Ihre Low-Code-App nutzt nur noch stabile, idempotente Endpunkte.
Security & Identity: Prinzipien, nicht Workarounds
Für Microsoft Graph und M365-Ressourcen gilt: Delegated Permissions, wenn die App im Benutzerkontext handeln soll; Application Permissions, wenn sie eigenständig agiert – dann mit Admin-Consent und entsprechendem Schutz. Diese Entscheidung prägt Ihr Sicherheits- und Prüfkonzept bis hinein in Logging und Secrets-Handling.
Governance & ALM: Aus Projekten Produkte machen
Ohne ALM kein skalierbares Delivery: Power Platform Pipelines demokratisieren Deployments zwischen Dev/ Test/ Prod; GitHub Actions und die Azure DevOps Build Tools automatisieren Export, Solution-Build, Checks und Imports – inklusive Quellcode-Versionierung und Quality Gates. DLP-Policies sorgen dabei dafür, dass kein Connector-Mix die Datenhoheit unterläuft.
Kosten- und Betriebsmodelle im Vergleich
Low-Code rechnet sich stark über verkürzte Implementierung und Wartbarkeit; der laufende Betrieb skaliert über Lizenzen und Request-Kontingente. Pro-Code skaliert finanziell über Hosting-Pläne: Consumption (pay-per-use), Premium (voraussagbare Ressourcen, VNET), Dedicated/App Service (klassische, geteilte Ressourcen). Die Wahl hängt vom Lastprofil, Integrationsgrad und Netzwerkanforderungen ab – nicht vom „Gefühl“.
Entscheidung in Prosa – typische Szenarien
Wenn ein Fachbereich in wenigen Wochen ein internes Portal braucht, dessen Datenmodell moderat ist und das Team nahe am Prozess sitzt, spricht vieles für eine Canvas-App auf Dataverse, flankiert von ein paar Flows. Wächst der Anwendungsfall zu einem öffentlichen Kundenportal mit SEO-Ansprüchen, komplexer Navigation, serverseitigem Rendering und hoher Last, rückt ein Next.js-Frontend mit Azure-Functions-BFF in den Mittelpunkt, das weiterhin Dataverse oder M365-Daten konsumiert. Gibt es harte Compliance-Auflagen, sichern DLP-Policies, Managed Environments und klar definierte Graph-Berechtigungen den Rahmen – unabhängig vom UI-Paradigma.
Beispiel aus der Praxis: Service-Portal „hybrid gedacht“
Extern sehen Kundinnen ein Next.js-Portal mit SSR für schnelle, indexierbare Seiten und einem BFF in Azure Functions, der Tickets anlegt, Dateien in Storage ablegt und Dataverse-Einträge transaktional erzeugt. Intern arbeiten Servicemitarbeitende in einer Model-Driven-App mit PCF-Komponenten für Spezial-UIs. Power Automate orchestriert Benachrichtigungen und SLAs – in handlichen, entkoppelten Flows, damit die 30-Tage-Grenze nie stört. Governance sichert DLP und Managed Environments, ALM läuft über Pipelines bzw. GitHub Actions. Das Ergebnis: schnelle Auslieferung, robuste Architektur, saubere Betriebsstory.
ALM in der Praxis – der rote Faden
Starten Sie mit einer Environment-Strategie, heben Sie alle Artefakte in Solutions, automatisieren Sie Deployments mit Pipelines und/oder GitHub Actions, und prüfen Sie jede Änderung gegen Quality-Checks. So entsteht aus einem Projekt ein Produkt mit verlässlichem Fluss von der Idee bis zur Produktion.
Low-Code zuerst, Pro-Code gezielt – und beides professionell
Die beste Wahl ist selten dogmatisch. Beginnen Sie dort, wo Low-Code Sie schnell voranbringt, und erweitern Sie mit Pro-Code, wo Architektur, Last oder UX es verlangen. Entscheidend sind saubere Schnittstellen, ein bewusstes Daten- und Berechtigungskonzept sowie ein reifes ALM-Setup. So werden Weblösungen auf Microsoft 365 zum echten Wettbewerbsvorteil – heute und langfristig.
