Hard-coded URLs inside canvas apps: finding every SharePoint and Power BI reference before you move
The app imports cleanly. Every screen opens. And the document library link on screen four still points at the old tenant, because it was typed into a formula in 2022. Here is how to find those before the users do.
LogiSam··6 min read
A canvas app's data sources are declared, and a migration re-points them. Its formulas are not, and a formula can contain anything a maker typed: a Launch("https://contoso.sharepoint.com/..."), an HTML control with an embedded report, an image URL to a site that will not exist. These references are correct in the source tenant, and they stay correct — for the source tenant — after every migration.
What is in the package
An exported app is a zip containing a .msapp, which is itself a zip. Inside are the screens as JSON (or as YAML in the newer format), the data-source definitions, the connection references and the resources. Everything a maker wrote is in there in clear text. Unpack both layers and you can search it like any other text.
What to search for
- Your SharePoint hostnames —
contoso.sharepoint.com, and the-myvariant for OneDrive. - Power BI —
app.powerbi.com,reportId,groupId, and thePowerBItile control's properties. - Dataverse environment URLs —
*.crm*.dynamics.com, typed into HTTP actions and hyperlinks. - Internal hostnames and IP addresses — the on-premises API that the gateway reaches.
- Email addresses and display names — hard-coded approvers.
Flows too
A flow definition is JSON, and it is where the worst offenders live: HTTP actions with a full URL, Send an HTTP request to SharePoint with a site address typed in, SQL actions naming a server. The V2 flow listing omits the definition, so each flow needs a direct read; solution-aware flows sometimes return only a summary and the full definition has to come from Dataverse's clientdata.
Triage
Not every hit is a problem. A link to a public Microsoft docs page is fine. Group the findings per app and per flow, mark each one *re-point*, *leave* or *remove*, and put the decision where the person doing the migration will see it — on the app's card, not in a spreadsheet nobody opens. Then search again after import against the destination hostnames, and expect the count to be zero.
Keep reading
Power Apps migration planning: the dependency checklist nobody gives you
Moving a Power App between environments or tenants is rarely hard because of the app. It is hard because of the eleven things the app quietly depends on, none of which appear in the export dialog. This is the list, in the order they bite.
Why "no solution" is the most expensive answer in a Power Platform migration
Three hundred flows, none of them in a solution, all of them needed in the new tenant. Recreating them by hand is not a plan. Here is what the platform allows an administrator to do about it, and where the limits are.
How to inventory an entire Microsoft 365 tenant's Power Platform estate in an afternoon
Every environment, every Power App, every Power Automate flow, every connection — the estate is all there, spread across four admin APIs that each refuse to describe the whole. Here is how to bring it into one list, and what to do about the parts Microsoft will not tell you.