Hi all,
Thank you to all who attended our webinar this week! Below you’ll find answers to the questions we received during the presentation:
Upgrade path:
Q: We are on 8.9.7, not the latest point release, 8.9.10. Do we need to upgrade to 8.9.10 first, or can we go for 9.9.0 LTS directly?
A: While you should absolutely be on the latest point version of your release, in this context the point versions don’t matter. You can upgrade from any point version of 8.9 to any point version of 9.9 (not that there are any yet).
Q: We’re in between LTS versions. What’s our upgrade path to get to the current LTS, 9.9?
A: It depends on where you are now. It’s always true that you can upgrade from any version in a series to its LTS. So you can go, for instance, from 9.3 straight to 9.9. If you’re not in the 9-series, then you’ll have to hit any intervening LTS. So for example, from 8.9, you would upgrade to 8.9.10, and then to 9.9.
Q: Can you upgrade directly from version 8.9 LTS to version 10, or should we first update to version 9.9 LTS?
A: The latter. You must hit every intervening LTS, so your path is 8.9 to 9.9 and then on to 10.0.
Q: What about upgrades within the 9-series? Is a schema migration still required for that?
A: There are database changes with every release, so a schema migration is basically always required.
Q: What about 10.0? Is that an LTS version? If not, when can we expect the 10-series LTS?
A: LTS versions are released on an approximately 18-month schedule. SonarQube 9.9 LTS was released in early February 2023, which means you should expect the 10.x LTS in summer of 2025.
Q: What’s the path to upgrade from SonarQube 8.9 Developer Edition to the latest version of Enterprise Edition?
A:From 8.9, you’ll need to upgrade to 9.9 and then to 10.0. There are no database schema differences from one edition to another. So, the edition upgrade can be done at any stage of that trasition. Simply download and use the Enterprise Edition of a version instead of the Developer Edition.
Q: Is there a cooling-off period you’d recommend before upgrading to the latest version after its release?
A: No. We release on an approximately 2 month cycle and do our best to ensure that each new version is stable and won’t need point releases. If you’re interested in the Latest versions, you should upgrade as soon as is practical after each is released. For LTS versions, the initial release is a hardened version of the previous release. In practical terms, that means that 9.9.0 is a hardened version of 9.8. So we don’t see any reason to wait. That doesn’t mean that it never happens that we release and then realize we broke something. We’re human too. 
But that’s the exception rather than the rule.
Prepping for the upgrade:
Q: Are there any license prerequisites to take care of before doing the upgrade?
A: Just make sure it’s not expired and you haven’t run out of LOC. Otherwise, nothing to do.
Q: What if we need to upgrade the underlying database engine in concert with our SonarQube version upgrade?
A: If your JDBC URL changes in your database upgrade, it’s likely that your server id will too. The best thing is to coordinate with your sales contact.
Q: Other than the database backup, is there anything else we need to back up before an upgrade? Anything that should be backed up or copied from the UI, for instance?
A: No. It’s all there in your database.
Q: We want to switch architectures during the version upgrade. Is there anything specific we need to do or be aware of?
A: This is the same as any other upgrade. Just make sure that the new instance points to the same database the old one did.
Q: Will the server ID change if we move from Developer Edition to Enterprise Edition?
A: No, but you will need a new license key for the upgraded edition.
Q: Is there anything we can or should do to speed up the database schema migration?
A; Per the docs: During your upgrade, tables may be duplicated to speed up the migration process. This could cause your database disk usage to temporarily increase to as much as double the normal usage. Because of this, we recommend that your database disk usage is below 50% before starting a migration.
Check those same docs for some additional database maintenance you may want to perform after your upgrade is complete.
Q: How do I download the current LTS to get ready for my upgrade?
A: Use the downloads page: https://www.sonarsource.com/products/sonarqube/downloads/
Q: Upgrading from 7.9.x LTS requires upgrading first to 8.9.10 LTS. is this release still downloadable from your site? Could you give the link to please?
A: Yes. Check the downloads page for the ‘Historical’ link at the bottom.
Q: SonarQube 8.9 to 9.9 is a big jump. What are the major changes I need to be aware of before I perform the upgrade?
A: You’ll find them summarized here: https://docs.sonarqube.org/9.9/setup-and-upgrade/lts-to-lts-release-upgrade-notes/
Q: SonarQube 9.9 requires Java 17. Is that bundled in or a separate install?
A: It’s a separate install.
Q: How do I tell if my current SonarScanner versions are compatible with my upgraded SonarQube version?
A: We don’t maintain a compatibility matrix. Just make sure you’re on the latest versions. They all work together.
During the upgrade:
Q: How is the upgrade procedure different if you’re deploying with Docker versus from the zip file?
A: The procedure is essentially the same. Except that instead of downloading a new zip file, you’re upgrading your image. You still need to back up your database and make sure you’ve upgraded any relevant 3rd-party plugins
Q: When upgrading, are some settings reset to their defaults?
A: Settings are stored in the database, so they should all be retained if you point your new instance to the same database as the old instance used.
Q: Is there any information stored on the filesystem that we should be aware of during an upgrade.
A: There is $SONARQUBE-HOME/conf/sonar.properties, which holds some key values. Most of them can be set via env vars if you’re deploying with Docker or Kubernetes. Additionally, any 3rd-party plugins you’re using will be stored in the filesystem.
Q: Why should we copy individual settings from the old sonar.properties file to the new one? Why not just replace the file?
A: The default contents of that file change occasionally. If you simply overwrite the new file with a copy of the old one, you’ll lose the opportunity to use those new settings.
Q: Do I need to be concerned about analyses firing during the upgrade?
A: You should pick a slack time to perform your upgrade since your SonarQube instance won’t be available - either for users or for analysis by your CI agents. That means analyses will fail since the SonarScanners won’t be able to contact the server.
Q: If something goes wrong in my upgrade, is there a guided rollback process?
A: No. It’s not possible to downgrade. That’s why you should back up your database before starting an upgrade: so you can restore it if you need to fall back to your old version.
Features in the version:
Q: I’m currently using a plugin to get a feature that you’ve since added as out-of-the-box functionality. Should I keep using the plugin, or switch to the native functionality?
A: In general, it’s best to stick with native functionality where you can. You use 3rd-party plugins at your own risk.
Q: We’ve noticed there are new rules and other features such as expanded SCIM support in 10.0 that we’d like to be able to use. Will they be backported to 9.9 LTS?
A: Only fixes for blocker bugs and vulnerabilities are backported to the LTS. For new rules and features, you’ll have to adopt the Latest version. In doing so, you should be ready to continue your upgrade path every ~2 months as newer versions are released, since only the LTS and the Latest version are supported.
Q: If I’m using custom Quality Profiles, how do I keep up with the new rules added in an upgrade?
A: The easiest thing to do is look at the changelogs of the Sonar way profiles. However, not every new rule is active in Sonar way. When rules target specific frameworks or circumstances, they are likely to be off by default. In that case, community announcements may help.
Q: How can I keep track of what existing rule implementations changed from one version to the next?
A: That’s not always easy. The data is available though if you dig into the SonarQube version release notes and look for the “improve [language] analysis” tickets. From there, you can find the changelogs of the underlying analyzers.
Q: SonarQube 9.9 requires Java 17. Does that mean we can’t analyze Java 8 code anymore?
A: Not at all! You can compile with, or to, whatever version your project needs. Just make sure you run analysis with Java 11 or Java 17
