A modern Linux machine very likely isn't going to run an old Progress version like 9.1D; it won't have the required libraries. But if you have source code for your application then you can compile it under a modern release of OpenEdge and run that on Linux. The current release is 12.8.
If you are on a current Progress maintenance contract, you can upgrade your existing licenses for free. Otherwise you will be buying new Progress licenses. Depending on your business needs and what licenses you currently have, you may be buying some new licenses anyway, either to ensure licensing compliance or to provide new functionality (e.g. database replication, database encryption, etc.).
Do we need same software progress 9.1d bundle and install refresh progress to another server and than create new database and dump and load and take backup and from HP/UX and restore newly created db in red hat Linux?
You would install a new release of OpenEdge on Linux. There is no backup and restore of the source database in this scenario. The new target database is created as a part of the dump and load process. Once you have provisioned the new server and installed OpenEdge on it, the basic process would be like this:
- Design your new target database structure with Type 2 and AI areas, based on static and dynamic analysis of your source database.
- Dump your source database schema to a file (dbname.df).
- Modify that schema file to reassign tables and indexes to the appropriate storage areas.
- Build the new void target database with
prostrct create on Linux.
- Copy the appropriate empty database overtop of the target to load the Progress metaschema.
- Load the modified application schema file (dbname.df) into the target.
- Back up the target. (This will be used if you need to re-run the load.)
- Shut down the source database.
- Dump the data from the source database, ideally to a shared file system that is accessible to the target machine, to avoid the extra step of copying the dump files across a network. What this entails depends on what database features you are using.
- tables (either binary or ASCII dump, depending on needs and constraints)
- sequence values
- users
- SQL schema, permissions
- Run a dbanalys report on the source to capture the table record counts.
- Load the dumped data into the target database.
- Run a dbanalys or tabanalys report on the target.
- Compare the source and target record counts to ensure that all table data was loaded successfully.
- Back up the target. (This is done for safety, in case the index rebuild crashes.)
- Build the indexes.
- Back up the target.
- Verify that other data (sequence values, users, SQL info, etc.) was loaded successfully.
- Start the target database.
- Test your application as appropriate.
This is a bare-bones overview and doesn't capture all the work you need to do to migrate to a new server and upgrade across three major releases, or the prior knowledge required to do the work properly. You will need to do additional work in testing and dry runs of the technical and business steps involved in this process, and in automating and documenting the steps, so you have the appropriate checklists, procedures, and scripts, and you understand the elapsed time for each step and for the process as a whole. You should also do pre-dump safety checks of your source database and server: ensure sufficient disk space, working backups, compacted indexes, no corruption, no recid fields, etc.
The operating system change requires you to review and possibly modify your operations scripts (database stop/start, backups, DR, maintenance, etc.).
The OpenEdge upgrade requires you to review your database and client configuration (database broker parameters, client startup parameters, AI/BI settings), backup and restore procedures, disaster-recovery procedures, etc. The upgrade is also an occasion for re-evaluating your licenses to confirm you have the correct licenses and user counts, and to evaluate whether you should buy new products, e.g. OpenEdge Replication Plus, Advanced Edition Enterprise RDBMS, etc. The above requires knowledge of OpenEdge 12. If your team doesn't have that you should consider hiring a reputable consultant to help you plan and execute that work.
