Microsoft have published a tool to help us migrate service level agreements (SLAs) created in the old web client to the newer style SLAs we find in the Unified Interface. In this blog post I will explain what is involved.

If you aren’t aware of the update to Service Level Agreements you can read this post, in which I describe how we create the new style SLAs. The two types are very similar but the new ones created in the Unified Interface make use of Power Automate. As the existing web client is reaching end of life you may need to migrate your old style SLAs to the new format.

Note:
In this post I am going to focus on SLAs but you should be aware that automatic record creation rules are also applicable here. As they have also been updated in a similar way.

I actually feel that I’m well placed to review this tool. As I have migrated SLAs for two customers now. The first time the migration tool wasn’t available so we recreated the SLAs manually. In this example I have opted to use the tool. Therefore at the end of this post I can compare my experiences of the two approaches.

Within the customer service hub we can access the service management area. And here you should find the “ARC & SLA Migration Tool” option under the heading of Data Management. (I’ve shown a screen shot below to try and make this easy to find!)

Notice that I have no automatic creation rules. But I do have 3 service level agreements that are pending, as these have been created in the web client and not migrated to the new Unified Interface.

Note:
I actually had 4 SLAs! It seems that only active SLAs are included. I had a fourth in a draft state which was ignored. (I was ok with that as I didn’t need the draft one!)

There is a really useful link on this page to a step-by-step guide on the migration process. I suggest you read this before starting. It explains that the migration is a six step process.

Step one – “Category to migrate”, allows you to pick which type of rules to migrate.

Step two – “Pre-migration check-up”, details any potential issues before you begin.

Step three – “Rules and items to migrate”, allows you to select the rules you want to migrate.

Step four – “Review”, gives you chance to review (and fix) any issues before starting the migration.

Step five – “Migration”, the actual migration!

Step six – “Finish”, a summary of the rules migrated.

Step One – Category to migrate

Here you can select to migrate your service level agreements and or your automatic record creation rules. I only have SLAs, so I used that option.

Step Two – Pre-migration check-up

Next your SLAs will be checked and hopefully passed. You may need to review and fix any failures.

Lucky for me none of my rules failed. Which was nice!

But from what I can see if you do get any fails I think the errors will be clearly described and will possibly also a link to FAQs to help you diagnose the issue.

Note:
Actually I had no errors but as I will explain later I did have a few issues to resolve!

Step Three – Rules and items to migrate

Step three lets to decide which rules to migrate. Simply click on any SLAs that you don’t want to migrate.

In my case I just selected my “Bronze SLA”. As in my first attempt I decided to migrate just one SLA. Once I knew that had worked I would return to the others!

I did try the download all logs option. It gave me some additional detail on what was going to be migrated. As all my SLAs had passed the checks I didn’t gain much by doing this. But I assume this will be an essential step if you have any errors!

Step Four – Review

This step is actually just a chance for you to double check everything before committing to the migration!

Check you have the right rule listed and click “Start migration”.

Step Five – Migration

Having clicked start migration you get a friendly message saying that the process won’t take long.

And for once I can confirm that the process is pretty quick. It took just a few seconds to migrate my rule.

Step Six – Finish

As you can see below my migration finished. And migrated one SLA successfully.

Afterwards you can see that I have migrated one rule. And 2 are pending, as I opted to only migrate one of my three rules.

My End Results

It is important to know that the migration process does not touch your existing rules. They will still be active.

Note:
Automatic creation rules differ as they are active as soon as the migration completes.

Below you can see my new rule. Notice that all of the SLA KPI items have been migrated for me. Also notice that the SLA is in a draft state.

After I have checked out the details I will need to deactivate my old rule and activate my new one.

You may have noticed that we also have a “Migration details” tab. In my simple example my SLA migrated successfully. But you could have a partial failure. Maybe it couldn’t convert specific failure or success actions fully. You can try to resolve any issues in the web client version and repeat the migration. Or you may opt to fix the issue in this newly created SLA. If you correct the issue in this SLA, I believe you can then mark the migration as complete. To avoid doing it again.

“Unfortunately” my migration worked perfectly, so I didn’t get to experience this scenario! If you aren’t as “unlucky” as me then you can check these FAQs which list a number of known issues.

My Problems!

So I did speak too soon …. I did have some issues to resolve.

When I came to activate my SLA I received a business process error message. On deeper investigation I found that some of the Flows which had been created for my SLA steps were off. So I needed to check each one and turn them on before activating my SLA. They were off as they couldn’t activate due to errors!

In doing this I found a few differences between the migrated SLA and my original.

In my example (as may be common) the failure actions sent out emails to flag any SLA breaches. I found that the body of my emails didn’t migrate correctly. So I had to recreate those.

But once completed the Flows could be turned on and my SLA activated.

In my specific example the body of the email contained some html code, I suspect that was the root cause of my issue meaning I had to manually recreate the information in the description fields of the emails. (Which wasn’t a big deal really!)

Below you can see that when I looked at the Power Automate Flows which are created two were initially off.

Conclusion

As I explained at the beginning, I have now migrated two customers to the new style SLAs. As in both situation I adopted a different approach I feel well placed to comment on this migration tool.

This new approach was quicker initially, as the definition of the SLA KPI items migrated easily. But I did have to fault find some issues with the resulting Power Automates. So it wasn’t a perfect solution. I guess most people may also have to review and fix some issues with their Flows.

I guess my examples was pretty simple. Meaning I could probably have created new SLAs from scratch with a fairly small amount of effort. If you only have a small number of SLAs maybe re-creating new ones from scratch may prove to be the simpler approach.

I had just three SLAs to migrate but what if I’d had tens or even hundreds of SLAs? Well then using the migration tool would have become a no brainer. So despite my problems I do think this is a useful tool that I would use again. Enjoy.