>>>The customer does have multiple locations. As far as whether it will be one SQL Server database or each site will have its own, not yet decided. I want to stay away from replication since I don't know how it is done and don't have the experience. We just had a conference call to just have a preliminary discussion. I would like it to be as simple as possible.
>>
>>Hmm... if fundamental things such as shared vs separate SQL Server databases have not yet been decided then IMO it's too early to discuss low-level details. Regarding bandwidth and latency, just try to minimize traffic over slow WAN (Internet) links. When discussing bandwidth in this kind of situation, remember that uplink speed is often more important than downlink, but often it's slower on asymmetric connections such as DSL or cable e.g. 60Mbps down/12Mbps up.
>>
>>If everyone has separate SQL databases, and you can use a loader approach as Thomas suggests, do you even need to have a shared server VM at all? EXE and metadata updates could be on a web or FTP site instead.
>
>First, thank you for some numbers.
>
>You see, each site will only need to see their one data. So if I combine all sites into one database I will still logically separate them (by site ID). But I need some time to work on this approach and they (the customer) may not give me the time.
>So, my preference would be to have a separate VM for each site, with the exe and meta data, as well as a copy of the SQL Server.
>Then, I will just need to devise an approach if the corporate wants to see some combine reports, pulling some summary data across all databases.

In that case it sounds to me like the "simplest" solution would be to have a server with your app components on-site at each location. That server could be a VM or a physical computer.

It's only if you are contemplating hosting your app off-site from the individual offices, that you need to worry about bandwidth, whether you should be looking into RDS etc.