The right way to kill off near-dead hosted applications?

Question

When a hosted software application does have a paying user base (albeit a small one), but it's no longer profitable to maintain it, improve it, or support it, what's the "right way" to kill it off, and instead use that time/money to focus on your solutions that are working? What's the most professional way to do this?

Do you...

1. Simply notify the users of an end-support date (say 1 year out?) and wait for them to leave after?
2. Forcefully terminate the application on a certain date?
3. Refer and help users transition to another competitor's solution?
4. Open-source it?

Answer 1

It's not easy to answer the question without knowing what exactly you do. But nonetheless 1 and 3 would be very good options not to alienate users and keep a good reputation of the company afterward.

I have a suggestion. make it two stage:

a) Notify the users of support end date. As you suggested, one year. Whoever agrees to stop using it by the end of this date you offer help in migrating to alternative solution.

b) Notify the users of the shutdown of operation in two years from now. Whoever decides to stretch over support end date to use it until the end will have to arrange for migration on their own.

Answer 2

I would say that typically, depending on the nature of your application A combination of 1, 2, and 3 would be best.

First you start out by saying, "xyz will not be supported by our development teams after xxx". Then in the same communication let them know, "Additionally 6 months after the end of support date xyz will be taken offline" Lastly, give them a route to migrate to another solution. "We understand how important xyz is to you, and to help you continue to have a solution for ____ we have worked with yyyy to help create a migration plan..."

Following this approach you are going to be able to make a clean break, yes it will take effort, but you will put forth a good-faith effort to your users and should look good to the overall, even with discontinuing the service.

Answer 3

From what I've been seeing lately from the online community, when you kill off a project there are several acceptable options (you name them all) depending on your target audience.

Non-Technical Audience: 1 (preferable), 3 then 2 (not as friendly)

Technical Audience: 4 (as long as your source isn't going to be used for anything else proprietary).

Answer 4

I would work out the costs to make it profitable and give everyone notice that the cost are increasing. Give them an opportunity to cancel or accept. If they pay the additional cost then you're ok.

If they cancel/dont pay the extra costs then simply go with number 2, give them a reasonable notice period so they can get their data and move to another application. This will be cheaper and quicker for all concerned.

Answer 5

If you can do a combination of #1 and #4, that might work - announce that the service is going away on date X, and offer the code to anyone that wants to take it over. There might be someone out there that values the service enough to support it for free.

I suppose you've already determined the amount that each user would have to pay in order to make it worth your while to keep supporting them? You could offer that as option #5, I suppose.

Answer 6

Here's an answer more typical of a suit than a developer:

Lure them away with a better application!

Granted, you may not be able to do this, but if you can, think of the sweetness!

• Your customers are happy (and may be talked into paying more) with the shiny new buttons,
• you are happy because you can support shiny new code,
• your boss gets Dollar signs in his eyes and
• you get a hefty raise.

Well, one can always dream, no?

Answer 7

Unless there are extraordinary circumstances, option two (with a decent notice period). Why put any more effort into a service that isn't profitable?