From Orchestrator to Service Management Automation: Migration Scenarios

Service Management Automation (SMA) is the next gen IT Automation tool. SMA has some certain advantage over Orchestrator but also some limitations and vise versa. Nevertheless I am taking in consideration that you are aware of these advantages and limitations and you’ve decided to move fully or partially from SCO to SMA.

Before choosing any migration scenario it is good idea to create the connections, credentials, variables and schedules that you have in Orchestrator in SMA. Also import any PowerShell modules that you might need. That will be easier to execute any of the migration scenarios below.

These scenarios mostly apply if you have some portal like SharePoint or Service Manager Self-Service in front of Orchestrator and you’ve probably figured out what could be the possible migration scenarios from Orchestrator to SMA but let’s have a look at them:

  • Create runbook in SMA for every runbook you have in Orchestrator in a way that you will be able to call Orchestrator runbooks from SMA runbooks. Any new runbook develop in SMA. Switch your front end portal to call SMA web service instead of Orchestrator web service. Slowly make you Orchestrator runbooks SMA native runbooks.
  • Took one Orchestrator runbook, convert it to SMA runbook. Make the Orchestrator runbook just to call the SMA runbook. Repeat the process for every other Orchestrator runbook you have. Every new runbook develop in SMA. ON your front end portal switch from Orchestrator web service to SMA web service.
  • Develop any new runbooks in SMA. Wait for your Orchestrator runbooks to obsolete or migrate them in a future time. You can call the two web services (SCO or SMA) separately but I would recommend if possible to only use one web service.
  • Stop any new runbook development. Convert your Orchestrator runbooks to SMA runbooks. Test your SMA runbooks. Switch from Orchestrator to SMA on your front end portal. Develop new runbooks in SMA.

Keep in mind that the proposed scenarios are general and depending on your environment and runbooks the advantages and disadvantages of them will be different. What I recommend is to always keep only one web service that will be calling runbooks for front end portal. Also you may not be able to migrate all of your runbooks from Orchestrator to SMA as Orchestrator still makes a lot more sense in certain situations that SMA might not be able to cover well. If you are just starting with SMA I recommend to have a look at Service Management Automation Whitepaper by Michael Rüefli.

10 thoughts on “From Orchestrator to Service Management Automation: Migration Scenarios

  1. Bad Kitty

    Stanislav, it seems like you are suggesting almost everyone stop developing runbooks in Orchestrator immediately. Since SMA has no GUI, this seems like a tough process. I also saw Pete’s article on getting comfortable with PowerShell Workflow.

    It seems like the process of moving to SMA could be months or years if we include the time to update our skills and wait for the right opportunity to change out our self-service portal. No?

    Interested to here what you think.

  2. Stanislav Zhelyazkov Post author


    If you do not see any benefits of using SMA for you it is not necessary to migrate. You can still continue creating runbooks in Orchestrator and as I said Orchestrator still have a lot of sense in many cases.

    For those who are using heavily PowerShell in Orchestrator it will be more beneficial and easier to migrate some or all runbooks to SMA.

    What I am trying to say that you have a choice and you are not stuck to one solution only and you have the benefit of using Orchestrator and SMA in parallel and even collaborate them.

    The migration scenarios are general ones that you might face if you want to move to SMA now or in some later period.

    Learning PowerShell and PowerShell workflows it is not so hard and yes it can take months to master it but you shouldn’t be afraid so much just because SMA does not have advanced GUI. Keep in mind that SMA is it is in its first version and in future version may be it will be a lot more easier to develop SMA runbooks.

  3. Stuart Douglas

    After reading a bit about SMA, and tuning into SCU2014 and a really great session by Anders and Pete (thanks guys!), I’m sold on SMA as the automation tool of choice going forward. I do have one question, I presume there’s no data bus as with Orchestrator, so is the approach to saving important data elements for later use in the runbook to use variables, write them to a temp db, is there another/better way that’s recommended?

  4. Stanislav Zhelyazkov Post author

    Hi Stuart,

    Yes Pete’s and Anders’ session was great. Basically when you use the databaus in Orchestrator is when you want to get data from previous activity or when you want to forward data to another runbook. Yes SMA does not have databaus but when you write in PowerShell a typical job that can be achieved several Orchestrator activities can be achieved with several lines of code and in that code you do not require to pass data. Of course as Orchestrator, SMA can be used in a modular way. That means reusing existing runbooks by executing them from another runbook. This can be done in SMA and you just pass the needed parameters from the parent runbook to the child one by using variables. And if you return information from the child runbook to the parent runbook you output it. Check the whitepaper you will find that information with examples.

    Here is a good post on parent and child runbooks and what are the options:


  5. Tim

    Hey Stanislav, great article.

    Does this mean there is no mechanism to return data from an SMA runbook back to Orchestrator after execution?

    Or is it possible to return data via use of something like $result = start-smarunbook -etcetc etc etc, and have the SMA runbook output a value as the last action in its execution?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.