It depends on how seriously you're considering moving to Azure and how soon. If you are, then I'd say yes.
Unfortunately, the idea of being able to write once run anywhere is a bit of a pipe dream. The concept of abstracting everything away just doesn't work if the platform limits your architecture choices - and nearly every platform does. Even if you can choose your data persistence technology for example, you're almost guaranteed to run into an impedance mismatch problem at some point that will affect your design.
So in Azure's case there are a number of issues you'll need to think about.
Firstly, no MSMQ or Velocity at this stage. Azure has it's own queueing component that has more of a passive model (poll for messages, no routing, etc), so you may be able to use that, but it's not transactional in the same way that MSMQ is, and you'll need to ensure all messages are idempotent. Distributed caching is on it's way I believe, but it's not there yet (and may not be Velocity).
Secondly, you can either choose Azure's Table Storage or SQL Azure Database for your table-like persistence. Which one you choose probably depends on where you scale pain points are. The easiest option would be to go the SQL route, but there are certain limitations there with DB size, and you won't be able to use many of the services around SQL Server, like the job agent, dependencies (for cache callbacks), etc. And if you're running into issues where SQL Server isn't scaling, then running in the cloud isn't likely to help much, just by the fact that it's still an RDBMS. If you want a more scalable solution, then Azure Table Storage is your man - but it's non-relational and you'll need to modify your architecture to accommodate the more limited scope of transactions that it supports - as well as the inherent limitations of its querying mechanism and latency of the REST-HTTP architecture. Think BASE, not ACID.
Thirdly, you'll need to think about file storage differently. As each of your instances is running in a VM, any local storage disappears when the VM shuts down, so for long term persistence, you'll need to use Azure Blob Storage and design your app keeping that in mind.
Fourthly, you've got a choice of two types of roles - web roles, running IIS (that you currently have no control of, in terms of tweaking IIS parameters) and worker roles, which are more like windows services. And there's no mechanism for your roles to be aware of each other - so communication from web to worker happens via the queues, or table/blob storage. So you'll need to keep this in mind too.
So all up, lots of design decisions will need to be made if you want to move to Azure - the platform, by it's very nature, limits what technologies you can use, and therefore what design options are open to you. If you do design with Azure in mind, then you will end up with a more inherently scalable system, but there are certain decisions that need to made along the way - and some may be deal breakers.
[Edit: I should add that this answer is more aimed at the consideration of moving your entire app to Azure. This, of course, isn't the only option - you might want to only move certain components to the cloud and keep the rest on-premise, interacting using something like Azure .NET Service Bus for example]