Supporting sunsetted products

Is it possible to provide support for a product that is no longer supported by Engineering? And is it possible to charge for that support?

Yes and yes — with caveats.

Normally, for an active product, a support contract provides assistance with questions and troubleshooting, fixes for at least major issues, and periodic maintenance releases. The commitment also extends to continuing to support the product for either a set period of time or until a number of new releases become available. Customers are sometimes happy to upgrade to new releases if new releases are consistently more stable than older ones or if they contain interesting new functionality, but for many customers the cost and uncertainty of upgrading makes them wish to remain on older releases. In other cases it’s the vendor that decides to “sunset” a product. In either case, the Support organization has a choice to provide support, or not, for a product that’s no longer active from a development perspective.

1. Plan ahead. The worst circumstances to make a decision on how far to go to help a customer is when the customer is in trouble — and the Engineering team is nowhere to be found. Have a game plan and communicate clearly with customers ahead of emergencies to avoid painful escalations.

2. Explore the limitations of restricted support. It’s true that most customer requests are not associated with bugs, and it’s also true that customers running older releases are less likely to be making production changes, hence to create new problems, but the possibility of discovering a new bug on an older product is not nil. What will you do then? Also you may rely on the Engineering team to deliver troubleshooting assistance, not just fixes. Would you be able to conduct troubleshooting without help? Finally, customers are likely to run into problems with the surrounding environment: will the old release work if they have to upgrade the operating system? the database?

 

 

3. Be honest with the limitations within Support. Providing support for a slightly-old release is fairly easy since the staff remembers it well, but after several years it can become more challenging as turnover makes experienced staff rare and reproduction environment disappear. If you want to continue to provide support on older releases you should expect to beef up the knowledge base and the reproduction environment. It’s not just “free money.”

4. Make case-by case decisions. If an older release is relatively problem-free, has an adequate base of customers wanting to remain with it (meaning enough of a revenue base), and there are no compelling reasons to upgrade to the next release, you have a good candidate for extended support. Otherwise, you should probably say no. Ideally there can be a transition period during which minimal Engineering assistance is available for troubleshooting and the most critical fixes, after which time you can plunge into support-only mode.

5. Archive the older release code. You never know!

6. Communicate clearly. Customers that are running older products need to understand exactly what they are paying for. In particular, if absolutely no fixes are available, they need to understand the need for careful testing of any changes. It may be wise to schedule a conference with the customer to ensure that the special terms of the support-only contract are well understood.

7. Enforce the SLA. If a customer chooses to remain on release 5 after it’s officially sunsetted (support only, no fixes), be prepared for some constructive discussions the nesxt time she finds a bug. It’s important to carefully refer back to the agreement and encourage either a migration to the current release or a workaround rather than caving in to a fix.

8. You can charge more (for less, as it were…) Customers who want to remain on older releases may be prepared to pay a premium to avoid upgrade costs, and they should understand that, although the vendor is no longer required to create fixes, there are real costs associated with supporting older releases in terms of people, reproduction environments, and the costs of supporting a small numebr of customers. You can increase the cost by a fraction each year that passes to reflect that fact. (And I would never offer such support for less than normal maintenance rates.)

Bottom line: it’s absolutely possible to provide “support only” maintenance contract, without fixes, and you can charge a premium for support beyond the normal period, but beware of having to provide suppor tn older products when your staff is no longer familiar with them.