Your makers built outside solutions. Can you still see what depends on what?
Most of what gets built never goes into a solution. That is fine until it has to move. How to recover the dependency picture a solution would have given you, and decide what to package together.
Nobody decides to build outside a solution. You open the maker portal, you build the thing, and it lives in the environment directly. The solution conversation happens later, if it happens at all, and usually because something needs to move.
By then there is a department’s worth of work sitting loose in an environment — frequently the default one, which has no solution discipline by design — and the question on the table is the hardest one to answer from the outside: what depends on what?
What a solution would have told you
A solution is three things at once, and it is easy to only notice the first:
- A package. The unit that exports and imports. This is the one everybody knows.
- A boundary. A statement that these objects belong together and travel together. That statement is itself information, and it is the thing you lose.
- A rebinding mechanism. Connection references and environment variables, which exist so that a package can arrive somewhere else and be pointed at local credentials and local values at import time.
Objects built loose have none of the three. There is no package, no recorded statement about what belongs with what, and bindings that point directly at a connection with no indirection to rebind.
The boundary is the part you have to rebuild
The package is easy to create later. The boundary has to be reconstructed, and that means working out, for every loose object, what it is actually joined to.
For a single app that is a short list: the connectors it binds, the flows it calls, the tables it reads, the other apps it links to. For three hundred objects across eleven environments it is a graph, and graphs are not something people hold in their heads or recover from a spreadsheet.
The useful move is to stop asking about objects and start asking about the estate. Which connectors cross environments. Which custom connector three production environments quietly share. Which app is the only consumer of a flow somebody is about to delete.
Four questions that decide the packages
Once you can see the graph, the solution structure mostly falls out of it. The questions worth asking, in order:
- What must travel together? An app and the flows it calls. A flow and the tables it writes. Anything that would be broken by arriving separately goes in one package.
- What is shared? A flow called by four apps is not part of any one of them. Shared objects usually want their own solution, or everything that calls them ends up in the same one by accident.
- What already exists on the far side? Standard connectors, system solutions, Dataverse base tables. Excluding these is the difference between a plan with forty items on it and one with four hundred.
- What has to be built before anything lands? Custom connectors, premium licences, environment variables with target values. These are prerequisites, not migration items, and they belong at the top of the plan rather than in the middle.
Where estimates go wrong
Almost always in the same place: counting objects instead of counting the work.
“Three hundred flows” sounds like a large migration and tells you nothing. Three hundred flows inside twelve solutions is twelve exports. Three hundred flows in no solution is three hundred pieces of preparation before the first export, and that preparation is maker work on each object, performed by somebody who can open it — which loops back to ownership, because half the owners will have moved on.
The honest estimate needs three numbers that are not on anybody’s spreadsheet: how many solutions have to be created, how many existing ones need updating, and how many objects are loose and therefore have to be touched individually.
Do the packaging as its own piece of work
The temptation is to fold solution creation into the migration and discover the structure as you go. It never works, because the first export forces a decision about the boundary and you make it in a hurry.
Settle the structure first, against the real dependency graph, and write it down before anything is exported. A dry run that reports exactly what creating the solutions would do — writing nothing — is worth more than it sounds, because it turns the plan into something a second person can read and disagree with.
And then stop the estate drifting back
None of this is a one-off. An estate that was loose once will be loose again unless something changes, and the something is rarely a tool — it is an environment strategy with a place for makers to build, and a managed path for anything that becomes load-bearing. Microsoft’s environment strategy guidance is the right starting point, and Managed Environments gives you somewhere to enforce it.
The inventory is what tells you whether it is working.
Power Insights reports which objects are in no solution at all, draws the dependency map across environments, and proposes the solution structure a selection would need. Related: the three things that break every Power Platform migration.
