Power Apps migration planning: the dependency checklist nobody gives you
Moving a Power App between environments or tenants is rarely hard because of the app. It is hard because of the eleven things the app quietly depends on, none of which appear in the export dialog. This is the list, in the order they bite.
LogiSam··9 min read
An app export is a .msapp inside a zip. It contains the screens, the formulas and the names of the data sources. It does not contain the data sources themselves, the credentials that reach them, the flows the app calls, or the fifteen places a maker typed a URL into a formula three years ago. Every one of those is a dependency, and every one has to exist — with the right name — in the destination before the app opens without an error.
1. Connections and who owns them
A canvas app outside a solution binds to connections, and a connection belongs to a person. If that person has left, the connection still works until its token expires, at which point every app bound to it stops. Before a migration, list every connection each app uses and the account it runs as. In the destination, those connections must be recreated by someone who will still be there in two years.
2. Connection references, and the flows that do not use them
Solution-aware apps and flows should bind through connection references, which are re-pointed once per environment on import. Flows that were built outside a solution and later added to one often still carry a direct connection, and will fail on import with a message that does not mention this. The fix is to convert them before export, not after.
3. Hard-coded URLs
https://contoso.sharepoint.com/sites/Finance/... in a formula. A Power BI tile embedded by report id. A Dataverse environment URL pasted into an HTTP action. None of these follow the app; all of them point back at the source after migration and work — silently — against the wrong tenant. Search every .msapp and every flow definition for the source hostnames before you move, and again after.
4. SQL statements and stored procedures
A flow with an *Execute a SQL query* or *Execute stored procedure* action depends on a database schema, not just a connection. If the procedure does not exist in the destination database, or has a different signature, the flow imports cleanly and fails at run time. Inventory the procedure names per flow and hand the list to whoever owns the database.
5. Flows triggered by the app
A Power Apps-triggered flow is a dependency in both directions: the app calls it by id, the flow expects the app's parameters. Migrate them together, in the same solution, or the app will call a flow that is not there.
6. Power BI integrations
Embedded tiles and reports reference a workspace and a report id in the source tenant. In a tenant-to-tenant migration those ids do not exist; in an environment move they usually do but the sharing does not. Find every Power BI reference and decide, per app, whether it moves, is re-pointed, or is dropped.
7. Dataverse tables, columns and option sets
Model-driven apps and solution-aware canvas apps depend on schema. Tables move in solutions; the rows do not. Custom option-set values must match exactly or forms load blank. Check that the destination solution carries every table the app touches, including the ones referenced only from a lookup.
8. Environment variables
The right way to hold a URL or a key — and still a dependency, because the *value* is set per environment. List them, and prepare the destination values before import so the first run does not use the defaults.
9. Custom connectors
A custom connector is an object in its own right, with its own authentication. It must be migrated first, because apps and flows reference it by id, and the destination id is new.
10. Sharing and security roles
Who can open the app is not part of the app. Export the sharing list — users, groups, roles — and apply it after import, or the migration is done and nobody can see the result.
11. The things that are not in any API
Desktop flow connections stored on a machine. A gateway that only exists on a server in the old datacentre. A Teams tab that points at the old app URL. These are found by asking the makers, and a migration plan should have a place to write the answers down against the app.
Keep reading
Why "no solution" is the most expensive answer in a Power Platform migration
Three hundred flows, none of them in a solution, all of them needed in the new tenant. Recreating them by hand is not a plan. Here is what the platform allows an administrator to do about it, and where the limits are.
Hard-coded URLs inside canvas apps: finding every SharePoint and Power BI reference before you move
The app imports cleanly. Every screen opens. And the document library link on screen four still points at the old tenant, because it was typed into a formula in 2022. Here is how to find those before the users do.
How to inventory an entire Microsoft 365 tenant's Power Platform estate in an afternoon
Every environment, every Power App, every Power Automate flow, every connection — the estate is all there, spread across four admin APIs that each refuse to describe the whole. Here is how to bring it into one list, and what to do about the parts Microsoft will not tell you.