I want to call attention to the 10.9 Upgrade Notices listed in the Release Notes Installation section:
"Increased startup time when upgrading to Jamf Pro 10.9.0—Duplicated columns stored in the application and application usage log database tables will be moved to an application details database table during the initial server startup when upgrading to Jamf Pro 10.9.0. This one-time extended startup could take anywhere from a few additional minutes to several additional hours, depending on the size of your applications table and the hardware used in your environment. It is important that you do not stop the startup process. If you have questions or experience any issues during startup, contact Jamf Support."
This is also mentioned in the What's New section with "Jamf Pro now uses Unix user paths "~" by default to save space in the application and application usage log tables."
What this means is there was some drastic data normalization done to the Applications and Application_Usage tables that could result in those tables being reduced by more than 78% and 60% in size respectively for environments that currently have a lot of rows in those tables. So don't get freaked out if your database is much smaller post upgrade.
With the normalization we will likely see an increase in upgrade times and slightly larger disk space utilization during that period before the size decreases. Some rough math shows that people with 10 million rows in their application table could see about 20 minutes to normalize it. Row counts per table can be confirmed via your JSS summary.
Rough math, and don't quote me, just giving you an idea. For people upgrading from a release prior to 10.7 the process will be twice as long as mentioned above and you will need roughly 125% of the size of the larger of applications or mobile_device_installed_applications tables available. If you are coming from 10.7+ you could need 25% the size of applications plus 40% the size of application_usage_logs available.
Also, I know I'm repeating common knowledge but always back up your database prior to upgrade and make sure not to restart tomcat or interrupt the upgrade process. It's also not a horrible idea to take a copy of your production database and upgrade it in a test instance closed off from the internet so APN/DEP/VPP/ETC services don't reach out and cause conflicts with your production instance running to get an idea of upgrade time and any problems your normalization may run into.
