Enterprise software upgrades – three words that strike fear into the heart of any sysadmin running complex applications, or applications that have not been upgraded in a while.

At Signiant, we are big proponents of SaaS as a deployment model. So much so we even made a video all about this (starring yours truly!).

As Director of DevOps at Signiant, my job is to make sure our SaaS solutions always just work for our customers. A big part of this is seamlessly rolling out new features to users without them having to deal with the upgrade process themselves. They just get the new features, automatically.

But internally we still have a few third-party applications that we run on-premises, either because the vendor’s product has no SaaS option, or because we have not gotten around to migrating to it yet.

I was recently involved in upgrading an issue tracking application that had not been kept up to date (its last upgrade was 2013), and it really helped reinforce for me one of the key benefits of SaaS: “managed upgrades”.

Here’s a quick summary of the upgrade process for this on-premises enterprise application:

Upgrade process for on-prem application:

• Check release number currently running (6.1.1) and compare with latest (7.4.0)
• Read release notes for each release between the major releases
• Read about new and changed functionality in the new release
• Check compatibility (databases, Operating System, etc.)
• Setup a new staging/test server to test the upgrade migration process
• Find that version of MySql is incompatible – find upgrade instructions
• Upgrade MySql, hope other applications using the database still work
• Install existing version of application on new server
• Upgrade it to v6.4
• Upgrade it to v7.4
• Find out we missed a step in the upgrade so go back to the beginning
• Re-run upgrade to 6.4
• Add upgrade to 7.0
• Upgrade to 7.4
• Tune database connection parameters
• Add more memory to server for new resource requirements
• Discover required external add-ons / plugins are no longer compatible with new version
• Find alternatives to add-ons / plugins
• Find any custom integrations that use new version and update them
• After success in test environment, schedule maintenance window for cut over
• Perform upgrade and migration during maintenance window
• Rollback due to upgrade failure
• Speak to vendor support and analyse failure
• Re-run all steps in test environment with working procedure
• Schedule new maintenance window
• Run production upgrade

Now here is what the corresponding upgrade would look like if this were a SaaS hosted application, such as Media Shuttle:

Upgrade process if this were SaaS hosted:

• Open browser
• Login to application
• Marvel at new functionality before my eyes

Love the SaaS.  Be the SaaS

I’ve been fortunate at Signiant to work in many different roles, one of which was managing our technical support team.  In support, we only saw a small window into major upgrades of enterprise software but I have a new appreciation for just how involved major upgrades of enterprise software packages can be.

Now that I’m working in the DevOps role and responsible for working with our engineering teams to make sure our upgrades are seamless and automated for our cloud hosted solutions, I find that I take the SaaS model for granted sometimes.  We’ve worked hard at Signiant to make sure that while we do upgrades very frequently (some more complicated than others), our customers just get to enjoy all the new functionality we’re adding to our cloud platforms, without any of the hassle of upgrading the solution themselves.  While I like the challenge of making complex systems work, it’s been a real eye-opener into just how complex and time consuming upgrades of enterprise software can be.