Question Does anyone have a demo of Progress database migration?

Nisha Chile

New Member
Does anyone have a demo of Progress database migration? We want to migrate database and application from progress version 10.1A02 to 11.7.
Last edited:

Cringer Moderator
Staff member
Why specifically 11.3? 11.7 is the current version. 11.3 is still obsolete, just not as obsolete as 10.1. ;)


The basic steps:

proshut -by dbName
proutil dbName -C truncate bi
probkup dbName /backupdir/dbName.pbk -com # you might skip this if you have after imaging enabled or replication and you are confident in your backups
proutil dbName -C conv1011
proutil dbName -C updatevst
proutil dbName -C updateschema

Anything more than this is probably application specific and requires significant knowledge of your environment.

Common additional tasks include:

- dump & load to adopt type 2 storage areas (which is an extensive topic and discussion in its own right)
- implement after imaging if it is not already enabled
- recompile application code
- consider code changes to adopt new feature of the 4gl
- adopt new db features if applicable

Rob Fitzpatrick Sponsor
Pedantic observation: I think of "migration" as moving an application or database from one machine to another. I think of what you are planning as an "upgrade".

The most significant part of the change you are considering is that it crosses a major-version boundary, from 10.x to 11.x. Other upgrades are much simpler by comparison.

Your changes can broadly be broken into two categories (apart from the 11.x installation itself, which is straightforward):
  • How to upgrade the database;
  • How to upgrade the application.
Each of these categories can be fleshed out further:
  • Things you must do;
  • Things you may have to do, depending on your circumstances;
  • Things you could do, i.e. opportunities for improvement.
  • You must:
    • Upgrade the database. Essentially:
      • Shut down, truncate BI, back up with 10.1A. Test your backup.
      • With 11.x, run proutil -C conv1011.
  • You should:
    • Examine the static analysis of your database (proutil -C dbanalys).
    • Examine the run-time performance metrics of your database, including promon metrics and CRUD stats. The latter, together with the dbanalys output, will help you assess whether structure changes may be in order.
    • Re-examine your physical structure. Projects like this are an ideal time to make configuration changes, which may include a full or partial dump & load to make structural changes.
      • Do you have the appropriate areas for your application?
      • Are they all Type II?
      • Do you have any empty areas?
      • Do you have any mixed-use areas (i.e. containing more than one object type)?
      • Do you have any objects in the schema area?
      • Do you have all very large tables in their own areas? Do you have separate areas for their indexes?
      • Do you have a separate area for tables that have word indexes?
    • Re-examine your configuration, including:
      • Broker startup parameters;
        • You need to learn about all the new parameters and capabilities that were added since 10.1A; there are a lot;
        • Don't forget client/server performance, if you have remote connections; do the users have performance concerns?
      • Security configuration (domains, run-time permission checking, table permissions, user lists, etc.);
        • Do you have any usernames containing "@"? They will have to change;
      • Transaction subsystem (BI settings, AI settings);
      • Backup/recovery regime
        • Does it follow Progress best practices?
        • Does it align with your business' RPO/RTO/SLAs?
        • Does it interfere with business processes or application performance?
        • What could be improved? Is your data as safe as it reasonably can be?
    • Perform any needed periodic database maintenance. Do you need to:
      • Compact or rebuild indexes?
      • Build new indexes?
      • Update SQL statistics?
      • Update SQL widths (dbtool)?
      • Perform a full dump & load?
      • Relocate tables or indexes?
  • You must:
    • Recompile all r-code and rebuild all procedure libraries, if any, using your 11.x compiler.
    • Update your CI/CD build pipeline, if any, to use the new DLC.
    • Check the Platform Availability Guide for information pertinent to you on:
      • OS support/certification, both client-side and server side; will you be running a very new OpenEdge on a very old OS?
      • Discontinued platform support (e.g. licenses for OE on Linux/PowerPC no longer exist)
      • Deprecated or discontinued products (e.g. DataServer for ODBC no longer exists)
      • Deprecated or discontinued product features (e.g. do you still use EDITING blocks or the RECID function in your code?)
    • Test! Test! Test!
  • You may have to:
    • Fix code or add a keyword-forget list if your old code uses identifiers that were not reserved language keywords in 10.1A but are now in 11.x.
    • Fix code that depends upon deprecated features.
    • Replace/decommission discontinued products.
    • Migrate off old or unsupported platforms (applies to the database too).
    • Update or otherwise deal with Progress libraries you depend upon (e.g. WebSpeed web-disp.p, ADM1/2, etc.).
    • Update configuration settings, .ini files, client shortcuts, published/packaged virtualized apps, etc.
  • You should:
    • Re-examine and update your client startup parameters;
      • Note that some parameters' default values will have changed, so don't forget to look at all parameters).
    • Examine your application's run-time metrics, e.g. client resource usage (bandwidth, memory, CPU, disk I/O) and CRUD stats; look for possible application issues;
      • Do you have outlying values in your table or index reads?
        • You may have inefficient or poorly-bracketed queries doing unnecessary reads.
        • You may want to fix the code or add needed indexes.
      • Do you have very large or frequently-updated client temp files (DBI/lbi/rcd/srt) in the temp directory?
        • This could be the result of poor coding or, in some cases, poor tuning. Some issues can be addressed with tuning, e.g. setting -Bt, -tmpbsize, -mmax.
  • You may want to:
    • Examine what has changed in the ABL language, runtimes, and tools (again, a lot) and audit your code for opportunities for improvement, both existing code and patterns and practices for new code.
Especially if this is an in-house application, but even if it isn't, this is an important time to train staff on new platform features, capabilities, restrictions, and best-practices guidance. Lots of best practices evolve over time, some becoming obsolete or even becoming worst practices. Examine what you are doing holistically, in development, operations, maintenance, etc., and ask yourself whether it is appropriately modern. If you think it is, can someone else corroborate your opinions?

This is also a good time to ask: is my Progress licensing up to date and appropriate for my use and deployment topology?
Last edited: