2026 should be a year of database updates, upgrades, and migrations. Across all of the most commonly used open source databases, end-of-life dates are forcing teams to take stock and move their workloads. The alternative is to stick with what is in place. While staying put might work in the short term, it will lead to more problems and higher costs over time. At the same time, moving too quickly has its own risks and potential challenges. How can we get things just right for you and your team?
Database dates for your diary
If you use MySQL, then there is a major date to plan ahead for. On April 30, 2026, MySQL 8.0 will reach End of Life (EOL) status. As a Long Term Support release, MySQL 8.0 is at the heart of many applications, so there should be a lot of planning completed already around moving to new systems. For those of you running PostgreSQL, version 13 is already End of Life, and version 14 will move to EOL status when version 19 of PostgreSQL is released in September 2026. Redis will see two end-of-life dates in 2026, with 7.2 going EOL in February 2026 and 7.4 in November. Outside open source, MongoDB 6.0 will reach EoL status in June 2026.
For teams running any of these databases, planning ahead around updates will involve a lot of work. For teams that follow a best-of-breed approach and use multiple databases in their stacks for different workloads, the challenge is even greater. Any migration should ideally start at least six months early to allow enough time for testing, compatibility checks, and successful cut-overs in advance of any end-of-life date. Yet the world of IT is rarely ideal; these applications might be critical to the business, leading to compressed timelines or even projects being postponed repeatedly. In a world where “if it’s not broken, don’t try to fix it” is often sage advice, a database migration might be seen as a lot of work for very little reward and high risk when things don’t go according to plan.
So what can teams do to get ahead of these projects and the potential problems that can come up?
Planning the move
The first place to start is knowing all of the database systems that are in place. This can be across test, development, and production instances, and across database versions. There might be multiple versions of one database, or versions of the different databases that are implemented. Either way, making an accurate list of what is implemented is essential. Even if you run your databases in the cloud using a managed service, those databases will be a specific version and will need to be updated over time.
Once you have that list of database instances and versions, you can decide if and when they should be updated. Test and development instances can be moved sooner, while production deployments can be moved once the database is proven to be as resilient and reliable as the existing versions. Everyone in IT is familiar with the rule of not implementing a version of software that is *.0, and waiting for the inevitable bugs or deployment problems to be patched. For production environments that have to deliver to service levels, that move will take some additional time.
You may also want to estimate the time frame for your project. Critical applications will need more careful planning and testing before they get shifted, while less important ones might need less time. Similarly, critical applications might have more complex deployments like sharded databases or clustering for availability. Updating a distributed database is harder and will take more time than a single-server deployment.
However complex your environment is, try creating a standard estimate for projects. An estimate will give you some internal deadlines for those projects based on your understanding of complexity, deployment type, and, most important of all, how critical the application is to the business. This will help you plan not only the migrations, but also your communications around the moves and the potential impacts they might have on the business. For truly mission-critical applications, this timeline might have to extend to twelve months.
Once you are ready to commit to a move, you should measure your performance today before any changes are made. This gives you a benchmark for your existing systems and a picture of what “good” looks like. Without this measurement, you will not be able to determine how successful the move has been. Even for end-of-life software migrations, businesses expect to see some form of return on their investment, and a performance boost from a move can count towards that return.
The details of the migration will depend on your database and how it handles the move. Some updates will be simple and can be carried out in place, while others will be more complex and contrite. The most serious are those where there is no simple rollback process; in effect, once you migrate, there is no route back. For these situations, restoring a backup may be the only recourse. Similarly, a restoration may be in order if you have a problem with performance.
Alongside the database itself, you will have to look at the overall application environment as well. Any change to the database can have a knock-on effect on the application developers, and on the line-of-business team responsible for the service. Implementing a test environment for the updated database for compatibility testing will help you ensure proper behavior and functionality. Alongside this test, you should also look at your documentation, so you can plan your architectural changes and ensure you have fully described your production implementation, rather than just thinking you have described it.
Potential challenges
The biggest challenge around database migrations is getting people on board with the project. To make it easier to get support, it’s important to look beyond the EOL date. Instead, look at the benefits that a change can deliver around performance or ease of use. These improvements might seem small, but they can quickly add up to real business value.
The next biggest challenge in any database migration is getting things to work as expected. You may find edge scenarios that use areas of your database that have changed and that were outside your initial testing and planning. Those functions then have to be updated and implemented, with the same attention to detail that they might have needed before the move.
To make all this work successfully, you should put together a budget for the migration project. This budget should cover any additional personnel costs to include what is needed during the move, as well as the cost of the hardware or any additional resources. Whatever you might have estimated, you may face additional expenses when those extra requirements crop up or unplanned extras need support. Such contingencies must be planned for, or you risk the migration failing as a whole.
How you communicate around a migration project can make a huge difference to its success or failure. Your communications plan should cover those directly involved, like the developers and infrastructure managers, through to those who own the application within the business. Each of these groups may be affected by the migration, and must be made aware of the issues and pain points that may come up. By agreeing communication paths ahead of the move, you make it more likely that you can work together effectively around the whole project.
In 2026—and beyond—database migrations will demand time, effort, and attention from developers and infrastructure teams. To make those migrations effective, planning ahead around end-of-life scenarios will involve preparation, testing, and measurement. Working back from those deadlines will help you prepare more effectively and make the business case to move at the right speed for your team, rather than leaving things to the last minute. The goal here is to reach the Goldilocks zone, where migrations are not too fast or too slow, but just right for the business.
—
New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.
Go to Source
Author:
