I wouldn't create a new portal site for each workspace. You have a group workspace you mentioned and that really aligns to the main portal site. Each separate workspace you have now (Finance, Marketing, Sales, etc.) would be a site underneath the main portal site. You can either use the team site template or construct your own and then add each department through the Site directory. This way your users can search the sites at the portal level and navigate down to the one they're looking for. We have a similar setup here with 150 projects under one workspace in V1 that I'm migrating to a single portal site with 150 team sites (customized) for each project.

You may want to look at the CorasWorks webparts and/or project workplace (www.corasworks.net) as they allow you to put a navigation tree on the main portal site and will let your users navigate down (up to 10 levels) so if you have a lot of depth you might want to consider this as it eliminates the need to know what site belongs to what parent site (if you have multiple levels).

As for accessing via web folders vs web, you'll find with SPS 2003 that the web is very fast thanks to ASP.NET.

Hope that helps.

You can have different virtual directories share the same port number but they must have a different “host header.” This means that you need to assign a different DNS entry/URL for each. I use a mechanism like firstportal.mydomain.com, secondport.mydomain.com, etc. Which isn’t too different from what you were doing before which was probably mydomain.com/firstportal, etc. The only downside to this new approach is that you have to coordinate it with the DNS. You can either have the machine run DNS or you can have the upstream DNS have both of these point to the same IP address. Either way, when the HTTP request gets to IIS, it will direct it to the correct web site.

I don’t know if there are any hard coded limitations on the number of portals, but there are certainly practical ones depending upon the numbers of users and power of the machine.

Yes, all document libraries are exposed automatically as what MS used to call web folders and now seems to refer to as network locations or network places. There is also WebDAV support.

Good luck with the migration.

I really don’t want to sound harsh here, but you are *not ready* to migrate to SPS 2003.

One of the large problems in learning 2003 is *unlearning* 2001 concepts. About the only similarity between 2001 and 2003 is the name and some of the search components. If you don’t understand the 2003 concepts and if you have not mapped out your taxonomy for 2003 using 2003 features and components, then your migration *will* fail. You are *much* better off to wait 4-6 months, get some training, run a pilot of 2003, etc….. and then migrate. I *seriously* advise against a migration for you until you have a good working understanding of SPS 2003.

I recall reading Microsoft documentation that stated IIS 5 will
support a maximum of 10,000 websites but the documentation did
not make the explicit distinction with regard to the hard-coded
maximum or its relevance to processor and related system resources.
The document did explain that IIS 6 would far exceed that maximum
but did not provide an explicit number.

As there was no explicit discussion regarding performance
degradation with regard to a 10th, a 100th, or a 10,000th
site I've concluded that the maximum discussed in that document
referred to an explicitly hard-coded maximum which pragmatically
speaking can be considered consistent with other hard-coded
maximums we encounter when using Microsoft's products.

I support my conclusion having tested other maximums, i.e.
Small Business Server (50 concurrent users), Windows 2000 Pro
(10 concurrent users) and so on. When reaching the stated
maximums an error message is displayed.

Those maximums were low and rather easy to test. Can my
conclusion while logically faulty be relied on to make
practical decisions?

On the basis of the indisputable facts that Microsoft does
impose hard-coded maximums into its products I would say yes,
the conclusion while logically faulty due to lack of explicit
testing does provide sufficiently reliable indication that
there is indeed a maximum number of sites a SPS implementation
may deploy. That number is at least 10,000.