Click to learn more about author Matt Yonkovit.
Databases play a critical role in our applications – after all, no one ever talks about their services using less data today. However, like applications, databases require ongoing management and regular updates. At some point, the database version you use will reach its End of Life (EOL). This is not uncommon – for example, MySQL version 5.6 reached EOL in February 2021, and MongoDB version 3.6 hits EOL in April 2021. It’s not just the world of open source either – Oracle 18c faces the end of error correction and security patching on June 30, 2021, and no extended support options will be available. If this happens to your database version, you need to ensure you have a plan in place.
If your database version reaches EOL, there will be no further functionality or security updates, and users will be encouraged to move to newer versions. Moving can turn out to be a large project, especially if you are now multiple versions behind on your updates. So, how can you reduce your risks, improve your approach to handling data, and ensure your services carry on as normal?
What’s Your Situation?
When it comes to EOL, you should start by recognizing why you have reached this point in the first place. Is this due to an application not needing to be updated in order to work? Did upgrading slip down the priority list? Is there a specific reason why you can’t move off your database?
If you can’t move, this is usually because you need something particular in order for your application to continue working as intended. Often, this is because a component supports only a specific database version, or has not itself been updated. Up until now, a migration may have been viewed as an unnecessary risk, but with EOL coming up, you may no longer have a choice.
If your application is not critical, it’s easy to put back making updates in favor of leaving things as they are. “Don’t fix what isn’t broken” is a common IT motto. However, you can’t afford to ignore database EOL dates.
What to Do Next?
If you find yourself in this position, it is important to go through your options, and consider what to do next.
The first option is, paradoxically, to do nothing. This might sound like an odd suggestion after saying that you should not ignore the problem, but these two things are not the same. Making an informed choice to carry on with an existing database instance is a different scenario to thoughtlessly maintaining the status quo. This approach is best suited to noncritical applications, where the data is not sensitive, and where other controls can be implemented for security.
In this scenario, it is worth looking at extended support options for database instances. This will fill some of the gaps that might occur over time after the EOL date passes, and provide a roadmap with the necessary steps you should take to mitigate security issues if a fault is discovered.
The second option is to carry out a migration. This will involve moving from the EOL database edition to one that has support now and in the future. Depending on how long you want to plan ahead, along with your application compatibility concerns, this could be a point upgrade or a move to the latest version. For example, companies dealing with MySQL v5.6 have the option to move to v5.7 or v8.0. Moving to 5.7 is a smaller change, but this version moves to EOL in October 2023. Depending on how long you intend to carry on using the application and database, and the amount of work the migration will be, moving to v8.0 may be less costly in the long run.
In this scenario, you should carry out compatibility testing. This will show you how well your application will work with the new database version and allow you to identify potential issues. You need to allow plenty of time to carry out thorough testing ahead of the EOL date, just in case there are problems. Doing this just before the cutoff date can cause stress. Alongside this testing, you should also carry out some backups, just in case you need to restore a previous version of the database on the existing systems.
The third option is the most radical – rip things up and start again. This involves not just looking at a database update, but also considering whether you are using the right database in the first place. This scenario is best suited to mission-critical applications where any downtime leads to lost revenues, and where updates have been put off to avoid risk.
Projects like this are more common in environments where change is viewed as a substantial risk to production and revenues. Examples include the supply chain, manufacturing, and utilities sectors, where applications have to be available around the clock and margins are tight. These critical applications can have strong uptime, so turning them off for updates is a risk. Those upgrades then pile up over time until they cannot be put off any longer.
In this situation, an EOL status means no other organization is responsible if something goes wrong. The impact of a problem – and the expense of cleaning it up afterward – would be far larger than the cost of a well-planned migration. In these cases, you should work on a strong cost-benefit analysis, and position this as a beneficial change for business stakeholders over time. In circumstances like this, EOL can act as a positive force, necessitating cautious companies to make long-term, forward-looking, constructive changes.
The Road Ahead
EOL situations are a fact of life for IT professionals – they affect every asset over time. Planning ahead for these situations is crucial, whatever your current circumstances.
Whatever EOL approach you take, there are steps you can put in place to ensure that your data remains safe and secure, applications carry on working, and users are not affected. From making migrations work, through to compensating controls and additional security measures, your implementations should carry on functioning well, and providing the results you need. By thinking ahead and getting the right database deployment advice, you can reduce, or even remove, the risk to your business.