Anyone running OpenEdge applications on HP-UX should start planning a migration strategy for before Hewlett-Packard drops support for the operating system.
Deadlines aren’t real until they are staring you in the face, right? But what if we told you a deadline that appeared to be five years away was way closer than you think.
Hewlett-Packard is dropping support for their HP-UX Operating System at the end of 2025. If customers stay on the unsupported HP-UX, not only will they not be receiving patches that support new hardware and eliminate security risks, they will also not be able to upgrade their OpenEdge application. OpenEdge 12 no longer supports HP-UX as a platform for deployment.
Platform migration can take from as little as a few weeks to six months or longer. With this in mind, organizations should start to plan their migration strategy and what it means for OpenEdge—today and for the future.
First Steps in the Migration: Sizing a New System
OK, where do we start? Decide what the new platform will look like.There are a lot of options for moving OpenEdge applications off HP-UX. The natural path for HP-UX users is to move to another UNIX-like Operating System, with Linux being the most popular.
The first step is to analyze your current system to help size a new system. Modern computer systems have become complex with many options. Making a poor choice can make your application run worse on the new platform than on the one being retired. That’s a pitfall we see far too often.
For your current system it’s important to look at:
- The number of CPUs and their utilization over time
- Application performance, specifically the Create, Read, Update, and Delete (CRUD) activity over time
- How much memory is in use? Memory is cheap and what seems like a lot of memory today, might look like a toy in five years. For example, many laptops have 32 GB of memory right now. It would be a shame for your enterprise application to be running on a machine that has less memory than a laptop.
- What is the disk configuration and what is the response time of the disks
Knowing this information can help you choose a right size machine for your application.
A note of caution: Do not get too enamored with over-provisioning the number of CPUs in a new system. OpenEdge runs best on fewer but faster CPUs than many slower CPUs. The more CPUs, the more likely you will be forced into a NUMA configuration, which is not a good architecture for any database application, be it Oracle, MSSQL, MySQL, Postgres and, of course, OpenEdge. Fewer CPUs with many CORES works best.
What Does a Successful Platform Migration Look Like?
Once you have your new system, there are several things you need to do to have a successful platform migration:
- Install OpenEdge on the new machine
- Bring over any Application Components needed to run the application. Don’t forget any external packages outside of the OpenEdge application such as Telnet, Mail, etc.
- Bring over the databases. Most times this will require a dump and load.
- Port scripts for the new environment
- Start testing. Test the “Happy Path,” but also test end of month, end of year, and any other not often run components of the application
- Plan for the cutover, which includes stopping the application on the old platform, doing a final data migration, and pointing all users to the new platform.
- Perform a Database Health Check to get the most value out of the new hardware.
How Complicated Is a Platform Migration?
Integration points are what makes an application complicated. The most interfaces into the database or application, the more testing and verification that needs to be done. We no longer live in a world where the OpenEdge application stands alone to run a business. All access points need to be accounted for.
The migration process is fairly straightforward for the Progress Services engineers, but for companies that have been on the same platform for the last five years or more, it can seem daunting. The person who led their migration the last time around might not even be at the company anymore, and there could be a loss of institutional knowledge. This is where the Progress Services team can help. On average, Progress Services does a go-live every month for a Platform Migration with several active for different customers at any given time. No other team has this experience with a wide variety of OpenEdge applications
Planning for Go-Live?
The hardest part of the migration for most companies is finding the downtime for the cut-over. This is typically handled on the weekend over a holiday period. However, with Global operations, what is a common holiday? Can the application be down for 24 – 48 hours for the cut-over?
Progress has tooling to limit the downtime for cut-over by using replication technology. This limits the downtime to an hour or two regardless of the size of the database.
Post Go-Live Activities?
Good planning and experienced execution can make a move to a new platform successful, but that’s not all you need to do. Invariably there will be some bumps on the road that you did not account for, so having the migration team available to solve any post Go-Live issues is essential. In addition, once you’ve moved, you need to do a post-migration Database Health Check or performance tune to make sure the applications are running at peak performance on the new hardware. You spent money on the new hardware, it is best to get the most value out of it.
Ongoing Support of the Application
The Progress Services team has built internal tools to help with migration and managing your new database once it’s up and running. The same team that does the migration can manage your database through our MDBA services.
This can not only serve as an insurance policy for your investment, but it is also cost-effective when you consider the cost can be as low as one-third or one-fourth the cost of a full-time employee for 24/7/365, follow-the-sun support.
No waking people up in the middle of the night or coordinating overtime coverage during off hours and weekends. This gives your team some relief while also ensuring the OpenEdge experts are on the case immediately.
Progress has the largest database services organization that works with the OpenEdge ecosystem because Progress wrote the product. If we run into any problems, we have a direct link to technical support and development. The Progress Services team sees hundreds of OpenEdge applications every year with the experience having supported hundreds of customers migrate
Conclusion
Whether your move to a new platform was prompted by moving to newer, better technology, or moving away from an unsupported operating system or hardware, execution and management are the keys.
Migrations are both necessary and inevitable, and the HP-UX end of life just forces your hand … a little earlier than you might have thought too.
To talk to an OpenEdge expert about your move, contact us to set up a consultation.
Mike Furgal
Mike Furgal started his career at Progress in 1989 in development and is currently the director of database and Pro2 Services. He has held many different roles during the time including working on the OpenEdge database product and managing different development teams working on the OpenEdge database. In 2012, he joined the Consulting team at Progress as Director of Database Services where he and his team are responsible for managing over 2,000 distinct databases and over 140 Terabytes of data and 175,000 connected users. As a former developer of the OpenEdge database, Mike brings a unique perspective as both a consumer of the OpenEdge technology, and also a developer of the same technology. Mike has presented highly technical topics around the world at nearly all of the Progress conferences and PUGs.