Question Request for Guidance on Upgrading Progress Database from Version 11.7 to 12.8

V

vikash

New Member
Hello,

I am currently preparing for an upgrade of our existing Progress database from version 11.7 to the latest version 12.8. As this will be my first time performing a database upgrade in this environment, I would greatly appreciate a detailed and validated step-by-step procedure.

Here is a brief overview of the current application architecture:
  • The frontend is built using Java and Angular.
  • The backend logic and database are both implemented using Progress.
  • The application communicates with the database using RESTful web services.
  • Both Tomcat and HTTPD (Apache) services are actively running and are integral to the current system setup.

To proceed with the upgrade smoothly and ensure minimal disruption, I would like to understand the following:
  1. Pre-upgrade checklist – What preparations are necessary before initiating the upgrade (e.g., full backups, compatibility checks, application downtime planning)?
  2. Upgrade procedure – Step-by-step instructions for upgrading from Progress 11.7 to 12.8, including any commands or scripts required.
  3. Configuration considerations – Are there any configuration files or environment settings that need to be modified post-upgrade?
  4. Impact on existing services – How will the upgrade affect the Tomcat and HTTPD services? Will any service-specific changes be required?
  5. Validation and testing – What are the best practices for verifying the upgrade (e.g., data integrity checks, performance validation)?
  6. Rollback plan – In case of issues, what is the recommended rollback strategy?
  7. Known issues or limitations – Are there any known bugs or compatibility concerns between version 12.8 and the components mentioned above?

Any guidance, documentation, or previous experience you can share would be extremely helpful. I am committed to ensuring a safe and efficient upgrade process, and your support in providing clarity around this would be greatly appreciated.

Also planning to deploy the application on PAS instance after upgrading successfully.


Thank you in advance for your assistance.
 
The database upgrade procedure itself is simple and straightforward. All that you need to do is to run "proutil dbname -C conv1112".

Of course, as you note, you need test everything and have backups and and a rollback plan. And a whole lot of that is very specific to your particular circumstances and configuration.

In no particular order here are a few things that we will need to know in order to give you a better answer:
  • Is the current OpenEdge 11 application using "Classic Appservers"? (Classic Appserver is NOT available with OE12)
  • Is the current OpenEdge 11 application using PASOE? (Both Classic AppSrv and PASOE _could_ be running on OE11)
  • What OS is your database running on?
  • What OS does your application code use?
  • Does your application connect to the database using TCP/IP connections? Or is everything using shared memory?
  • Are you using OpenEdge Replication? If so - how many targets do you have?
  • Are you using anything "extra" like TDE or Auditng or Multi-tenancy?
  • How much time do you have available for the upgrade? Minutes? Hours? Days?
This sort of thing tends to be an iterative process of exploration. So do not be surprised if there are follow-up questions.

Also - if you're in a hurry you might want to consider engaging some professional services. We are all just volunteers here and any advice given depends on how much free time we have and whether or not anyone is inclined to dive into a topic.
 
You might want to read this thread about upgrading across a major-version boundary.
https://www.progresstalk.com/threads/does-anyone-have-a-demo-of-progress-database-migration.183440/

The question in that thread was about going from 10.x to 11.x, but it is similar in principle to go from 11.x to 12.8.

Be sure to compare the products and features you use against the list that Progress has deprecated since 11.7. You will find this in the Platform Compatibility Guide:
https://docs.progress.com/bundle/OpenEdge-12-Platform-Compatibility-Guide/resource/OpenEdge-12-Platform-Compatibility-Guide.pdf

I'll second what @TomBascom said. Your list of requirements ("Checklists..., Step-by-step instructions..., including any commands or scripts required..., rollback strategy") can't be provided on the basis of your post. A lot more context and information about your applications, your environment, your usage of OpenEdge products and features, etc. needs to be provided and analyzed before anyone could provide such assets. In my opinion, the time commitment that would be involved in providing such comprehensive help crosses the line between free Internet advice and paid consulting.
 
One might also note that with good paid help, a huge amount of your time is likely to be saved ... not to mention the predictability and quality of the result ... not to mention the opportunity for learning.
 
Hello @TomBascom,

Please find below the requested information to assist me with the Open Edge upgrade planning:

  • Is the current OpenEdge 11 application using Classic AppServers?
    Yes, the current application is using Classic AppServers. We plan to migrate to PASOE after upgrading to version 12.8, as Classic AppServers are not supported in OE12.
  • Is the current OpenEdge 11 application using PASOE?
    No, the current version 11 application is not using PASOE. However, we intend to deploy the application on PASOE after upgrading to version 12.8.
  • What operating system is your database running on?
    Linux.
  • What operating systems does your application code run on?
    Windows and Linux.
  • Does your application connect to the database using TCP/IP connections or shared memory?
    The application connects to the database using TCP/IP.
  • Are you using OpenEdge Replication? If so, how many target servers do you have?
    Yes, we are using OpenEdge Replication with one target server.
  • Are you using any additional features like TDE, Auditing, or Multi-tenancy?
    No, we are not using any additional features on our database.
  • How much time is available for the upgrade? (Minutes, hours, days?)
    We have one day allocated for the upgrade.
Please let me know if any additional details are required.

I'm truly grateful to everyone who took the time to respond to this post. Your support means a lot—thank you in advance!
 
Often when people upgrade to 12.8, they focus on what they must do: upgrade the database, recompile source, migrate from WebSpeed/App Server to PASOE, etc. But after they execute that bare minimum set of tasks, they are essentially left with a 12.8 installation that is configured and used as if it were 11.x.

At some point, whether it is in this project or a future one, you will want to take a deeper look at all the features that have been added or changed in the platform between your current release, 11.7, and the target release of 12.8. Fortunately, almost all of this information is captured in one document: https://docs.progress.com/bundle/openedge-whats-new/page/Whats-New-in-OpenEdge-12.8.html
It is broken down by changes per release, from 12.0 to 12.8.

This manual is also available in PDF form, as part of the 12.8 documentation set: https://documentation.progress.com/output/ua/resources/OpenEdge/128/oe-pdfs-128.zip

I encourage you to read through this sooner rather than later. Especially noteworthy in your case is the fact that in 12.3, Progress added the capability to upgrade a replication-enabled source without having to disable OE Replication. This is a big benefit when the database is large, as it avoids having to do a time-consuming replication rebase during the upgrade window.
 
At a very high level...

You cannot migrate to PASOE *after* migrating the database. Classic appserver is NOT available on oe12, thus you must migrate your appservers before or during the migration.

You DO NOT want to be doing that for the first time the same weekend that you migrate the database and everything else. You want to be confident that the PASOE deployment is working correctly and that you are comfortable managing it before you move forward with the rest of the project.

If this were my migration project the FIRST thing that I would be doing is getting the conversion from Classic Appserver to PASOE completed, tested and into production.

Your biggest problem with PASOE is probably going to be fixing crappy code that PASOE shines a bright light on. It has been said that PASOE is basically a "memory leak detector". It is not that PASOE causes memory leaks. It simply makes existing leaks a lot more obvious than Classic did.

You can do all of that without migrating the database or any client code. The db and the clients can stay on oe11.7 and you can deploy PASOE on oe12.8 connecting to the oe11.7 database. Since your server OS is Linux, having both oe11 and oe12 installed at the same time is easy. (It is possible on Windows too, it's just more of a PITA.)

Since your application connects via TCP/IP rather than shared memory, the second thing that I would do is to get the clients migrated. That _should_ be very straight-forward. In most cases it will just be a re-compile with oe12 and then some testing. You _might_ find that some new reserved words need to be accommodated in the code base or that some bug fixes have highlighted some stuff that never should have worked in the first place.

Note: when you do migrate from oe11 to oe12 the nature of the "server" processes used for tcp/ip connections changes. The oe12 servers are multi-threaded BY DEFAULT so you probably want fewer servers and more connections per server. This impacts your -Mn, -Mpb, -Ma, and -Mi settings. Testing is a very good idea. Your mileage may vary.

Since you have replication I would build the fallback plan around keeping a target offline when you migrate so that if the migration is a failure you have an immediate fall back. I would consider adding a second target to provide better protection going forward with either a success or failure scenario. The gory details will depend on the business requirements.

If you think that you may need to revert after the migration and after significant data processing then your ONLY path back is a dump & reload. If you think that you may need to pursue that, then you should practice it extensively beforehand. The process is non-trivial and if you are doing it under pressure you really want to have a well oiled process ready to go. The time required depends greatly on the amount of data and the available hardware configuration. FWIW - most people consider it impractical to seriously consider this option. It is also a sign of very weak testing.

Miscellaneous note: you should do a comprehensive review of startup parameters and configuration options as part of this process. There are some important changes to default behaviors and values as well as some brand new options. Some new defaults are much better than old defaults or "typical" settings and if you are explicitly setting them you may want to reconsider.
 
You must log in or register to reply here.
Back
Top