Completing PAD Code Post-Migration

completing pad code post migration migrated flows are not production ready out of the box platform differences between legacy rpa tools and power automate desktop mean code completion work is always required after export this article explains what to expect in your output and what you'll need to address manually what to expect in migrated output functional equivalence, not identical code blueprint aims for functional equivalence — migrated flows should do what the original bot did, but the code will look different one source action may expand into multiple pad actions to preserve the intended behavior this is by design extra variables pad does not support variable scoping to simulate scope and prevent collisions, blueprint adds subflow specific prefixes to variable names this increases verbosity but ensures variables from one subflow don't override those in another if your organization isn't concerned with variable collisions, variable prefixing can be toggled off in the export wizard see variable prefixing docid\ lvidy2 rg7bpa9sjxzn4u for configuration options extra code blueprint adds code beyond the core logic to preserve functionality across platforms this includes net scripts — used when no native pad action (or combination of actions) can replicate source behavior without being overly verbose or complex optional code — todo comments, regions, and logging are included by default; toggle these off in migration preferences if your organization doesn't need them duplicate subflows pad's lack of variable scoping can result in what appear to be duplicate subflows the logic is the same, but parameters differ to prevent variable collisions blueprint continues to optimize subflow reuse with each release data type conversions pad handles variable typing at runtime and supports a specific set of data types blueprint maps or converts others as needed lists → converted to pad datatables via asenumerable support xml payloads → handled via native xmldocument support what you'll need to fix manually todos and compiler errors todos and compiler errors make up the bulk of post migration completion work resolving these is required before a flow can run selectors resolving todos and compiler errors alone does not make a bot production ready selectors must also be reviewed and tested blueprint cannot validate selector efficacy during migration because it does not have access to your target applications ⓘ if you encounter selector issues in migrated flows, contact blueprint support or your success manager custom actions and libraries blueprint migrates standard actions only for custom actions and libraries, rules can be configured to define how blueprint handles them during export if processes or subflows appear missing by default, blueprint inlines subflows that are called only once or are very short — they won't appear as separate flows in output if you believe logic is missing verify your selections in the export wizard check the rpaimportlog in your project folder for import failures — failures are listed at the top use bulk reimport/recalculate to force a fresh migration of specific processes in export wizard options , change call or embed settings from system recommended to call everything to prevent inlining and keep all subflows discrete