What version are you upgrading from?
Sonarqube community version 7.9.6
System information (Operating system, Java version, Database provider/version)
RHEL-9,Java-11,Postgres 13
What’s the issue you’re facing?
We have running community edition with version 7.9.6 on RHEL-9 with postgres 13 database.We want to create a brand new instance of sonarqube enterprise version for which we have license key and then want to export the old database and import the database into new sonarqube instance once it is up and running .Database version will remain same.
Can you please advise if this is possible or still need to go through defined migration path and what would be it if we want to go to latest version.
Can we stay on 9.9 LTA or is it recommended to go the very latest version?
Will going to enterprise version our project history and data will remain intact?
Can you please adivise about the below error. Will this error still come if we do fresh installation and then export and import the database into fresh instance.
####web.log
ERROR web[][o.s.s.p.w.PlatformServletContextListener] Web server startup failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.DatabaseServerCompatibility': Initialization of bean failed; nested exception is The version of SonarQube is too old. Please upgrade to the Long-Term Active version first.
2024.08.07 09:08:40 INFO web[e5099a35-b108-4602-a509-92bcb74f6a16][o.a.t.u.h.p.Cookie] A cookie header was received [__utmzz=utmccn=(not set);] that contained an invalid cookie. That cookie will be ignored.\n Note: further occurrences of this error will be logged at DEBUG level.
####################
Any other recommendation please suggest for this migraiton.
Thanks a lot for your response. So if we start from empty instance, then can we go to the latest version without going through intermediate upgrade steps? As it will be new instance with empty database.As our jenkins integrates with sonarqube and with each job run it will continue to create new projects and do fresh analysis on each branch or PR etc. As you mentioned data from old instance is not of much value. Or do you think this is not ideal approach.
Also with data from old database imported to new database server, then that would also impact our LOC towards license and will count all the analysis done before and has potential to reach threshold defined with LOC immediately as we enter in the license.
Just trying to be aware of all the possibilities if we do inplace upgrade for 7.9-8.9-9.9 or install a new sonarqube instance with latest version (10.6) and start all the analysis from scratch as we build each project in jenkins.
I want to know your opinion on the above approaches please if you can guide.
Hi @harp,
When upgrading from version 7.9 to 9.9, it may be more easier to start with a clean instance. I recommend setting up multiple instances if you have staging licenses.
As part of the upgrade, there will likely be changes in how analyses are run in Jenkins, including:
Introduction of new parameters for branches/PR
Discontinuation of obsolete parameters for coverage and the JDK scanner
The migration effort and strategy will be influenced by several factors, including:
Number of Jenkins instances
Structure of jobs or pipelines
Types of scanners used (e.g. Docker, Jenkins tools, Maven)
Number of affected jobs
Quality gate objectives
Number of development teams and languages involved
It’s also important to consider whether you have:
Jenkins test instances
Utilization of Jenkins shared libraries or Docker
I would be happy to discuss this further and provide assistance with the migration process. Please let me know if you have any questions or need additional support.
If we do go with clean instance, this changes our server-id as it will be fresh database so i am thinking to go step by step from 7.9 to 8.9 and so forth so that we can have same server id allocated to our enterprise license.
One further things is concerning is that our LOC in production is showing to be 200M but our license is just for 2M. Do you have any guidance on this as how we can reduce it to within permissible limits of our license usage else on upgrading it will not do any analysis. How can we clean it or limit to just scan selective repositories.
We have jenkins test instance and we do not used docker.We have staging license where we can test and for our staging environment also it is breaching our line of code as it is more then 4M as well. Before we proceed with migration we need to have correct information how to deal with LOC.
Thanks.
Hi @harp,
You’re absolutely right to highlight the differences between the Community and Enterprise editions of SonarQube in terms of LOC counting. While the Community edition is great for getting started quickly, it tends to count lines of code for each branch independently. This can quickly inflate the total number of LOC, especially if you have a large number of active branches.
The 2 million LOC in your Enterprise license may seem limiting, but it’s a good starting point for establishing a “Clean as you code” culture. By focusing on the most critical projects and removing those that are no longer maintained, you can quickly free up capacity.
Here are some avenues to explore:
Recalculate LOC: Before making any drastic decisions, I suggest checking if the LOC calculation is correct. Files like unit tests, configuration files, or generated files can sometimes be included in the count. Check your exclusion configurations and ensure that only relevant source code files are analyzed.
Prioritize projects: Focus on the projects that have the most impact on your business and are most likely to benefit from Sonar analysis.
Remove obsolete projects: Remove projects that are no longer maintained or are no longer relevant. Be aware that this action is irreversible and can result in the loss of analysis history.
Progressive migration: Consider a gradual migration to the Enterprise edition, starting with the most important projects. Retain the Community edition for non-essential projects.
Upgrade the license: Don’t hesitate to contact your sales representative to discuss your needs and possibly negotiate a higher LOC quota.
In summary, managing the LOC quota requires a thorough analysis of your environment and objectives. Don’t hesitate to reach out to me if you need more personalized advice.
or 2 years ? You sould read :
Licenses 