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
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.
Upgrade the database. Essentially:
Shut down, truncate BI, back up with 10.1A. Test your backup.
With 11.x, run proutil -C conv1011.
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?
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?