Move a Power Platform estate without discovering it in production.
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.
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. Neither of the failures below shows up until somebody opens the app on the other side.
The app that calls a flow left behind
It arrives in the target with a broken button, and nobody notices until somebody presses it — usually the week after go-live, usually in front of the customer.
The app pulled out of its solution
Its siblings stay behind, and it arrives with connection references that rebind to nothing. Valid-looking, and wrong.
The hostname nobody searched for
A source-environment URL typed into a Launch() keeps pointing at where it came from — quietly, successfully, for months.
Six stages, from your list to sign-off
Every stage rebuilds from the current assessment, so a plan opened in week six is a plan of the estate as it is in week six.
- 1
Start 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 — 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
- 2
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
- 3
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
- 4
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 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
- 5
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
- 6
Send the plan to the people who must agree it
A read-only link that opens the same plan through the same screens, with no account needed and no access to anything else. Email addresses and the accounts connections authenticate as are withheld.
- An expiry date and a view count on the project
- Revoke the link at any time
- The same component as the live plan, so the two cannot drift
The moves this is built around
Tenant to tenant
A merger, an acquisition or a divestment, where the target tenant has none of the connectors, connections or solutions the apps assume.
Default to managed
Pulling production work out of the default environment into something governed, without breaking the dependencies nobody documented.
Dev to UAT to live
Standing up a real ALM path for apps that were built straight into production, with the solution structure worked out first.
Plan your next migration on real data.
Assess the tenant, import your list, and see what it actually depends on before anything moves.
Read-only · nothing installed · the plan writes nothing to your tenant
More on Power Insights
Every page of the Power Insights sub-site, and the way back to the rest of LogiSam.