Migration

A plan that rebuilds itself from the estate

A migration plan written in a spreadsheet is out of date the day after it is written. This one is recomputed from the current assessment every time it opens: only the selection is stored, so the plan can never describe an estate that has moved on. What is stored alongside it is the thing a spreadsheet is actually good at — where each app has got to, and why it is stuck.

  • Objects moving, connections to recreate, premium connectors to licence and solutions to create or update
  • Stage tracking per app — Ready in Dev, Pushed to UAT, Passed, Failed, Pushed to Prod, Blocked
  • Notes and tags on each card, so “blocked on IT” is attached to the app rather than said in a meeting
  • Dependencies and risks computed across the whole plan, not per object
  • A read-only share link for people who should see the plan but not change it
Migration plan with objects moving, progress by stage, connections, premium connectors and solution counts
Migration plan with objects moving, progress by stage, connections, premium connectors and solution counts

Where every app has got to

Drag an app between columns. The stages are cumulative and ordered, which is the point: an app in production counts as having had its connections built and its UAT passed, so a progress figure cannot go backwards when somebody finishes something. Failed UAT sits at the same depth as UAT rather than beyond it — a failure is not progress — and blocked counts as nothing at all until it is cleared.

Kanban board of a migration with apps in Awaiting, Ready in Dev, Pushed to UAT, Passed and Failed columns
Kanban board of a migration with apps in Awaiting, Ready in Dev, Pushed to UAT, Passed and Failed columns

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.

Flows tab of a migration plan with trigger, connectors, actions and called-by columns
Flows tab of a migration plan with trigger, connectors, actions and called-by columns

Search inside the apps

Reads each canvas app’s package and looks in the actual source — where hardcoded URLs live and where no admin API can see. Five prepared searches for the things that break a move: SharePoint references, hardcoded URLs, SQL servers and databases, Power BI, and environment or object ids.

Search inside the apps dialog offering SharePoint references, hardcoded URLs, SQL servers, Power BI and object ids
Search inside the apps dialog offering SharePoint references, hardcoded URLs, SQL servers, Power BI and object ids

Take ownership of the whole plan

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 all twenty-four at once, so they appear in your maker portal — rather than twenty-four trips to PowerShell. The same menu exports a users-per-app CSV: owner plus everyone it is shared with, by email.

Tools menu on a migration plan offering to share all apps with the administrator and export users per app
Tools menu on a migration plan offering to share all apps with the administrator and export users per app

Every screen here is a live demo tenant

Contoso is sample data, generated rather than scanned — but it renders through exactly the same code as a real tenant, so what you walk around is what you would get.

Run it on your tenant
In the user manualMigrations(opens the Power Insights app in a new tab)

See it on your own tenant.

The free plan assesses a single environment for real — no trial countdown, no sample data.

Read-only · nothing installed · no card required

LogiSam Assistant Guided help & instant answers

Answers come from this website. Privacy policy

↑↓ to navigate ↵ to open