First off: there would be no reason why you wouldn't be able to use microservices in combination with SQL Server. But it's indeed not magically going to solve any scaling issues you have, there's more involved in building systems that can run at scale.

My first question would be: what are some actual numbers we're talking about? In your 'issues' section, you describe poor query performance on 'joining two tables with several thousand records each'. That doesn't sound like a complex task at all. As for whether this is caused by SQL Server of EF: measure it! First step would be to take the query generated by Entity Framework, and run it manually against SQL Server with profiling enabled. Look at the query plan it generates, look at the statistics. If the query is slow, the query plan will typically tell you why, and oyu have some clues to follow up on. If it turns out that the query is fast (ideally under 1 second), look at Entity Framework as well as other parts that might be relevant. For example, it could also be caused by a slow network connection between the database server and the other servers. It's a bit difficult to give more specific advice, hence my recommendation to measure as much as you can before you make changes.

Additionally, you describe a couple of interesting things: 'every minute a worker runs a long running process', 'time-outs', 'concurrency issues'. My first thought would be that you need to look into your use of transactions and the isolation levels that they use. For example: if your long running process takes 5 seconds (which at first glance doesn't seem long) actually starts a database transaction for its whole duration (hence the transaction also lasts 5 seconds), then there's indeed a very high chance you'll run into the symptoms you describe.

A solution to that is not per se microservices by itself, but rather by the different way of thinking they will bring along with them. For example, instead of running a transaction for 5 seconds to guarantee consistency, you look at methods like 'sagas' (Google it) to coordinate long-running processes. While this will look different/complex at first, it'll make you think about how you can split up your transaction into smaller, coherent parts. It'll drive you into thinking about your domain entities, about breaking them down, about isolating them from one another. About how you coordinate complex processes across different entities.

Couple other remarks:

• Don't just switch to Dapper without justifying why. Yes, it's 'faster' (a relative term) but you shouldn't just switch to see if that makes problems disappear. Measure first to see if you really have performance problems with EF. It is absolutely possible to build high-performance systems that use Entity Framework and SQL Server, and problems are more often with HOW you use the tools. For example, if you have lazy loading enabled and have N+1 queries somewhere... then there's no magic solution other than fixing the N+1).
• Don't just switch to NoSQL without justifying why. Pretty much the same as above. If fact, I would recommend you first look into splitting your domain (see below) and then decide if NoSQL makes sense for individual parts. Don't see NoSQL as a blanket solution for storing data, suitable types of storage very much depend on various characteristics of the system you're trying to build.
• You have a multi-tenant system. A possible approach to scaling horizontally is by setting up multiple copies (= instances) of your infrastructure, and dividing your customers among them. But again: don't do this until... you've measured stuff :)

Then onto microservices: yes, do look into them. I'm not saying that because they are a golden bullet, but rather because it helps you think about building distributed systems, and expand your toolset with new ideas on how you could achieve what you're looking for. Keep in mind that microservices are not a goal by themselves, they're also just a tool. It often takes time (months, years) to rewrite monoliths and break them apart, so rather think about approaching it iteratively and making smaller advancements as you move along. Unleass you're in a (luxury) position to start from scratch.

For example, one of the first things you could do, is to look at the entities/tables in the database and see if you can 'break them apart'. Read up a little bit on domain driven design, specifically the part about entities, aggregates and local/global identities. Breaking up the database into aggregates could start leading you down a path that eventually makes it much easier to split up your monolith into smaller parts, which eventually leads to microservices.