Migrating Hundreds of Power Automate Flows Between Tenants Without Breaking Connections

Why does exporting and importing flows between tenants break the connections?

A flow definition and its connections are two different things. The definition is the trigger, the actions and the expressions, and it exports cleanly. A connection is an authorised session between a connector and an account, created by a person or a service identity in one tenant and stored against that environment. It is not part of the export, and it could not work in another tenant even if it were, because the account it was authorised with does not exist there.

So a flow that was exported as a legacy package and imported somewhere else arrives with every connector asking to be reconnected, one flow at a time, in the import screen. That is survivable for ten flows. For several hundred it becomes weeks of clicking, done by whoever happens to be signed in, which quietly makes that person the owner of the connections behind the whole estate. That is the same key person problem that breaks flows when an employee leaves, now created deliberately on the busiest week of the project. How to avoid it for a single leaver is on our Power Automate consulting page; a tenant migration is the same problem for every flow at once.

Microsoft also documents an administrator led route for moving whole environments between tenants in some scenarios. Check current Microsoft documentation for what it moves, what it leaves behind and whether it fits your licensing and regions. Even where it applies, connections still have to be recreated in the target tenant, so the connection work on this page does not go away.

What else in a flow is tied to the old tenant besides its connections?

Reconnecting is the visible part. The failures that reach the business after go live usually come from values inside the flow definition that were correct in the old tenant and are silently wrong in the new one. Search every definition for these before you estimate anything.

How do you inventory hundreds of flows with the Power Platform CLI and PowerShell?

Do not start from the maker portal. Start from a spreadsheet that a script produced, so the inventory can be re-run on the day before cutover and compared with the first one. The admin PowerShell modules for Power Apps and Power Automate return flows and connections across environments for an administrator, and the Power Platform CLI lists environments and solutions and exports them. Exact cmdlet and command parameters change between versions, so check the current reference before you script against them. The pac commands themselves, and how they pair, are explained in our guide to Power Platform ALM with the PAC CLI, so this page only lists what the inventory must capture.

• Every environment in the source tenant, including the default environment, where personal flows in My flows are easy to miss.
• Every cloud flow and desktop flow with its environment, owner, co-owners, state, trigger type and whether it is already in a solution.
• Last successful run and recent run count, so flows nobody has used can be retired instead of migrated.
• Every connection with its connector, the account that created it and its status, joined to the flows that use it.
• The tenant bound values from the table above, found by searching exported definitions for site addresses, identifiers, email domains and HTTP triggers.
• A business owner and a criticality rating per flow, which no script can produce and which someone in each department has to confirm.
• A decision per flow: retire, migrate as is, migrate with changes, or rebuild.

How do you batch flows into solutions for a tenant migration?

Solutions are what make several hundred flows movable in a controlled way. A solution aware flow uses connection references instead of embedding a connection, so on import you map each reference once rather than reconnecting every action in every flow. A flow created outside a solution can be added to one, but it may keep its embedded connections until its actions are switched to connection references, so check each one rather than assuming the add did the work.

Batch by dependency and by owner, not alphabetically. A batch is a set of flows that share connections, depend on the same SharePoint sites or Dataverse tables, and can be tested and switched over by one business owner together. Parents and child flows go in the same batch. Keep batches small enough that one failed smoke test does not hold back unrelated processes, and big enough that the connection mapping is worth scripting. Retired flows stay behind, exported as a backup and documented, so nobody asks for them in six months.

How do you pre-create connections in the target tenant and map connection references on import?

Create the connections before the first import, signed in as the identities that will own them in production, never as the engineer running the migration. For connectors that accept a service principal, such as Dataverse, use one. Many everyday connectors, including SharePoint, Office 365 Outlook, Teams and Approvals, work through a user context and need a dedicated, licensed service account instead. The trade offs between the two, and how connection ownership fails later, are covered on our Power Automate consulting page. Check current Microsoft documentation for which connectors support which authentication, because it changes.

Then generate a deployment settings file for each solution. It lists every connection reference and environment variable in the solution; you fill in the identifier of the pre-created connection for each reference and the target value for each variable, and pass the file to the import. The importing identity must have access to the connections it maps, which is why sharing them with the pipeline or service identity is part of the preparation. Generating and using the settings file is the same mechanism we describe for promotion between environments in the ALM and PAC CLI guide; in a tenant migration you fill it with target tenant values once per batch.

Prepare the rest of the target tenant in the same pass: licences for the service accounts and for any premium connector use, data loss prevention policies that allow the connectors the flows need, gateways, app registrations and the environment variables' target values. A DLP policy in the new tenant that groups connectors differently will suspend flows that imported perfectly.

How do you smoke test each batch before it goes live?

Import the batch with its flows turned off, then prove each one works before anything depends on it. A smoke test is short and specific: it shows that the trigger fires, that every connection authenticates, and that the flow writes to the right place in the new tenant, not that the whole business process is correct.

• Confirm the import mapped every connection reference and that no flow shows a connection error or a suspended state.
• Check environment variables resolved to target tenant values, not the source values the solution was exported with.
• Trigger each flow once with a test record, message or file that the business owner has agreed, in a test site, list or mailbox where one exists.
• Read the run history for each action, including branches that only run on errors, rather than trusting a green run.
• Verify the output where it landed: the row, the file, the email, the Teams message, the call to the external system.
• For scheduled flows, run them manually once and check they will not reprocess data the source tenant already handled.
• Record the result per flow with the tester and the date, so the cutover decision is evidence rather than memory.

How do you sequence the cutover so nothing critical runs unverified?

Use the low risk batches to prove the method and the most critical batches to use it. The first batch should be internal notifications and reports that nobody loses money over if they are late for a day. By the time payroll, invoicing, order intake or compliance flows move, the connection mapping, the settings files and the smoke test have already worked several times.

For each batch, set a switch moment agreed with the business owner. Turn the source flow off and the target flow on at that moment, never both at once, because two tenants processing the same schedule or the same external trigger will double send and double post. Keep the source flows exported and the source tenant readable until the batch has run through a full business cycle, including a month end for finance processes, so rolling back is turning one flow off and another on again rather than a rebuild. Flows whose runs wait for days, such as long approvals, need a decision: let in-flight runs finish in the source tenant before switching, or cancel and restart them in the target.

Once a migrated process runs at full volume, expect limits you did not hit before, especially where a new service identity now carries work that was spread across several people. The design fixes are in our guide to Power Automate 429 throttling at scale.

• Batch 0: inventory, target tenant preparation, gateways, identities and a pilot import of two or three trivial flows.
• Low criticality batches: notifications, reminders and reporting flows, to prove the method end to end.
• Medium criticality batches: departmental processes with a business owner available to test on the day.
• High criticality batches: finance, payroll, customer facing and compliance flows, each on its own switch moment with rollback agreed.
• Hypercare: daily review of failed runs in the target tenant until every process has completed a full business cycle.
• Decommission: source flows turned off permanently, exported definitions archived, then the source tenant closed on its own schedule.

How long does migrating a few hundred flows take with one engineer?

There is no honest single number, because the effort depends on how many flows are already in solutions and how many hardcode tenant specific values. What we can give is the arithmetic we use to plan, with the assumptions stated, so you can replace them with the figures from your own inventory. The per flow hours below are planning assumptions for this worked example, not measured averages.

Take 300 flows, one experienced engineer and a target tenant whose SharePoint, Teams and users are migrated by other teams on their own plan. Assume a quarter of the inventory is retired, leaving about 225 to move. Assume most of those are simple, with standard connectors and no hardcoded identifiers, at under an hour each including the smoke test; a large minority need identifiers moved into environment variables and a fix or two, at a few hours each; and a small number are complex, with custom connectors, gateways, child flows or external callers, at a day or more each. Worked through, that is roughly eight to twelve weeks of batch work. Add two to four weeks for inventory, business owner confirmation and target tenant preparation before the first batch, and two to four weeks of hypercare through a business cycle after the last one.

On those assumptions one engineer should plan for roughly three to five months end to end. The range moves more with waiting than with work: a SharePoint migration that lands late, business owners who are not available to test, or app registrations and licences that take weeks to approve. A second engineer shortens the batch work, not the waiting, so the cheapest way to protect a hard date is to start the inventory and the target tenant preparation early.

Should you run the migration yourselves, and when is moving the flow the wrong answer?

Run it yourselves if you have an engineer who already works with solutions, connection references and the admin tooling, and who can be taken off other work for the duration. Bring in help when the date is fixed and nobody has done it before, or when the inventory turns up a large estate of personal flows with no owner. Senior consultants and full-stack developers at Solzet deliver this as a defined engagement, remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly or white-label for Microsoft partners.

A tenant migration is also the cheapest moment to stop carrying flows that should not exist. Retire what nobody uses, rebuild the few that were fragile before the move, and question whether a process belongs on the platform at all. We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. Where the automation surrounds a system that sits outside the Microsoft estate and the new tenant's licensing is the obstacle, a custom-built CRM or back office application on React, Node.js, PostgreSQL or .NET is the alternative we build. The wider flow work, including takeover and monitoring after the move, sits in our Power Automate consulting service.