Can Power Insights move apps between tenants for me?

No. It plans the migration and produces the worklist; it never writes to either tenant. Solution creation exists as a dry run that reports exactly what it would do without doing it.

How does it know what an app depends on?

From the app's own data sources for the flows it calls, from Dataverse for solution membership, and — when you ask it to — from the app package itself for the exact addresses and any hardcoded references.

What happens to flows an app calls that are not in my list?

They are offered before they are added, and the plan distinguishes a flow that is merely missing from your selection from one that does not exist anywhere in the tenant, because those need opposite responses.

Can I track progress as the migration runs?

Yes. Each app moves through the pipeline — awaiting, ready in dev, pushed to UAT, then passed, failed or blocked — with filters and a running total across the project.

Migration

Move a Power Platform estate without discovering it in production

Plan the move from what the tenant actually contains — every dependency, every solution, and every hardcoded reference that would quietly point back at where it came from.

The list is never what actually moves

A migration list is written by a person, from memory or a spreadsheet, and it is almost always a list of apps. That is not what moves. An app that calls a flow which is left behind arrives in the target with a broken button. An app pulled out of a solution its siblings are still in arrives with connection references that rebind to nothing.

Neither failure shows up until somebody opens the app on the other side, which is usually the week after go-live and usually in front of the customer. The work is not the copying — it is knowing what has to travel together, and what is written inside each app that will not survive the journey.

Start

Begin with the list you already have

Upload the apps you intend to move and the project builds itself around them. Matching is by app id and environment name, never by display name, because two environments routinely hold apps called the same thing and matching on the name quietly moves the wrong one.

Import a spreadsheet, or pick from the estate
Anything that could not be matched is listed rather than dropped
The plan rebuilds from the current assessment every time it opens

Dependencies

Everything the selection quietly depends on

A migration list is written by a person, and it is almost always a list of apps. That is not what moves. Every connector the selection binds to, every connection behind it, and every flow an app calls — counted, and listed with what would break.

Connectors ranked by how many objects bind to them, premium and custom marked
Custom connectors flagged: they must be rebuilt in the target first
Connections listed with the account each authenticates as
Flows each app calls, read from the app's own data sources

Solutions

One solution per thing that has to travel together

What is already packaged, what has to be built, and what needs adding to a solution that exists — counted in solutions rather than objects. Default and system solutions are excluded, because they already exist on the far side.

Proposals grouped so objects that must move together do
Filters for in a solution, create, and needs updating
A dry run reporting exactly what creating them would do, writing nothing

Hidden references

Find what is hardcoded before it breaks

The admin APIs describe what an app is bound to. They say nothing about a SharePoint URL typed into a Patch(), or a source environment's hostname in a Launch(). Those live in the app's source — so every tool here reads the source, and every one of them exports.

Search app packages for SharePoint references, hardcoded URLs or any string
Find flow actions by kind, and the SQL server and database each step reaches
Power BI integrations: the connector, the data sources and the embedded tiles
Export any answer as Excel, CSV, the raw records or the untouched API payload

Tracking

Know where every app has got to

A migration runs for weeks. Somebody sets up connections in dev on Monday, somebody else pushes to UAT on Thursday, and what everyone needs on Friday is a list of which apps are where.

Awaiting, ready in dev, pushed to UAT, then passed, failed or blocked
Filter to everything not started, or everything sitting in UAT
A running total across the project, counted cumulatively
Every app named under the stage it has reached

Plan your next migration on real data

Assess the tenant, import your list, and see what it actually depends on before anything moves.

Start free Contact us All features