Moving apps and flows to another tenant: do you know everything that travels with them?
A migration list is a list of apps. What actually moves is a graph. The six classes of dependency that come with a Power Platform estate, including the one that never appears on an app’s own connector list.
Every cross-tenant migration starts with a spreadsheet of apps. Somebody exports it from the admin centre, somebody else adds a column for the business owner, and that becomes the scope.
It is a reasonable place to start and a terrible place to stop, because a list of apps is a list of nodes and what you are actually moving is a graph.
Six things come with an app, and only one is on the list
In rough order of how often they are forgotten:
1. The flows it calls
An app that calls a flow and arrives without it has a button that does nothing. The failure is silent — the screen renders, the control is there, the press produces an error the user reports as “it’s broken” three weeks later.
2. The connectors behind both
Standard connectors exist in the target tenant already. Premium ones exist too, but they carry a licensing requirement that has to be satisfied before anybody can run the thing. Custom connectors do not exist at all until somebody builds them, and they do not come along inside a solution export the way people expect.
3. The connections, and the identities behind them
A connection is a credential. It does not migrate — it gets recreated on the other side, as somebody, and the question of whom is one of the few genuinely consequential decisions in a migration. A production process authenticating as a named individual in the source tenant should not quietly become the same arrangement in the target.
4. Solution membership
Solutions are the unit of transport. An app pulled out of a solution its siblings are still in arrives with references that rebind to nothing. Solution membership is itself a dependency, and it does not appear on any list of app names.
5. Dataverse schema
Tables, columns and relationships the apps and flows read or write. Managed solutions carry this; anything built loose does not.
6. The connectors reached only through a called flow
This is the one that catches careful people. An app binds four connectors. It also calls two flows, and those flows bind connectors the app never touches. Open the app’s own connector list and you see four. Move the app and its flows and you need seven.
No per-object view surfaces that, because it is not a property of any single object — it is a property of the path between them.
Why the graph has to be computed, not remembered
Any dependency list written by a person is a snapshot of what that person knew on the day they wrote it. A Power Platform estate is not static: makers ship, flows get added, somebody rebinds a data source on a Tuesday. By week four of a migration the spreadsheet and the estate are two different documents.
The useful version of a migration plan stores only the selection — these apps — and recomputes everything derived from it every time it is opened. Then a plan opened in week six is a plan of the estate as it is in week six, and the question “is this list still right?” stops being asked.
What to count, and in what units
Estimates go wrong because people count the wrong things. A few that are worth counting properly:
- Solutions, not objects. Ten apps in one solution is one package to move. Ten apps in no solution is ten pieces of preparation before anything can move at all.
- Actions, not flows. A three-step flow and a ninety-step flow are both “a flow”. If anything has to be rebuilt by hand, the action count is the only honest proxy for the work.
- Custom connectors, individually. Each one is a build in the target, usually with a backend host that also has to be reachable from the new tenant, and usually with nobody left who wrote it.
- Connections, by identity. Not “forty connections” but “forty connections across eleven accounts, four of which belong to people who have left”.
Then the part no graph can answer
Everything above is structure, and structure is discoverable. What is not discoverable from the relationships is what somebody typed inside the apps — a source-tenant SharePoint URL in a formula, an environment id in a deep link, a Power BI report that lives in a workspace nobody is moving.
Those have to be read out of the app source, and they belong on the same checklist. An app that imports cleanly and points at the tenant you just left is the most expensive outcome available, because it looks like success.
We wrote that up separately: what is hard-coded inside your fifty Power Apps.
The order that actually works
- Inventory the source tenant — every environment, not the ones you were told about.
- Take the list of apps and let the dependency graph grow it into the real scope.
- Resolve ownership before anything else, because you cannot package an app you cannot open.
- Decide the solution structure — what must travel together — and build the packages.
- Search the app source for anything pointing back at where it came from.
- Stand up what has to exist first in the target: custom connectors, premium licences, Dataverse schema.
- Then move something, and track every app through its stages so the status is a list rather than a meeting.
Steps one, two, four and five are an afternoon of reading if the inventory exists, and a fortnight of archaeology if it does not. That is the whole argument for assessing the tenant before planning the move.
Power Insights migration planning computes the dependency graph from a selection of apps, including the connectors reached only through a called flow, and keeps the plan current against the estate.
