SonarQube CE → SonarCloud
SonarQube ↔ SonarCloud: integration to migration path.
SonarCloud is your authoritative Quality Gate, so we never re-point every pipeline on a single day. Self-hosted SonarQube goes live alongside SonarCloud first, every scanner run dual-publishes to both so we can measure agreement on real PRs, and only then does gating authority flip project by project — moving your code analysis onto infrastructure you own and custody you control. No flag day, no Quality Profile rewrite, and every project rolls back in minutes.
The honest exception: Community Edition has no branch or PR analysis. The real parity counterpart to SonarCloud is Developer Edition — paid and self-hosted — and we tell you which edition your stack actually needs before Phase 1.
The idea
Dual-publish to prove parity. Flip gating last.
The topology that makes this zero-downtime is dual-publishing at the scanner: every CI run invokes
sonar-scanner against both SonarCloud and your self-hosted SonarQube on the exact same tree, with
Quality Profiles imported via the Web API and the same scanner CLI version pinned across hosts to stop verdict
drift. SonarCloud keeps owning PR decoration and the blocking gate while self-hosted accumulates findings under
your own profiles, so you measure CE-or-DE-vs-SonarCloud agreement before you commit. Only once agreement clears
threshold do we flip the required status check per project, then peel SonarCloud away — each project independently,
each reversible.
The phases
Six steps. Each one reversible.
Baseline & inventory
We document every SonarCloud project by key, language mix and LoC band, every active Quality Profile and Quality Gate, your PR-decoration host, token usage by CI provider, and which engineers run SonarLint connected mode. Quality Profile XML is backed up to the migration repo. Read-only.
Stand up self-hosted SonarQube
SonarQube (Developer Edition for true parity) goes live on your infra — external Postgres, tuned Elasticsearch heap, TLS reverse proxy, SSO wired to your corp IdP. Profiles and gates are imported from SonarCloud's XML backups. No production project publishes here yet.
Dual-publish; SonarCloud still gating
Every CI scanner job publishes to both SonarCloud (still the blocking gate) and self-hosted SonarQube (advisory). Results sit side-by-side so you can measure agreement on real PRs before flipping authority.
Flip gating authority per project, in waves
Per project in waves (low to high blast radius), PR decoration moves to self-hosted, SonarCloud's required status check is unblocked, and self-hosted's check becomes required on branch protection. It bakes seven days at 100% with active false-positive monitoring.
Decommission SonarCloud publishing
CI scanner jobs publish to self-hosted SonarQube only, in the same wave order. The SonarCloud organisation is kept read-only for a 30-day evidence window so historical metrics stay accessible for audit.
Retire the SonarCloud organisation
After at least 30 days with no new analyses, the SonarCloud subscription is cancelled, tokens revoked and CI secrets cleaned up. Compliance documentation is updated so the SOC 2 boundary now reflects self-hosted operating controls.
Feature parity
Where self-hosted SonarQube matches SonarCloud, and where it doesn't.
| Capability | SonarQube CE | SonarCloud | Parity |
|---|---|---|---|
| Scan type (SAST / quality) | Sonar analyzers, main-branch only on CE | Sonar analyzers, branch plus PR | Partial |
| Branch analysis | CE: none; Developer Edition required | Native sonar.branch.name | SaaS only |
| PR decoration | CE: none (community plugin partial); DE+ native | Native on GitHub / GitLab / Bitbucket / Azure DevOps | SaaS only |
| Quality Gates | Full metric conditions, self-hosted gate | Hosted gates, some conditions tier-gated | At parity |
| Quality Profile as code | Backup plus restore XML via Web API | Same API surface | At parity |
| Custom rules | Full plugin API (.jar against sonar-plugin-api, XPath) | Limited subset of languages and rule types | OSS only |
| SonarLint connected mode | Works against self-hosted SonarQube | Works against SonarCloud | At parity |
| Webhooks | Project plus global on gate evaluation | Same | At parity |
| Auth (SAML / OIDC / LDAP) | Built-in providers plus group sync | SSO via GitHub / GitLab / Bitbucket / Azure OAuth only | OSS only |
| Analyzer / rule-pack updates | You upgrade on your cadence (can lag) | Continuous vendor-managed updates | SaaS only |
| Data sovereignty | Postgres plus index on your infra | Vendor EU / US region per org | OSS only |
| Deployment model | Self-hosted (Postgres plus embedded ES plus JVM heap) | SaaS vendor-hosted | OSS only |
| Cost model | Licence (DE) plus compute plus ops headcount | Per-LoC SaaS billing | Partial |
| Compliance (SOC 2) | Self-demonstrated controls | Inherited SonarSource SOC 2 boundary | SaaS only |
What we're honest about
The caveats most vendors leave out.
Community Edition has no branch or PR analysis
This is the single biggest gap. SonarQube CE is main-branch-only — no `sonar.branch.name`, no PR decoration. The realistic parity counterpart to SonarCloud is Developer Edition, which is paid and self-hosted. CE alone is a genuine workflow downgrade, and we say so before you commit to an edition.
Quality Profile and analyzer drift causes verdict mismatch
Two hosts running different analyzer versions produce "same code, different verdict" tickets that erode trust in both. We treat profiles as code — backup XML committed and reconciled weekly — and pin the same scanner CLI across hosts. The dual-publish window exists precisely to catch this before it bites.
Self-hosting means you own Postgres, Elasticsearch and uptime
SonarQube embeds Elasticsearch and depends on external Postgres; an under-provisioned heap OOM is the number-one ops incident, and upgrades are stop-the-world. There is no managed-availability backstop once SonarCloud is gone. That is why we run it — HA Postgres, sized heaps, a break-glass admin path and a tested DR runbook.
You give up SonarCloud's inherited SOC 2 boundary and continuous updates
Auditors previously accepted SonarSource's SOC 2 as an inherited control, and SonarCloud's analyzers update continuously. Self-hosted means you demonstrate the equivalent controls yourself and upgrade analyzers on your own cadence — which means you also lag new rules until you apply them. We plan an audit cycle of overlap before retiring SonarCloud.
Why this beats a flag day
Reversible per project, soaked before you cancel.
Every gating flip rolls back in under 15 minutes by re-enabling SonarCloud's required status check while both systems are still publishing, so a bad project is a single branch-protection toggle, not an incident. And we never cancel the SonarCloud subscription on a hunch: each project soaks while gating authority sits on self-hosted, then SonarCloud receives no new analyses for at least 30 consecutive days as an evidence window — with the organisation held read-only for audit — before the subscription is cancelled. You are never betting your CI on one big cutover.
See whether your stack needs CE, Developer Edition, or a hybrid.
A call with a senior AppSec engineer. We inventory your projects by language and LoC band, separate the workflows that need branch and PR analysis from the ones CE can serve, and tell you honestly whether self-hosting is a clean parity move or a feature trade — before you commit to an edition.
Map my migration →