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.

Power Platform migrations move solutions. A solution is the unit of export and import; it carries apps, flows, tables, connection references and environment variables together, and it is the only thing that carries them between tenants. An app or flow that is not in a solution can be exported on its own — one at a time, through a different dialog — but the result does not import into a solution, does not use connection references, and has to be re-shared and re-bound by hand.
How estates end up outside solutions
Makers build in the default environment, from a blank canvas, because that is what the portal offers first. Solutions are a step that has to be chosen. In a tenant that grew from the bottom up, the proportion of flows outside any solution is routinely above half, and the ones outside are, on average, older and more business-critical than the ones inside.
Finding them
Solution membership is not in the Flow API. It is in Dataverse's solutioncomponents, and cloud flows appear there with component type 29, keyed by the flow's workflowidunique. A flow with no row in that table is a non-solution flow. Count those per environment before quoting a migration timeline.
What an administrator can do about it
The Power Platform admin PowerShell module has Add-AdminFlowsToSolution, which calls the same endpoint the maker portal uses when a maker chooses *Add to solution*: the environment's migrateFlows operation, taking a solution id and a batch of flow names. It moves a non-solution flow into the solution in place — the flow keeps its id, its runs and its connections — and it works on flows the administrator has never been shared on.
- It processes in batches; twenty at a time is a safe size against throttling.
- It needs the destination solution to exist first, with a publisher.
- It reports per flow, and the failure messages are worth reading: a flow can be refused because it is already in another unmanaged solution, or because it is not a cloud flow at all.
What it cannot do
Desktop flows are not eligible — they live only in Dataverse, and asking migrateFlows to move one returns FlowNotSupported. Add them to the solution directly through AddSolutionComponent instead. Canvas apps are added the same way, with component type 300, and model-driven apps with type 80. And converting a flow does not convert its connections into connection references; that remains a per-flow edit in the designer, or an accepted limitation that the import wizard will re-bind.
The order that works
- 1Create the solution with a publisher you control.
- 2Add apps and desktop flows as components.
- 3Convert the cloud flows in batches; collect the refusals.
- 4Fix the refusals — usually a flow already in another solution, which needs removing there first.
- 5Export.
Keep reading

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.

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.