GOVERNANCE · April 15, 2026 · Updated November 6, 2026 · 6 min read

Before you migrate a SharePoint site, find every flow, app, and Teams tab that depends on it

app.migrationfox.com/governance/dependencies

Dependency Scan Results

contoso.sharepoint.com/sites/finance

23 ARTIFACTS FOUND

EXACT Flow Approve Expense > $500 env: Default-Contoso

EXACT Flow New Invoice → Approval chain env: Finance-Prod

EXACT Canvas App Finance Expense Tracker v4 owner: j.mehta

POSSIBLE Flow Weekly status digest SharePoint connection

HEURISTIC Flow Monthly budget reminder name matches site

EXACT Teams Tab Finance · General → Q4 Reports tab URL

… plus 17 more

Exact

Possible

Heuristic

Illustration · example output

Here is the script nobody wants to live through. On Friday you migrate a SharePoint site. The cutover is clean. Permissions replay, pages render, the document libraries are right. You close the ticket. Monday morning there are seven tickets open, all of them variations of “this thing that used to work is broken now.” You start digging. One is a Power Automate flow that fires when an item is added to a list that no longer lives at the URL the trigger was configured against. One is a canvas Power App whose data source connector is still pointed at the old site GUID. Two are Teams tabs that show Cannot load content because the tab was pinned to a SharePoint page at the old URL. One is an embedded Power BI report that references a SharePoint list as a datasource. Two are approval flows fired from library views that are now 404.

None of this was in your migration scope document. Nobody mentioned the flows. The person who built the app left two years ago. The Teams tab owner is on leave. You spend the next three days playing detective while the users are unhappy and the client is unhappier.

This is the silent breakage problem: the migration technically succeeded, but the project still failed. The migration tool does its job. Nobody told the tool about the flows, apps, and tabs quietly referring to the site’s URLs. The Power Platform Dependency Graph exists to surface them. Before you migrate, you scan. What the scanner finds shows up in one report, grouped by type. You decide what to update, what to rebuild, and what to warn the owner about. Then you migrate.

What the scanner actually looks for

The scanner lives at /governance/dependencies in MigrationFox. You give it one SharePoint site URL, and it checks three artifact types across your tenant:

Power Automate cloud flows. Flows are listed in each Power Platform environment through the Power Platform admin (BAP) API. Where an environment has Dataverse and the flow’s definition is stored there, the scanner reads the definition and extracts the site URL from each SharePoint action, so it can tell whether the flow targets this exact site. Otherwise it records that the flow uses a SharePoint connection.
Power Apps. Apps are listed through the same API. For each app the scanner reads its connection references and checks the app definition the API returns for a literal reference to the site URL. A SharePoint connection reference shows the app uses SharePoint; a URL match shows it uses this site.
Teams channel tabs. Through Microsoft Graph, the scanner reads the tabs in each team’s channels and flags any tab whose URL opens into the scanned site. SharePoint page, document library, and list tabs all carry the site URL.

Channel messages, SharePoint web parts, and Power BI datasets are not scanned. The full list of limits is at the end of this post.

Three artifact types scanned

⚙ Power Automate cloud flows BAP API · /flows

▢ Power Apps connection references

☷ Teams channel tabs Graph /teams

Match strength: exact, possible, heuristic

Not every reference is equally certain, so every finding carries one of three labels:

Exact: the scanner confirmed the artifact points at this site. A flow action whose site parameter is this site, an app definition that contains the site URL, or a Teams tab whose URL opens into the site. These break on migration unless they are updated.
Possible: the artifact uses a SharePoint connection, but the scanner could not confirm which site. Common for flows whose definition is not readable through Dataverse. Needs a human to look.
Heuristic: the flow or app name contains the site name, but no URL match was found. May or may not break. Worth a look, not a blocker.

The report shows a count for each label, so you can work through the exact rows first and then triage the rest. The scanner cannot run a flow to see the URL it builds at runtime, which is why the possible and heuristic labels exist: they tell you where a person needs to open the flow and check.

What the report shows

Findings are grouped by type (flows, apps, Teams tabs). Each row shows:

The artifact name
The owner (the flow creator or app owner; Teams tabs have no owner field)
The container: the Power Platform environment, or the team and channel for a tab
The match strength (exact / possible / heuristic)
A note explaining what tied the artifact to the site

The report also lists scan gaps, such as environments or teams that were not scanned, so you know what the result does not cover. You can download the full report as JSON, which also carries each flow and app’s last-modified date and a link to open it. Attach it to the change ticket and have the business owner sign off on the list of artifacts that will need to be repointed on cutover day.

How to use it

Open /governance/dependencies in MigrationFox.
Pick an app-registration connection to the tenant. The scanner reads every flow and app through the Power Platform admin APIs, which MigrationFox can only call as an app registration that holds the Power Platform Administrator role. Sign-in (“Sign in with Microsoft”) connections are refused for this tool. Everything the scanner does is read-only.
Paste the source SharePoint site URL, for example https://contoso.sharepoint.com/sites/finance.
Run the scan and review the report. Start with the exact rows.
Download the JSON and share the list with the business owner and the app owners. Track sign-off in your migration change ticket.
During cutover, repoint the listed flows and apps at the new site. For Teams tabs, update the tab or remove it and add it again pointing at the new URL.

What it does not do

Honest list, no vaporware:

Power BI datasets, Microsoft Forms, and Viva Connections cards. Not scanned.
Channel messages and SharePoint web parts. Not scanned. A link pasted into a conversation, or a web part on another site that points at this one, will not appear.
Desktop flows (Power Automate for desktop). Not scanned.
Logic Apps, Azure Functions, and custom code. Out of scope; they cannot be enumerated from the Power Platform admin APIs.
SharePoint Framework (SPFx) solutions. Not inspected for hardcoded URLs.
Flow run history. The report does not show when a flow last ran. Check run history in Power Automate before deciding a flow is abandoned.
Scan caps. The scan covers up to 20 Power Platform environments and 50 teams. Anything beyond that is listed as a scan gap.

A tool that hides its limits is worse than a tool that names them. You know what the scan covers and where you still need a human pass.

Why this matters for the migration contract

Fixed-price SharePoint migrations carry the silent-breakage risk on the delivery side. The contract says “migrate site X,” the client assumes everything downstream will keep working, and post-cutover breakage eats the margin. With a dependency report attached to the pre-migration change document, the client signs off on a concrete list of flows, apps, and tabs that will need updating, and those get scoped as separate line items.

The right sequence is: scan first, scope against the scan, migrate last. Flip that order and you are debugging flows on a Monday morning with users asking when their app will be back.

Get started

The Dependency Graph comes with the Tenant Suite or Consultant Pro; a single report pack does not include it. Prices are on the pricing page. Create an account at app.migrationfox.com/register.