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.

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

Unmanaged developer environments are being deleted: what to do before 15 December 2026
On 15 December 2026 every unmanaged developer environment in your tenant is suspended, and a month later it is deleted. This is narrower than the "Managed Environments are now mandatory" version going around — and more urgent, because most administrators cannot say what is inside those environments.

"Move the solutions" assumes there is a solution: getting work out of a developer environment
The official guidance for saving a developer environment before 15 December is to enable Managed Environments on it or move the solutions out. Both assume the work is in a solution, and in a personal developer environment it usually is not. Here is what is actually involved, and the dependencies that break quietly rather than loudly.

Developer environment triage: let go, move, or convert
With a December deadline and a licence cost attached to every "keep it", this is a triage exercise rather than a migration. Three outcomes, the evidence each one needs, and how to sequence the middle pile so nothing lands in a target environment missing the flow it calls.