Following our latest Friday Fact, where we highlighted that moving Logic Apps Consumption between resource groups does not update internal workflow references, there’s another critical detail to consider.
When you manage Logic Apps Consumption in Azure, you’ll eventually need to move them between resource groups. This usually happens when governance models change, environments require separation, or subscriptions need consolidation.
The unnoticed behavior
At first glance, this process seems simple. The Azure portal lets you move resources between resource groups with just a few clicks. However, here’s the catch: while Azure moves the Logic App itself, it does not move the associated API connections.
📝 One-Minute Brief
Moving a Logic Apps Consumption workflow to another resource group does not move its API connections. This Friday Fact explains why connections remain in the original resource group, the hidden risks this creates, and what teams must plan when reorganizing Azure resources.
This is one of those platform behaviors that can easily go unnoticed until it creates operational issues. Let’s break it down.
In a Logic App Consumption, every connection you configure — whether it’s to SQL, Service Bus, SharePoint, Outlook, or any other system — is represented as a distinct Azure resource of type Microsoft.Web/connections. These connection resources reside in the Resource Group where they were created and are referenced by their absolute resource IDs within the workflow definition.
So what happens if you decide to move your Logic App to another Resource Group?
- The Logic App workflow resource itself will move.
- But the
Microsoft.Web/connectionsresources will remain behind in the original Resource Group. - The workflow definition will still point to those original connections, which means your Logic App now straddles two Resource Groups: the workflow in one, the connections in another.
At first, everything may look fine. The Logic App continues to run, and the designer shows the connections are valid. But under the hood, you now have a hidden dependency on another Resource Group.
Potential issues with this behavior
However, this creates several potential issues:
- Risk of accidental deletion: If someone deletes the old Resource Group, your Logic App in the new RG will immediately fail because its connections are gone.
- Governance misalignment: Cost tracking, tagging, RBAC, and policies become fragmented across multiple Resource Groups, reducing clarity and increasing management overhead.
- Auditing and troubleshooting complexity: To fully understand a workflow’s dependencies, you must jump between Resource Groups, which is error-prone and time-consuming.
Best Practices to keep in mind
- Always plan moves as a set: Include both Logic App workflows and their API Connections in your migration plan.
- Recreate connections in the target Resource Group: Use ARM/Bicep/Terraform to redeploy connections alongside the Logic App.
- Keep resources co-located: For clarity, governance, and lifecycle management, store Logic Apps and their connections in the same Resource Group.
- Validate before cleanup: Never delete a Resource Group until you’ve confirmed no Logic Apps elsewhere still depend on its connections.
Combined with the previous Friday Fact, this paints a clear picture: moving Logic Apps Consumption resources in Azure is not a simple drag‑and‑drop operation. Logic Apps store absolute references to both internal workflows and external API connections. As a result, moving them without careful planning can create hidden dependencies and fragile integrations that break later and are hard to detect.
Too lazy to read? We’ve got you covered! Check out our video version of this content!
If you liked the content or found it helpful and want to support my work, consider purchasing—or helping purchase—a Star Wars Lego set for my son.
