Q. Is there a tool to convert my Orchestrator Runbook to an Orchestrator SMA Runbook?
A. There is no tool that I know of that can perform this conversion. And, given the difference in the runbooks I think it unlikely such a tool would be very efficient if it existed.
Orchestrator Runbooks consist of one or more activities from Integration Packs that are linked together with various conditions to control the flow of execution using the runbook designer, which is a graphical tool allowing activities to be clicked and dragged onto the runbook canvas. A databus is also present that enables data to be leveraged between activities in the runbook. The Integration Packs themselves come from a number of different sources including built-in, from Microsoft, and from partners. Runbooks can be exported to an XML format.
Orchestrator SMA Runbooks are essentially PowerShell workflows that use the scription language's modules to enable additional functionality. PowerShell modules are sourced from various places including those built into the operating system, from Microsoft and from other vendors. PowerShell has a very rich set of functionality and logic flow. The workflow enables PowerShell execution to be checkpointed and resumed from a checkpoint in the event of a failure during execution.
I think the whole reason behind Orchestrator SMA was that vendors, and even teams in Microsoft ,did not want to have to maintain two separate "packs" of functionality to integrate with their technologies, an Integration Pack for Orchestrator, and a PowerShell module for PowerShell. Given the PowerShell module could be used in so many different scenarios such as CLI for live management and also in scripts/workflows for automations, it made sense for vendors to want to focus on PowerShell modules. Orchestrator SMA allows the PowerShell modules to be used as part of PowerShell workflows executed through the Orchestrator SMA engine.
Converting an Orchestrator runbook to a PowerShell workflow would be a complex activity in an Integration Pack and would have to be mapped to a specific cmdlet(s) in a PowerShell module. Logic would then need to be added to connect the various activities together, ascertain which data is required later in the execution flow, be saved to a variable, and also checkpoints positioned in the most optimal locations. Additionally even if such a conversion was possible, the generated PowerShell workflow would likely be unoptimized as there are very different capabilities in PowerShell. Additionally, trying to mirror an Orchestrator runbook in PowerShell would be "ugly".
My guidance at this point is this: use Orchestrator to implement as much functionality as possible using PowerShell via the Run .Net Script activity. This will aid in conversion to PowerShell workflows later. When the time comes to convert to a PowerShell workflow, map out the goals of the Orchestrator runbook, use it as a high level workflow from the steps required, then re-architect using the best practices and methods available in PowerShell.
