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.
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).