Why "no solution" is the most expensive answer in a Power Platform migration

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

1. 1Create the solution with a publisher you control.
2. 2Add apps and desktop flows as components.
3. 3Convert the cloud flows in batches; collect the refusals.
4. 4Fix the refusals — usually a flow already in another solution, which needs removing there first.
5. 5Export.