Migrate Power Automate Flows in SharePoint

What happens to Power Automate flows in a SharePoint migration?

Nothing happens to them, and that is the problem. A Power Automate flow is not stored in the SharePoint site. It lives in a Power Platform environment, under the account of the person who made it.

When you move a site, a library or a list, SharePoint content travels and the flows that watch it stay where they were. A flow that starts when a file is added still points at the old site address and the old list ID. In the new tenant there is no flow at all, and in the old tenant the flow keeps watching a site that nobody uses.

Most teams notice weeks later, when an approval email never arrives or a file stops moving to the right folder. By then the old tenant may already be closed. So a Power Automate flow needs its own line in the migration plan, next to permissions and metadata.

Which automations stay behind after a SharePoint move?

All of them, but they differ in how hard they are to bring back. Sort your inventory by this table before you plan any effort.

The last two rows are not a migration problem. They are a rebuild problem, and the section on replacing old workflows covers them.

Why do Power Automate flows break after migration?

Five things inside a flow point at the old environment, and every one fails in its own way.

The site address and the list or library ID come first. A SharePoint trigger or action names both, and the new site has a different address and new IDs. The flow does not fail loudly. It simply watches the wrong place.

Connections come second. A connection is tied to the account that signed in when the flow was made, so it has to be signed in again by an account in the new tenant. Connection references and environment variables, which Microsoft recommends adding to a solution, carry settings that may name the old tenant, and Microsoft suggests clearing environment variable values before export.

The owner is third. A flow belongs to the person who created it. If that person has no account in the target, the flow has no owner and nobody can edit it.

Fourth are the people and mailboxes inside the steps. An approval that goes to a manager or an email sent from a shared mailbox names an address that may not exist after the move. Fifth, a policy in the target tenant can block a connector your flow depends on, and the flow fails on import for a reason that has nothing to do with SharePoint.

Lists add a sixth case. A flow that reads a lookup or Person or Group field needs those fields rebuilt first, which is why the order matters. See how to migrate SharePoint lists and their columns before you repoint a flow at a moved list.

Which methods move a Power Automate flow?

There are three, and Microsoft points larger jobs toward solutions.

Microsoft's documented package route exports a flow as a .zip file from My flows and imports it into another environment. The importer needs the Environment Maker role there. The page does not cover another tenant, so test one flow before you commit to the method.

The solution route is cleaner. Publish the solution, export it as a file, and the flow definitions sit in a Workflows folder as readable JSON. A solution should contain the connection references, environment variables and tables the flow uses, so they travel together.

Neither method touches the SharePoint content, which is why the content move is a separate job. Our guide to the SharePoint Migration Tool limitations you hit in week one explains where Microsoft's own tool stops.

How do you migrate Power Automate flows step by step?

Do the inventory before anything moves. Steps one and two decide how long the rest takes.

1. List every flow. Record the owner, the trigger, the site and list it watches, the connectors it uses and whether it is on or off. Ask owners too, because personal flows do not show in an admin view of the site.
2. Mark what is still needed. Many flows were built for a project that ended. Retire those instead of moving them.
3. Add the flows to solutions. Group related flows so their connection references and environment variables travel together.
4. Move the SharePoint content first. The target site, library or list must exist before a flow can point at it. Lists need their lookups rebuilt before any flow reads them.
5. Match owners and mailboxes. Pair every owner, approver and shared mailbox with an account in the target tenant.
6. Export and import the flows. Use a solution for many flows and a package for a single one. Choose Create as new when the flow does not exist in the target.
7. Repoint the triggers and connections. Choose the new site address and list, sign every connection in again and fix any step that still names an old address.
8. Enable the flows one at a time. Switch the old flow off in the same hour, so the same file or item is never handled twice.

Permissions on the sites the flows touch follow their own track, described in how to migrate SharePoint permissions to another tenant. The wider order of work is in the Microsoft 365 migration planning checklist.

How do you replace old SharePoint workflows?

You rebuild them. There is no export for a SharePoint 2013 or 2010 workflow that produces a Power Automate flow.

Microsoft removed SharePoint 2013 workflows from existing tenants on 2 April 2026 and said there would be no extension. New tenants lost them in April 2024. SharePoint 2010 workflows went earlier, switched off for new tenants in August 2020 and removed from existing ones in November 2020. After the shutoff, Microsoft says a 2013 workflow can only be viewed as raw XML, so the definition is still readable even though it no longer works.

That readable definition is your specification. List the trigger, the conditions, the actions and the people it notified, then build the same logic as a cloud flow. Microsoft recommends Power Automate for workflow orchestration and Approvals in lists and libraries for simple sign off. It also offers the Microsoft 365 Assessment tool, which finds existing workflows and rates how easily they convert.

If a workflow was already dead before the move, say so in the plan. Moving the site does not revive it, and a migrated site that still carries a retired workflow gives users a button that does nothing.

How do you test Power Automate flows after migration?

Trigger every flow once with real data and read the result, because an enabled flow proves nothing.

Add a test file or item to the watched library or list and wait for the flow to fire. Open the history of the flow and read every step instead of looking at the green tick. Check that the approval email reaches the right person, that the file lands in the right folder and that the item is stamped with the right values. A flow that used to write to a Person or Group field is worth a second look, because that field is rebuilt rather than carried.

Then confirm the old flow is off. Two flows watching two copies of the same data create duplicate emails and duplicate files that look like a migration bug. Links people saved in the flow's emails point at the old site as well, a problem covered in what happens to SharePoint sharing links after migration. Teams without spare hands for the rebuild and test pass hand it to our cloud migration service.

Frequently asked questions

Where to start this week

Open the Power Automate admin view and count the flows that name your SharePoint sites.

That number is the real size of your automation job, and it is almost always larger than anyone guessed. Mark the ones still in use, give every flow an owner in the target tenant and decide which retired workflows get a replacement. A Power Automate flow you find now costs an hour. One you find after the old tenant closes costs a week.

Published 12 October 2026. Flow export and import steps come from Microsoft Learn pages on exporting and importing flows and exporting a solution. Retirement dates come from SharePoint 2013 workflow retirement.