>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.

Take an average of all the table sizes added together for a single customer and multiply by the number of customers. That will at least give you a ballpark # for the database size. Then figure out how much data is added per year per customer and multiple that by the # of customers times a few years of data to give yourself some breathing room. Double it - that's about how much space you'll probably want for the DB.

>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.

If it's hosted at your location realize you're going to have a single point of failure (your location itself). You might want to have an offsite DB/Web server that you back up to (you can use scripts and log shipping to do something like this). Plus a tape backup to backup your primary site.

>
>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.

Bandwidth and true hardware requirements are just going to be a guess w/o real metrics from a real application. But if you're just using this as a ballpark budget, you'll probably want at least 3 web servers (2 at one location, 1 at offsite), 2 database servers (one inhouse, one offsite), maybe a bit more modest box for the load balancer (assuming PC based), otherwise a load balancing router. A good quad-core box with RAID and 4-8 GB of RAM should be decent for most traffic loads.

Bandwidth is harder to gauge. (hopefully I get the math right here). How many users per site? How many users at the same time per site? Are they using it all day long?

For example, if you have fairly heavy pages that are, on average 500K and expect a max of 10 hits/second (pulled that number out the air) that's 5MB of bandwidth needed. A T1 will give you 1.54 MB/second. So you'll probably want something like 5 or 6 bonded T1's to be able to handle the traffic load (which would give you approx. 35-50% of headroom).

As a side note: don't underestimate the required development time - there are a lot of metaphors used in desktop apps. that don't translate well to the web and w/200 tables it sounds like a moderately complex system, probably a ton of reports, etc. that need to be modified. You also need to decide if you want a diff. database per customer, or one database for all of them (there are tradeoffs with each approach).