14

When a vendor declares that they no longer intend to provide any support or services to a piece of software (and stated the intent to exit the business - offering no upgrade paths), what kind of recourse is available to the customer?

Please consider this from the customer's viewpoint. The customer's IT staff will likely only consider the technical options, but there are likely non-technical options which the customer can pursue as well. Also, what kind of reasonable steps can be taken by the customer ahead of time to minimize disruption, such as in contract terms?

Things I can think of:

  • Need to purchase spare hardware and set up a spare environment on which the software can continue to operate.
  • Various data export methods which do not require vendor involvement. (This can include trivial techniques such as examining the data stored in a commodity database backend, to the more involved techniques such as screen scraping, printing to image followed by re-scanning, etc)
  • Parallel systems where staff will duplicate the old data into a new system manually or semi-automatically
  • Legal means, in case the vendor is in financial trouble (as in the case of source code escrow)

Any other ideas?

  • Assuming that there is no "circumvention" involved (no DRM, no DMCA), is data recovery or reverse engineering legal/acceptable?

Edited note:

It is a combination of several anecdotal, but real stories. I am not directly involved in any of those. It is simply my desire to learn about how "software end-of-life" situation is handled in general. It is not my intention to make the original story sound like too "difficult" to be solved.

Jonas
  • 14,867
  • 9
  • 69
  • 102
rwong
  • 16,695
  • 3
  • 33
  • 81
  • What is the time lines here? Are you a customer or build a product on top of said vendor? –  Feb 20 '11 at 15:24
  • 3
    You can try to purchase source code from the vendor then support yourself? This is a pretty difficult situation to be in. – btilly Feb 20 '11 at 15:55
  • 2
    Makes one wonder why the data has not been stored in some sort of open format to begin with ... if it is stored as plain text in db, you can copy it. If it is stored in xml / plain text, then you can copy it. If it is binary/encrypted, then you need to crack it. It is all doable. – Job Feb 20 '11 at 17:08
  • 3
    @Job: agreed. The importance of open/simple storage format (and the concept of "vendor lock-in") has been recognized for more than a decade. Decisions made several decades ago would not have this benefit of hindsight. Back then, affluent customers went with the market leaders irrespective of cost, and less-affluent customers had to accept the status quo or take the risk. – rwong Feb 20 '11 at 18:42
  • These sorts of stories serve as good examples as to why it is good to have data exit plans. That can be using open formats as @rwong suggests, but that should also mean having export clauses in contracts. – smithco Feb 21 '11 at 01:57
  • Is it a software service or purchased software? If purchased software that the company has now installed for themselves, they can just keep using it - not optimal, but I have known companies to keep using software well past end of life like this. – sevenseacat Feb 21 '11 at 04:55

3 Answers3

2

One strategy that is not on your list is to bring on a team of interns and give them the summer to figure it out. Since it would likely be a one-off project, it won't matter if the code is pretty, if takes a lot of hours or if it just takes a lot of manual data entry.

smithco
  • 1,207
  • 7
  • 6
2

Reverse Engineering is pefectly acceptable on your own data. Assuming you have the database files to begin with. If its a hosted service, you may be better off just paying the fee and having them export the data. imo, its extremely rude and unprofessional of them to require a fee for that, but some people dont care about such things.

Since you know this application is something you need, perhaps if its feasable, its time for an in-house developed system? This way you wont end up in this situation again.

GrandmasterB
  • 37,990
  • 7
  • 78
  • 131
0

If the product is something you do not require changes to, do not foresee requiring changes to and runs on your own hardware there is always the option of accepting the risk to keep using it.

It isn't fancy, and it can be a pain, but depending on the product and the vendor you might find if you think about it that the situation is no different than it was when the vendor technically supported it.

One note: If the system is something exposed to the public then this is a bad approach because you have no way to get security updates applied.

Bill
  • 8,330
  • 24
  • 52