Difference in number of rules after importing Quality Profile

SonarQube Cloud
,
1

Hello,

We are currently evaluating a migration from a self-hosted SonarQube Community Edition instance (SQCE) to SonarCloud (OSS plan), and we are validating whether analysis results remain consistent between the two environments (issues, code coverage, etc.).

As part of this, we exported and imported a custom Java Quality Profile (sonar-24-java-findbugs) from our self-hosted SonarQube instance into SonarCloud.

However, we observed a significant discrepancy in the number of active rules:

  • Self-hosted SonarQube (SQCE): ~1652 rules

  • * SonarCloud: ~646 rules

This suggests that approximately 1000 rules are not imported or not available in SonarCloud.

From our understanding:

  • The profile import was performed via XML export/import.

  • The profile is set as default in both environments.

  • The difference appears to impact mainly maintainability-related rules.

Questions:

  1. Is this behavior expected when migrating profiles from SonarQube Community Edition to SonarCloud?

  2. Are some rules (e.g. from specific analyzers/plugins like FindBugs/SpotBugs or custom plugins) not supported in SonarCloud?

  3. Is there a recommended approach to align rule sets between SonarQube and SonarCloud to achieve comparable analysis results?

  4. Should we consider this as an acceptable deviation and rely on the built-in SonarCloud rule sets instead?

Our goal is to understand whether we can achieve comparable analysis coverage or if this difference is inherent to SonarCloud.

If needed, we can provide anonymized exports of the Quality Profile or additional details.

Thanks in advance for your support.

Best regards,
Marian

4

Hi Marian,

Not just some rules. All rules. SonarQube Cloud doesn’t support 3rd-party and community plugins. So you’re just not going to have those available there.

I’m not aware of one. Can you help us understand what rules you find valuable from these other plugins that aren’t available natively?

Uhm… Yes? :innocent:

You realize I’m biased though, right? :sweat_smile:

 
Ann

5

Hi Ann,

Thanks a lot for the clarification, that helps.

Understood regarding the lack of support for 3rd-party/community plugins in SonarCloud. That explains the gap we’re seeing (in our case mainly coming from FindBugs/SpotBugs-related rules).

Our main concern is ensuring reasonable comparability of analysis results between the current self-hosted SonarQube setup and SonarCloud, especially from a governance/validation perspective.

To answer your question, the rules we are missing are mostly:

  • bug detection patterns typically covered by SpotBugs/FindBugs

  • some additional maintainability checks not present in the built-in SonarCloud profiles

At this stage, we are considering treating this as an accepted deviation, and relying on the built-in SonarCloud rule sets, but we would like to understand:

  • whether SonarCloud’s native Java analyzer already covers equivalent patterns (even if via different rules)

  • or if there is any recommended complementary approach (e.g. combining with external tools in CI) to retain similar coverage

The goal is not necessarily 1:1 parity, but to ensure we don’t lose important classes of issues during the migration.

Any guidance on best practices in such migration scenarios would be very helpful.

Thanks again for your support!

Best regards,
Marian

6

Hi Marian,

You’re going to have to tell me, specifically, what rules matter to you.

And it’s worth pointing out that we do import 3rd-party reports. Sorry, I should have mentioned that in my initial reply. I was just too focused on “plugins” to think of it.

 
HTH,
Ann

1 Like