Why Migrated Flows Look Different in PAD

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 variable scope 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 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 see variable prefixing docid\ lvidy2 rg7bpa9sjxzn4u for details on how variables are named and structured in output program flow 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 native vs custom actions 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 see setting up defaultrundotnetscriptreferences docid 821wzumakctteumhg9aat for details on net script configuration data types 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 selectors 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 generated subflows 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 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 see why blueprint creates multiple similar subflows docid\ jc8qf1mdzkqowh97uqukq for details on the subflow structure blueprint produces wrapper subflows 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 see wrapper subflows docid\ owgtiscydgxdqtk wpfcd for how these are structured and when they appear one to many conversions 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 ⓘ for a full list of what to review and complete after export, see preparing migrated flows for production docid\ h9qdcjgx34vunwjkdorns