Following our latest Friday Fact, where we highlighted that moving Logic Apps Consumption between Resource Groups does not update the internal workflow references, there is another equally vital detail to keep in mind. When you’re managing Logic Apps Consumption in Azure, sooner or later, you’ll encounter a common scenario: the need to move your Logic Apps between Resource Groups. This might happen because your governance model changes, you need to separate production from test, or you’re consolidating resources under a new subscription strategy.
At first glance, this seems straightforward. Azure Portal even allows you to move resources between Resource Groups with just a few clicks. But here’s the catch: while the Logic App itself moves, its API Connections do not automatically move with it.
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.
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.
This, combined with the previous Friday Fact, paints a clear picture: moving Logic Apps Consumption resources in Azure is not “just about dragging and dropping them into a new Resource Group”. Because Logic Apps store absolute references to both internal workflows and external API Connections, moving them without careful planning can leave you with invisible dependencies and brittle integrations.
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 would like to support me in writing more, you can consider purchasing (or helping to purchase) a Star Wars Lego set for my son.
