Upgrade from 7.3 to 7.9.2: Database migration failed (no projects on dashboard)

SonarQube 7.9.2
PostgreSQL 9.5.

Trying to upgrade SonarQube to an LTS version and cannot import old data.
Every time we run SonarQube 7.9.2 against our data from 7.3, whole tables are left empty (e.g. projects).

The process:

  • SonarQube 7.3: use pg_dump to create a .sql dump file
  • SonarQube 7.9.2: import the .sql file (psql < /dumpfile.sql) - psql: import succeeds
  • (re)Start SonarQube 7.9.2 (sudo service sonar start) - psql: data is wiped before the server comes up completely


  • Dashboard shows 0 projects
  • Some tables are now empty (e.g. projects)
  • Note: SonarQube still runs fine

We couldn’t find anything off in the postgres logs, nor in the sonar.log file.
We believe this might be a DBCleaner but we have not yet understood why this is happening.

Has anyone else seen this? Any thoughts on what might be happening here?

tl;dr Starting SonarQube 7.9.2 wipes out SonarQube 7.3 data


Welcome to the community!

Your procedure is non-standard. Normally you would dump to a backup just in case and then upgrade the DB you dumped from.

Assuming you have a really compelling reason to do it in that non-standard way (do you?):
After you’ve done the import, you should start by pointing your 7.3 at that DB (wiping out that instance’s ES data) & spinning it up. That lets you verify the import. Only then would I do the upgrade to 7.9.2.


1 Like

Hi Ann,

Thanks for your reply.

We are aware our procedure may not be the standard one, but we choose to do so only to smooth the transition between versions of SonarQube as much as possible.
While our production env is running, we spawn a new instance and install a newer version of SonarQube on it. We then import our data and run it. Only when we’ve confirmed all the data has made it through and that checks are running as expected, do we configure our URLs to point at the new instance.

I’d say we’d rather stay with this procedure so long as it doesn’t interfere with basic SQ functionality (this case, for example).

I’ll take your advice to the team and maybe try to point our 7.3 instance to the new DB. Not sure this goes well with our will to make this a smooth transition (it involves much more downtime, IMO).

Any other suggestions perhaps?

I think I found the issue: we set currentSchema to the wrong schema. It should’ve remained public. The data now stays put, even after the server is started.