Migration zu Logic Apps: wann sich der Wechsel von Power Automate lohnt

Power Automate ist für viele Teams der perfekte Einstieg in die Automatisierung: Flows lassen sich per Klick bauen, Lizenzen sind über Microsoft 365 oft schon vorhanden, und die Community-Konnektoren decken die meisten Alltagsfälle ab. Doch es gibt einen Punkt, an dem die Plattform an ihre Grenzen stößt, etwa bei hohem Ausführungsvolumen, komplexen Enterprise-Workloads oder wenn IT-Sicherheit strengere Anforderungen an Netzwerk und Zugriffssteuerung stellt. Microsoft hat für genau diesen Fall einen offiziellen Migrationspfad definiert: von Power Automate zu Azure Logic Apps (Standard).

Dieser Beitrag zeigt, an welchen Symptomen Sie erkennen, dass ein Wechsel sinnvoll wird, was Azure Logic Apps (Standard) technisch anders macht und wie der Migrationsprozess laut Microsoft-Dokumentation konkret abläuft. Sie behalten dabei die Kontrolle über die Entscheidung: Nicht jeder Flow muss migriert werden, aber wer die Signale kennt, kann rechtzeitig planen statt im Ernstfall zu reagieren.

Wann Power Automate an Grenzen stößt

Power Automate ist bewusst auf Bürgerentwickler und Fachanwender ausgelegt und arbeitet mit gemeinsam genutzten Ressourcen. Genau das führt bei steigender Last zu spürbaren Engpässen. Laut der Microsoft-Dokumentation zu Plattformgrenzen gelten unter anderem folgende Einschränkungen:

• Tägliche Aktionslimits pro Lizenz. Ein Flow mit einem Trigger und einer Aktion verbraucht bei jedem Lauf bereits zwei Aktionen. Bei kostenlosen beziehungsweise in Microsoft 365 enthaltenen Lizenzen liegt das Tageslimit deutlich niedriger als bei Premium- oder Prozesslizenzen.
• Connector-Drosselung. Jeder Konnektor hat eigene Ratenlimits. Wird dieses Limit erreicht, liefert der Dienst den Fehlercode 429 mit einer Meldung wie „Rate limit is exceeded. Try again in 27 seconds“.
• Action-Burst-Limit. Aktuell liegt die Obergrenze bei 100.000 Aktionen pro fünf Minuten und Flow. Wird das überschritten, drosselt die Plattform den Flow automatisch.
• Automatische Deaktivierung. Ein Flow, der 14 Tage in Folge durchgehend gedrosselt wird, schaltet Power Automate ab. Er lässt sich zwar wieder aktivieren, wird aber bei anhaltender Überlastung erneut deaktiviert.
• Grenzwerte für Schleifen und Parallelität. Eine „Auf jedes anwenden“-Schleife verarbeitet je nach Performance-Profil maximal 5.000 oder 100.000 Array-Elemente, gleichzeitige Ausführungen sind bei aktivierter Parallelitätssteuerung auf maximal 100 begrenzt.

Diese Zahlen sind kein Zufall, sondern Ausdruck des Zwecks der Plattform: kleine bis mittlere Automatisierungen für Fachanwender, nicht dauerhafte Hochlast-Integrationen. Wenn Ihre Flows regelmäßig gegen diese Grenzen laufen, wenn Sie auf 429-Fehler in den Logs stoßen oder wenn ein Flow trotz Optimierung immer wieder gedrosselt wird, ist das ein klares Signal, die Architektur zu überdenken.

Was Azure Logic Apps (Standard) anders macht

Microsoft stellt Power Automate und Azure Logic Apps (Standard) in der offiziellen Migrationsdokumentation direkt gegenüber. Der Kern des Unterschieds: Power Automate ist auf geteilte Ressourcen und einfache Bedienung ausgelegt, Logic Apps (Standard) auf dedizierte Kapazität und Enterprise-Anforderungen.

Leistung und Skalierbarkeit

Ein Standard-Logic-App läuft auf dedizierten Compute-Ressourcen, entweder als Single-Tenant-Instanz, in einer App Service Environment oder in einer hybriden Bereitstellung. Workflow-Instanzen werden standardmäßig parallel ausgeführt, was die Verarbeitungszeit bei komplexen Aufgaben reduziert. Für hochvolumige Workloads, die in Power Automate ständig an Aktions- oder Connector-Limits stoßen, ist das der entscheidende Vorteil: kein geteilter Ressourcenpool mehr, sondern feste Kapazität, die elastisch mitskaliert.

Sicherheit und Compliance

Azure Logic Apps (Standard) bringt Funktionen mit, die in Power Automate schlicht nicht existieren:

• Virtual-Network-Integration und private Endpunkte, wodurch Workflows nicht mehr zwangsläufig über das öffentliche Internet laufen müssen.
• Managed-Identity-Authentifizierung, die manuell verwaltete Zugangsdaten überflüssig macht.
• Rollenbasierte Zugriffssteuerung auf Ressourcenebene. Während RBAC in Power Automate an den einzelnen Benutzer gebunden ist, greift sie in Logic Apps auf Ressourcenebene. Verlässt also die Person, die einen Workflow erstellt hat, das Unternehmen, geht der Zugriff auf den Workflow nicht verloren.

Entwicklung, Versionierung und Betrieb

Für Teams, die produktiv mit CI/CD arbeiten, bietet Logic Apps (Standard) volle Git-Integration über Visual Studio Code, inklusive Änderungsverfolgung, Branching und automatisierten Deployments über Azure DevOps oder GitHub Actions. Workflows lassen sich als ARM-Vorlagen oder Bicep-Dateien definieren, also als Infrastructure as Code, was wiederholbare und weniger fehleranfällige Bereitstellungen ermöglicht. Zusätzlich unterstützt die Plattform mehr als 1.400 Konnektoren, eigene Codeausschnitte in .NET, C# oder PowerShell direkt im Workflow sowie Bereitstellungen ohne Ausfallzeiten über Deployment Slots.

Wichtig für die Einordnung: Diese Vorteile richten sich an professionelle Entwicklerinnen und IT-Teams, nicht an Fachanwender ohne Entwicklungshintergrund. Wer einfache, punktuelle Automatisierungen baut, gewinnt durch den Wechsel wenig und verliert die einfache Bedienbarkeit von Power Automate.

Der Migrationsprozess in der Praxis

Microsoft beschreibt die Migration nicht als automatische Konvertierung, sondern als geplanten Prozess mit eigener Testphase. Aus der Dokumentation lassen sich folgende Schritte ableiten:

1. Bestandsaufnahme. Prüfe, welche Flows tatsächlich von den Grenzen betroffen sind, etwa über die Analytics-Ansicht in Power Automate, die die Anzahl ausgeführter Aktionen pro Flow zeigt.

2. Zielarchitektur festlegen. Entscheide, ob Single-Tenant Azure Logic Apps, eine App Service Environment oder eine Hybridbereitstellung mit eigener Infrastruktur passt.

3. Workflow-Logik nachbauen. Die Flow-Logik wird im visuellen Designer oder direkt im JSON-Code-Editor von Azure Logic Apps nachgebildet, lokal in Visual Studio Code oder browserbasiert im Azure-Portal.

4. Verbindungen neu einrichten. Verbindungen zu Diensten wie SQL Server oder Azure Key Vault müssen manuell neu erstellt werden. Microsoft empfiehlt hier ausdrücklich rigorose Sicherheits- und Funktionstests.

5. Migration validieren. Die Dokumentation nennt vier Prüfschritte, die vor dem produktiven Umstieg abgeschlossen sein sollten: Funktionstests (bleibt die ursprüngliche Logik erhalten?), Verbindungstests, Sicherheitsvalidierung gegen Unternehmensrichtlinien und Performance-Tests, die sicherstellen, dass die migrierten Workflows die bisherigen Power-Automate-Leistungswerte übertreffen.

Plane für diesen Prozess bewusst Zeit ein. Anders als ein einfacher Export-Import-Vorgang erfordert die Migration, dass jede Verbindung, jede Berechtigung und jede Fehlerbehandlung neu durchdacht wird, gerade weil sich das Sicherheitsmodell fundamental unterscheidet: nutzerbasiert in Power Automate, ressourcenbasiert in Logic Apps.

Migrieren oder optimieren: eine Entscheidungshilfe

Nicht jeder Flow, der gelegentlich gedrosselt wird, braucht sofort eine vollständige Migration. Bevor Sie den Aufwand eines Plattformwechsels starten, lohnt sich ein Blick auf drei Fragen:

• Ist das Problem strukturell oder einmalig? Ein einzelner Lastspitze lässt sich oft durch Flow-Optimierung lösen, etwa durch Trigger-Bedingungen, das Aufteilen in mehrere Flows oder den Umstieg von „Auf jedes anwenden“ auf gefilterte Datenabfragen.
• Brauchen Sie wirklich Enterprise-Sicherheitsfeatures? Wenn Virtual-Network-Integration, private Endpunkte oder ressourcenbasierte RBAC aus Compliance-Gründen zwingend sind, führt an Logic Apps kein Weg vorbei.
• Steht ein Entwicklungsteam bereit? Logic Apps (Standard) setzt Kenntnisse in Visual Studio Code, Git und idealerweise CI/CD voraus. Ohne diese Ressourcen wird der Betrieb aufwendiger, nicht einfacher.

Wenn diese Fragen für einen Wechsel sprechen, lohnt sich eine strukturierte Migrationsplanung mit klaren Testkriterien, statt Workflows unter Zeitdruck während eines akuten Drosselungsproblems umzuziehen. Wer diesen Schritt nicht allein stemmen möchte, kann ihn auch extern begleiten lassen, etwa im Rahmen einer Power-Automate-Beratung.

Häufige Fragen

Ab welchem Ausführungsvolumen sollte ich zu Logic Apps wechseln?

Eine feste Kennzahl nennt Microsoft nicht. Entscheidend ist laut Dokumentation eher das wiederkehrende Muster: Wenn Flows regelmäßig gegen Aktionslimits, Connector-Drosselung oder das Action-Burst-Limit von 100.000 Aktionen pro fünf Minuten laufen und Optimierungen daran nichts ändern, ist das ein starkes Signal für die Migration.

Werden Power-Automate-Flows automatisch nach Logic Apps konvertiert?

Nein. Microsoft beschreibt die Migration als manuellen Prozess: Die Workflow-Logik wird im Designer oder JSON-Editor von Logic Apps nachgebildet, Verbindungen zu Diensten wie SQL Server oder Azure Key Vault müssen neu eingerichtet werden. Eine automatische Ein-Klick-Konvertierung bietet Microsoft laut der offiziellen Migrationsdokumentation nicht an.

Kann ich Power Automate und Logic Apps parallel betreiben?

Ja, das ist sogar der übliche Weg. Sie müssen nicht alle Flows auf einmal migrieren. Sinnvoll ist es, zunächst nur die Workflows umzuziehen, die tatsächlich an Plattformgrenzen stoßen oder erhöhte Sicherheitsanforderungen haben, während einfachere Automatisierungen in Power Automate bleiben.

Was passiert mit einem Flow, der dauerhaft gedrosselt wird?

Laut Microsoft-Dokumentation deaktiviert Power Automate einen Cloud-Flow automatisch, wenn er 14 Tage in Folge durchgehend gedrosselt wurde. Der Flow lässt sich zwar wieder aktivieren, wird aber bei anhaltender Überlastung erneut abgeschaltet. Genau solche wiederkehrenden Deaktivierungen sind ein deutliches Signal, entweder eine Prozesslizenz zu erwerben oder die Migration zu Logic Apps zu prüfen.

Brauche ich für Logic Apps (Standard) ein eigenes Entwicklerteam?

In der Praxis ja, zumindest grundlegende Kenntnisse. Microsoft positioniert Logic Apps (Standard) ausdrücklich für professionelle Integratoren, Entwicklerinnen und IT-Administratoren, während Power Automate für Fachanwender ohne Entwicklungshintergrund gedacht ist. Wer produktiv mit Git-Versionierung, CI/CD-Pipelines und Infrastructure as Code arbeiten will, sollte entsprechende Ressourcen einplanen, bevor die Migration startet.

Weitere Details zu den einzelnen Migrationsschritten und zum vollständigen Funktionsvergleich finden Sie in der Microsoft-Dokumentation zur Power-Automate-Migration sowie in der Übersicht der Plattformgrenzen von Power Automate.