8

How bad is it to use OpenDS, which is not actively maintained, and had the last patch in 2010, and require JDK6(which is also obsolete) in a production environment?(Although at the backend and not directly exposed to the end-users).

If it's already there, is it generally worth the time and money needed to find a replacement, run integration tests and such? What are common criteria for taking this step, regarding obsolete software in production in general?

masegaloeh
  • 17,978
  • 9
  • 56
  • 104
  • 4
    Good practice is to do a proper risk assessment on your individual situation. – HBruijn Jun 25 '14 at 18:27
  • 3
    In this specific case, wouldn't it be possible to migrate to OpenDJ, which is a fork of OpenDS and probably easy to migrate to? – ptman Jun 25 '14 at 19:06
  • 1
    Seconding. ForgeRock has a nice little [roadmap](https://wikis.forgerock.org/confluence/display/OPENDJ/OpenDJ+Roadmap) for OpenDJ, too. – Yolo Perdiem Jul 09 '14 at 15:52

1 Answers1

13

I suggest you evaluate this in terms of business/operational risk.

Using old, unsupported software often caries these potential risks.

  • No vendor support
  • No updates to bugs
  • No security patches
  • OS updates may be incompatible
  • Disaster recovery options may be limited.
  • Licensing issues can cause recovery/operational problems.
  • Inability to scale/expand operations based on this service.

The last two are often overlooked.

Years ago, I had a case where a customer was using legacy, proprietary MTA software. They secured a new major email marketing contract and needed to quickly ramp up their mail server farm.

They were unable to secure a license for their MTA. The MTA had certain features and an special API that integrated deeply into their email marketing platform.

We had to manually clone disks and put them into new more powerful servers to scale out the system. Spinning up new server would have made more sense but was not a workable solution due to the legacy software.

So if you don't plan to upgrade soon, you may need to assess the risks and at least have tentative plans on how to mitigate issues should they arise.

People often mention security. However, old software, provided it has no, known active exploits is inherently no more secure than a modern replacement.

The security risk is not that the software could be exploited but that you have no easy recourse if a security issues is identified.

Personally, I would rather upgrade some key component of operations in a planned manner than try to urgently engineer a new solution.

jeffatrackaid
  • 4,112
  • 18
  • 22