In addition to the suggestions above, there are a couple of other reasons why the overall coverage numbers reported in VSTS will be different (assuming you're using the standard VS code coverage tool and haven't provided any special configuration).
The default behaviour of the VS code coverage tool is to include the test code when calculating the coverage numbers i.e. the number reported in VSTS is the coverage of [test code + product code], whereas the figure reported in SonarQube only takes into account the product code.
So if VS reports an overall coverage number of, say 80%, it means that 80% of your lines of [test + product] code are being executed. However, it's normally the case that almost all of your test code is being executed, so the code coverage on your test code is likely to be higher than 80%, which means the code coverage on your product code will be less than the 80% reported (the last time I analysed a VS code coverage report for a solution in detail, the coverage on product code turned out to be 10% lower than the summary figure reported by the build).
In addition, the VS coverage numbers will also include assemblies that are not part of your solution if the pdb files are available (I'm looking at an example of a coverage report that includes the third-party fluentassertions.core.dll and fluentassertions.dll assemblies, both of which are showing as >95% not covered).
VSTS makes it very easy to set up collecting code coverage - you just click a checkbox in the build definition, and the number appears on the build summary page. Intuitively, you might expect this number to be the coverage of your product code (which is what SonarQube shows). However, it almost certainly isn't the case out of the box. The inclusion of test code will tend to skew the number upwards, whereas any third-party assemblies with pdbs that have been included will tend to skew the number downwards.
If you want to see exactly which projects and assemblies are included in the coverage report the simplest thing to do is download it by clicking on the build summary page and open it up in VS.
It is possible to change the default VS behaviour to get the coverage on product code, but it's not particularly straightforward. See Customize code coverage analysis on MSDN for more information.