>Thank you guys for your response.
>
>I'll try to give you a little more background info of what we've got and where we are wanting to go with it. We currently have an app written in VFP that uses roughly 200 related tables in its database. We have roughly 350 different locations using this program individually and housing the database(s) at their location(s). The size varies on each table considerably. We have tables ranging from 1KB to 30MB in size for each of the 200 tables.
>
>Now, what we're wanting to do is centralize all of this data from the 350 locations and house it at our location. Then we want to write a web app. that has the same functions as our program that is in place now. This will give them all of the flexibility they previously had and the convenience of it being over the web, plus we will be housing the data so it will be safe and secure. We would like to use a SQL backend for this web app. to work with these tables that are in place. We know that we might have to change the structure of our tables drastically and we will probably sub-contract the job of creating this web app. Then, we would pick up on maintaining it from there on out.
>
>We just need some ideas for servers, other hardware and load balancing scenarios that we would need to make this application fully functional for all of our locations to use at the exact same time.

Hardware is cheap, and getting cheaper all the time. You'll probably find hardware costs are only 10-20% of the total cost of the project. I don't think you can go/no go a project based just on hardware costs, which you won't really know until you know the software platform you'll be using, and its size and data/bandwidth requirements.

What you're proposing is a major change from your current VFP app. The approach I'd take would be:

- create and issue an RFP
- either before or after getting RFP replies, qualify contenders based on projects your size or larger they have previously successfully completed (i.e. check references)
- based on that, you may end up with several possible options e.g.

- Python/Django or Ruby/Ruby on Rails, on LAMP
- ASP.NET on the MS stack
- Amazon EC2 ( http://aws.amazon.com/ec2/ ) - with this option you don't need any hardware infrastructure at all

If you choose an option that requires your own infrastructure, I'd be inclined to set up a single relatively low-cost, commodity, name-brand server from the likes of Dell, HP or IBM:

- for really low cost you could go single socket with a 4 core processor and 8GB RAM, better might be dual-socket with 2x 4-core processors (8 cores total) and at least 16GB RAM, especially if you're planning to virtualize servers via VMWare, Hyper-V etc. I'd use 64-bit software wherever possible.

- disk tends to be a bottleneck on loaded servers (especially database servers). Don't skimp there - get a chassis that can accept at least 8 physical drives (3.5", or 2.5" enterprise, 10K or 15K rpm), SAS interface preferred. You shouldn't need solid-state drives initially. You may find a rack-mount solution, with separate chassis for server and disk arrays works better than a single large server case that holds both the server board and drives. In production you may want to go with a SAN for performance and availability but you don't need to start with its expense and complexity.

- a separate, dedicated high-speed Internet connection for this server. You will probably also want to invest in a hosting-grade router such as SonicWall or Cisco

A single server such as the above can handle all of the software components needed for development and test. As the app is developed, you can gradually open it up to some of your preferred clients. Monitoring this machine, with a few users, can give you a good idea of the performance you'll need. When you factor in high availability, redundancy, backup, and scalability, you'll arrive at the hardware you'll need. The prior experience of your chosen partner will help here.

Another possibility for either development or production is to have someone else host your server(s) e.g. RackSpace. These server(s) can be virtual, dedicated or co-located.