SaaS Blogs

One topic that is rarely addressed on blogs or in conversation is release management: the processes and science behind rolling out a new version of your SaaS offering. So imagine you’ve created the world’s next Salesforce.com: how do you plan on handling new releases? This question is stickier than it seems. There are a variety of operational decisions to make. At a minimum, you should ask yourself:

1. How often to I plan on releasing? Most companies I’ve spoken to about this have indicated monthly or bi-monthly (every two months, not twice a month) releases for bug fixes and basic functionality introducton, and larger scale “version releases” yearly. The decision of “how often” should be driven by a combination of customer needs and expectations coupled with feasibility. For example, if you are in the awkward position of managing an offering with features that have long development cycles (3-4 months), then don’t try and cram things into a single month simply to be on the monthly release bandwagon.
2. Do I offer a ‘preview release’? It isn’t uncommon to offer a subset of your customers (particularly the early adopter type) a sneak peek of a new version or giving them a pre-official release upgrade. This keeps early adopter customers happy and gives you the opportunity to get some critical feedback on your new features, but does introduce some logistics around multi-version support (see question #3).
3. Do I support multiple versions? This is a religious war in SaaS world. Some folks are adamant about one version and one version only, while others see it as critical to proper customer management. On one hand, supporting only a single version (i.e. migrating all customers to a new application version once released) simplifies a variety of tangential topics like support. On the other hand, single version releases may not play well with real world dynamics. For example, on a major release, large clients may request that they delay upgrading for a month or two with exposure to a “sandbox” upgrade of the new version, allowing them to train staff on new functionality prior to making that new version part of modus operandi.
4. Do I need a parallel release environment? Now that you’ve got 1-3 answered, how do you plan on actually cutting a new release? Are you going to maintain dual, matching environments and “cut over” or are you aiming at a patching mechanism that can physically roll out new bits over the old ones with rollback capabilities, or even trickier, will your versioning be meta driven allowing you to match customers to the appropriate version bits and coordinate this on a release management engine? Each of these approaches has different cost, risk, and implementation difficulty implications.

The questions I’ve posed are a small part of the many decisions to make during your release management planning. Other parts of defining a release strategy aren’t options, but required. For example, little things like when you migrate your customers to new bits, you should migrate their contracts in lock step. What does this mean? Well, if you’ve added functionality that you’re bundling for free in a subscription or have removed functionality from the application and are currently charging customers for that now removed functionality, update their contracts so they get the free stuff or so they are no longer paying for things that don’t exist! Little things like this are key to ensuring customer satisfaction and a hiccup-free release.

One last tip is automate! Look to automate this process in a way that is flexible but that keeps mistake-prone human hands out of the equation. This will be critical, regardless of what decisions you make above.

How do you feel about multiple versions? What tips do you have from the real world for ISVs planning a release management system for their SaaS offering? Have you encountered any unexpected headaches? Do share!

The SaaSBlogs group on LinkedIn now has 1100+ members and it’s growing every day; make sure you are not missing out and join today.