Engineering Support for Older Releases

One of the perennial causes of customer escalations and general discontent is the level of Engineering support for older releases (well, the level of Engineering support for current releases is also a problem, but that’s another story for another day!) The issue is sometimes a simple lack of awareness of the service-level agreement, Many customers, having installed a version recently, automatically assume that it’s supported since it’s new to them. The other, much more difficult problem is that customers often find the standard rules impractical for the way they run their business.

So what is the standard practice for Engineering support? There are lots of variations but most vendor provide technical support for the latest release and the one immediately preceding it, and Engineering support (that is, bug fixes) only for the current release. So if the latest version is 3.2, technical support would be available for 3.2 and 2.11 (assuming 2.11 is the last version for the 2.x releases) and Engineering support would be available for 3.2 only. If a bug is uncovered in version 2.11, the customer will be encouraged to upgrade to 3.2 where the bug may not exist at all or will be fixed.

In addition, most vendors provide a guaranteed timeframe for support. So if release 3.3 comes around technical support continues to be provided for 3.2 for a year or two. Similarly there should be a grace period for Engineering support on 2.11, say for a year after release 3 becomes available. Typically you can restrict the severity level for fixing bugs on older releases, fixing only the most severe defects.

As you can see, the details can become very convoluted. The wise vendor maintains a support matrix that clearly shows those releases that enjoy full support (technical and Engineering) versus technical support only, versus none at all.

The actual length of the support period should be determined by your customers’ needs. Complex systems, lengthy upgrade processes, regulated industries, and larger customers all suggest a need to lengthen the support period. In some environments you may need to commit to delivering support for 10 years on each version.

Should you offer support beyond the contractual agreement for an additional fee? Perhaps. You can certainly charge more to support older versions but the issue is one of staffing: can you afford to maintain staff that’s knowledgeable about older releases, especially for bug fixes? Often the answer is no and it’s not possible to offer the service at a practical price point.

Besides building the support lifecycle to match customers needs you should also work closely with customers to ensure that they are indeed using supported releases and to encourage them to upgrade if they are not. It’s very difficult to force an upgrade in the middle of a crisis, especially if the customer feels it’s all your fault, and magically creating bug fixes on an older release is very painful.