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.

  • What is the time lines here? Are you a customer or build a product on top of said vendor?
    – user1249
    Commented Feb 20, 2011 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
    Commented Feb 20, 2011 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
    Commented Feb 20, 2011 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
    Commented Feb 20, 2011 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
    Commented Feb 21, 2011 at 1:57

3 Answers 3


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.


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.

  • 2
    Interns: The local equivalent of outsourcing
    – Earlz
    Commented Feb 21, 2011 at 3:46
  • Internsourcing! Commented Feb 21, 2011 at 18:09

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.