--- title: Why Migrated Flows Look Different in PAD slug: blueprint/why-migrated-flows-look-different-in-pad docTags: yO7XZ9PJxDCKZ-Mf4TSYB createdAt: 2026-04-17T18:28:53.858Z --- :::CtaButton{label="🟢 Migrator" openInNewTab="false"} ::: After Blueprint exports your RPA processes, the resulting Power Automate Desktop (PAD) flows are functional — but they may look structurally different from what you'd write by hand. This is expected. PAD and legacy RPA platforms differ in how they handle variables, program flow, data types, and action availability, and Blueprint's output reflects those differences. This article explains the most common reasons migrated code looks different in PAD and describes the constructs Blueprint generates to bridge the gap. For the work required to make a migrated flow production ready, see [Preparing Migrated Flows for Production](docId\:h9QdCJGx34vUNwJKdORns). *** # Why Migrated Code Looks Different :::Heading{depth="2" indent="1"} Variable Scope ::: :::Paragraph{indent="1"} Legacy RPA platforms typically support global variables shared across an entire automation. Users can choose whether or not to migrate PAD flows with local variables in the export wizard. ::: :::Paragraph{indent="1"} If export with local variables was not used Blueprint resolves this by declaring all variables in an **Init\_Variables** subflow that runs at the start of every flow, making them accessible across the full execution context. Blueprint also prefixes variable names per subflow so that variables originating in different subflows cannot collide or overwrite one another. This increases verbosity. If your organization is not concerned with collisions, variable prefixing can be toggled off in the Export Wizard. ::: :::Paragraph{indent="1"} See [Variable Prefixing](docId\:LvIdY2-rg7Bpa9SJxzn4u) for details on how variables are named and structured in output. ::: :::Heading{depth="2" indent="1"} Program Flow ::: :::Paragraph{indent="1"} PAD does not natively support constructs like GoTo, nested loops with complex exit conditions, or some exception-handling patterns common in legacy platforms. Where direct equivalents aren't available, Blueprint uses PAD **Labels** and **Go To** actions to replicate the original logic as faithfully as possible. ::: :::Heading{depth="2" indent="1"} Native vs. Custom Actions ::: :::Paragraph{indent="1"} Not every legacy RPA action has a direct PAD equivalent. Blueprint maps actions to PAD's native library where possible. When no native equivalent exists, it uses custom actions — or, for platform-specific functionality, generates .NET scripts to replicate the behavior. ::: :::Paragraph{indent="1"} See [Setting up defaultRunDotNetScriptReferences](docId:821WZUMAkctTeuMhG9AAt) for details on .NET script configuration. ::: :::Heading{depth="2" indent="1"} Data Types ::: :::Paragraph{indent="1"} PAD's type system differs from most legacy platforms. Blueprint applies conversion logic to map source data types to PAD-compatible equivalents. Some conversions are straightforward; others require intermediate handling that adds steps to the output flow. ::: :::Heading{depth="2" indent="1"} Selectors ::: :::Paragraph{indent="1"} UI automation selectors are platform-specific and cannot be automatically translated. Selectors from UiPath, Blue Prism, and A360 will require manual review and updating in PAD after migration. See [Preparing Migrated Flows for Production](docId\:h9QdCJGx34vUNwJKdORns) for how to approach this. ::: # What Blueprint Generates :::Heading{depth="2" indent="1"} Generated Subflows ::: :::Paragraph{indent="1"} Blueprint structures output into multiple subflows rather than a single flat flow. This mirrors the Call Tree of the original automation — each subprocess or reusable component becomes a discrete subflow in PAD. ::: :::Paragraph{indent="1"} One exception: by default, Blueprint inlines subflows that are called only once or are very short, so those appear embedded within their parent flow rather than as separate subflows. This is configurable — set **Call or Embed Settings** to **Call Everything** in the Export Wizard to keep all subflows discrete. ::: :::Paragraph{indent="1"} See [Why Blueprint Creates Multiple Similar Subflows](docId\:JC8QF1MDzKQoWH97UQuKQ) for details on the subflow structure Blueprint produces. ::: :::Heading{depth="2" indent="1"} Wrapper Subflows ::: :::Paragraph{indent="1"} For processes that call reusable components shared across multiple automations, Blueprint generates wrapper subflows that act as adapters between the calling flow and the exported reusable component. ::: :::Paragraph{indent="1"} See [Wrapper Subflows](docId\:OwgtiSCydgXdqtK-wPfCD) for how these are structured and when they appear. ::: :::Heading{depth="2" indent="1"} One-to-Many Conversions ::: :::Paragraph{indent="1"} Some single legacy actions expand into multiple PAD actions in output. This occurs when the source action has no direct PAD equivalent and the logic must be decomposed into sequential steps. Blueprint targets functional equivalence, not identical code — migrated flows should do what the original bot did, even where the code looks different. ::: # Platform-Specific Differences Certain behaviors in migrated output are specific to the source RPA tool. See the platform-specific articles for details relevant to your migration: - [UiPath to PAD Migration Output](docId\:a1SaJvHomibEEbIS4uKja) - [Blue Prism to PAD Migration Output](docId\:pOlzB8a7GNKtos_VFwDtw) - [A360 to PAD Migration Output](docId\:rTsN23d7rQ8lI-RAVDpLJ) - [Setting up SAP for RPA](docId\:xhCkz1-XIjZPRT2e--VIY) :::hint{type="info"} ⓘ For a full list of what to review and complete after export, see [Preparing Migrated Flows for Production](docId\:h9QdCJGx34vUNwJKdORns). :::