Most large organizations have IT change management processes sorted. The approval cycle, implementation, backout steps, review and closure form a fine-tuned machine with many moving parts. This is day-to-day stuff. You can’t manage a large infrastructure without having a structured, consistent approach to managing changes.


For others, their change management is more like the Post-it note chaos at the start of The Phoenix Project (once they’d moved past email storms and actually started using post-its). It’s like the crazy traffic around the Champs Elyse in Paris. I’m sure there are some rules in there somewhere and most people avoid hitting each other, but that’s more through good luck than good management.


With either scenario, someone within your organisation is the change initiator. They need to change an infrastructure component or application for a reason that will benefit your organization, whether it’s a new feature, a compliance request, a security patch or a network hardware upgrade. Even if a vendor is supplying the changed component, someone in your company has decided to run with it and implement it.


This isn’t always the case with your Software-as-a-Service (SaaS) products. And that frightens a lot of people. One of the main benefits of SaaS is the fact that you’re always being kept up to date. You’re no longer at the mercy of long release cycles, as the vendor can guarantee that the entire user base had applied the previous release, so everything works for everybody with just one more incremental upgrade. The downside is that you’re at the mercy of the vendor who will release changes whether you want them or not, whenever they want to.


There aren’t many SaaS companies that offer a ‘beta’ approach to their changes. Microsoft’s Office 365 platform does with their update channels. First Release lets you receive the changes before they go mainstream. so you can configure this for your IT team, your test labs and even a pilot group of early adopter power users. The Deferred Channel receives updates every four months instead of monthly. As an aside, they’ve introduced a similar concept to Windows 10 updates, including a Long Term Service Branch that doesn’t see updates for 1-3 years.


Applying this to the real world is going to involve some planning.

  • Who is going to be in the First Release group?
  • When are you going to schedule the testing of these changes?
  • What co-dependencies are there within your organization that will need to be tested against (eg what other systems rely on Word integration)?
  • Does the scheduling of any other changes to any other systems or infrastructure have an impact on the scheduling of your SaaS change testing?
  • Will the scheduled SaaS changes have any impact on other integrations you have with other SaaS products, particularly if there’s a change to their APIs?


If your SaaS provider doesn’t pre-release updates, then you really have to be on your game. Your best bet then is to stay notified of the product roadmap, so you know (as best you can) what’s coming up in the future and when. This might mean monitoring a blog or subscribing to a particular mailing list.


Remember, SaaS changes don’t just impact your systems, they can also impact your people. If an update changes a user interface, you might get some helpdesk calls. Make sure your helpdesk have seen the new interface or ‘what’s new’ splash screens too.


The relationship you have with your vendor is really important here. Hopefully you’ve established your change management needs during the buying process so you’re not caught out after implementation.


From another perspective, maybe your SaaS use isn’t that integral to your infrastructure after all? If it’s a bolt on product like Slack, do you really care what changes they make and when? Again, this assessment of the impact on your organization on future SaaS changes should have been addressed during the buying process. You might actually have assessed this and tagged it as a low risk.


There are a lot of considerations if you are adopting Software as a Service. We’ve explored a few things to watch out for and some tips to make your SaaS adoption a success, from an IT Operations perspective.


I’d love to hear your thoughts on what steps (if any) you’ve taken to include SaaS as part of your change management processes.