There is a range of possibilities for a Windows environment (P2P workgroup, domain server, ATS, Terminal Server), but all of them would work fine for 10 users if properly configured.
Most AlphaBasic applications are disk-bound (rather than CPU bound), and rely on shared access to files with some kind of locking scheme. So in choosing a configuration, you should give more consideration to that aspect of performance.
The P2P workgroup is the simplest and probably the cheapest, but has the lowest file I/O performance and the greatest exposure to network problems, particularly if different versions of Windows are in the mix.
A domain server is a step up in terms of overall network reliability, but not a big step in file i/o performance.
The ATSD (A-Shell Telnet Server) and Windows Terminal Server (along with its competitors - Citrix, etc.) put all the CPU and file activity load on the server (as in Linux), but end up giving you much better performance by eliminating all the network file sharing overhead. Given the same hardware, Linux will still be faster, but the point is probably moot given the performance of modern hardware.
If your server is old, tired, or short on memory, ATSD might be a better choice since it has relatively tiny overhead (less than 10 MB per connection), and is probably cheaper. But any decent modern server with 4GB+ of RAM and a quad-core CPU can easily handle 10 Terminal Services connections, and does give more flexibility in client devices.
As for the recompiling, you may not need any, either for the platform change or the A-Shell update. Regarding the platform, the only issue would be if your app had extensions that specifically related to the UNIX environment (e.g., referenced native filespecs, launched native LINUX commands via HOSTEX, etc.) As for the update, the old RUN format is still supported by both the runtime interpreter and the compiler. It's always possible though that in the intervening updates between 4.8 and the current 6.0, some fix, change or enhancement might inadvertently affect your app.
The main compatibility issue that I know of is the switch from octal to decimal for the [p,pn] system in 5.0. (This was done to expand the range of ppns from 255x255 to 999x999, which was important to some developers with large sites subdivided by ppns into companies, departments, profit centers, etc. The change doesn't affect RUN programs per se, unless you used an XCALL to manipulate ppns that stored each as a single binary byte. (Obviously, to handle 999, you need either 2 bytes or a 3 character string.) If unsure whether that might be an issue, you should probably grep your source for XCALLs generate a list of all the different XCALLs you use, which you could either look up in the XCALL reference or send it to us and we can help you review it. (Fortunately it's usually pretty easy to swap out or upgrade such calls, assuming it's even an issue at all.)
Note that you can also download a demo copy and test it out before making a commitment.
