Document Actions
Retiring a SaaS product?
My company provides SaaS with a twist. Since we serve enterprise customers, we allow them to stay on a previous version of our software until they go through their internal upgrade policy procedures (testing, UAT, communication, training, etc). Now, we are faced with having to support customers who are four or five releases behind. I know that this is not a typical situation for a pure SaaS provider, but how would you handle a sunset policy in this case? Would the policy be written in a format similar to traditional sunset policies, with just shorter time frames? I've got customers with no verbiage in their contracts regarding support for prior versions, and I need communicate our policy to them AND add contract verbiage for future customers.
Whether on-premise or on-demand, it's annoying to have customers more than a couple of releases behind. In some ways, it's evidence that the product isn't mission-critical, or at least, that they're not pushing it to its limits and so the old one works and why fix what ain't broke. But it is more difficult to maintain (for you) and becomes more difficult to convert (for them). I always upgrade at least every OTHER release even if I don't need the new features just to ensure that my data doesn't get left behind.
Microsoft has a 7 year policy for operating systems but apparently 10 years for business products. Read more at http://support.microsoft.com/gp/lifePolicy
Sometimes I wish we could have Y2K every five years or so just to force people to upgrade.
I think your "current release plus one back" policy is a good one. Perhaps it's fairer to say that we are maintaining the current release, supporting (but not updating) the prior release, and not supporting releases older than that. Alas, without a contract in place, you can't really enforce it and I cannot imagine any of your customers would agree to a new contract without some concession in another area. However, you should get the company to decide NOW and start adding verbiage to all future contracts.
Answered by Steve Johnson
