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.
StartBegin 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
DependenciesThe list is never what actually moves
A migration list is written by a person, and it is almost always a list of apps. That is not what moves. An app whose flow is left behind arrives in the target with a broken button, and nobody finds out until they open it.
- Flows each app calls, read from the app's own data sources
- Objects sharing a solution with something already selected
- Broken flow calls told apart from flows merely missing from the project
- Everything offered is listed before it is added — and can be ignored
SolutionsOne 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 referencesFind 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, and this reads it.
- SharePoint references, hardcoded URLs, SQL servers and bare GUIDs
- Or any text you type, matched literally across every app
- Results by app, file and line, with the surrounding formula
- Distinct targets listed, so forty hits on one site read as one site
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.
- Four stages per app: connections in dev, flows, UAT, production
- Filter to everything not started, or everything sitting in UAT
- A running total across the project, counted cumulatively
HandoverA workbook somebody works through
Not a report. An index sheet of every solution to create, then one tab per solution listing the objects to add to it, each row starting at Pending so progress can be tracked in the file itself.
- Excel workbook and PowerPoint deck of the whole plan
- One file per app and flow for a whole selection, zipped
- Solutions worklist with a status column to mark off
Plan your next migration on real data
Assess the tenant, import your list, and see what it actually depends on before anything moves.