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. None 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.
Seven 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. Every screen on this page is the Contoso demo tenant — sample data, rendered through exactly the same code as a real assessment.
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
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. Including the connectors an app never binds itself and only reaches through a flow.
- 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
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
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
Take ownership of the whole plan at once
Apps owned by people who have left are the standard blocker on any migration, and you cannot add an app to a solution you cannot open. One action makes you a co-owner of every app in the plan, so they appear in your maker portal — rather than twenty-four trips to PowerShell.
- Co-own every app in the plan from one labelled action
- A users-per-app CSV: owner plus everyone it is shared with, by email
- Each action reports exactly what it would do before it does it
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. The stages are cumulative and ordered, so a progress figure cannot go backwards when somebody finishes something.
- Awaiting, ready in dev, pushed to UAT, then passed, failed or blocked
- Notes and tags on each card, so “blocked on IT” is attached to the app rather than said in a meeting
- Failed UAT sits at the same depth as UAT — a failure is not progress
- A running total across the project, counted cumulatively
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
Two screens that decide the estimate
The flows that come with them
Every flow pulled in by the apps in the plan, with its trigger, connector count, action count and how many apps call it. The action count is the honest proxy for effort, and the “no solution” marks are the flows that will not travel with a solution export.
What one app is actually joined to
The app in the middle, what it reaches around it, and a line saying plainly whether it is in a solution. An app that is not carries each of its connectors as a separate thing to recreate by hand in the target.
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.