Is my mssql 2008 standard suitable for web edition 2014 A web edition seems enough for me when I read this.

I thought it had a 2gb size limit before? I have three databases our current db and am not doing anything fancy. Just some server agent jobs from http://ola.hallengren.com 
This is our current db:


  Microsoft SQL Server 2008 (SP3) - 10.0.5538.0 (X64)   Apr  3 2015 14:50:02   Copyright (c) 1988-2008 Microsoft Corporation  Standard Edition (64-bit) on Windows NT 6.1  (Build 7601: Service Pack 1) (VM) 


output of exec sp_spaceused
db1:


database_size 1355.81 MB  
unallocated space 264.66 MB
reserved 758112 KB
data 647008 KB
index_size 105536 KB
unused 5568 KB


db2: 


database_size 3141.25 MB
unallocated space 146.16 MB
reserved 1955672 KB
data 1725656 KB
index_size 216800 KB
unused 13216 KB


db3: (can be removed I hope) and seems similar to db2

it all runs on an xeon e5-2650 v3 @2.3ghz (4 cpu's) and 8gb ram. So I thought that a D2 on azure will perhaps be similar and a web edition of sql 2014.
(west Europe)
https://azure.microsoft.com/en-us/pricing/details/virtual-machines/#Windows
or is it recommended to move away from running a sql server on a vm and towards hosted sql. https://azure.microsoft.com/en-us/pricing/details/sql-database/
Web edition looks like Standard edition except "It is only available through an SPLA" going by the specs listed in the article you linked to.

With regard to a 2Gb limit, are you thinking about Express edition (or MSDE as it was called pre 2005)? That has had a per database size limit of 10Gb since SQL2008R2 (it was 4Gb in 2008 and 2005 and 2Gb in 2000 &amp; SQL7). Note that is is per-database and data files only, so you could have several databases each under 10Gb that consume much more than 10Gb in total, and log files don't count towards the total. The key limit on Express is that it won't use more than 1Gb of RAM per instance which will limit performance for large data. You can mitigate this a little by running multiple instances. So running Express in a VM may be suitable for your needs and the least hassle option as you don;t have to worry about differences between SQLServer .

I don't have much experience with Azure SQL so I can't comment in any detail on the relative suitability of that for your needs. There are some differences in what is supported so you'll need to find documentation on that and test any potentially affected parts of your application. Be ware of which resources you use for this research: there have been many changes recently so articles form a couple of years ago may be pretty much irrelevant. See this SO question and other similar recent questions for potentially useful references. As well as feature compatibility you'll need to judge the performance requirements of your app against the "Database Throughput Units" (and therefore the cost) of the account types you are looking at, see this MS page for more details about the performance specs for each service tier.