Doc's Vision for the OGFB Site

Below are my brief thoughts on both your unconditional and preferred requrements.

Unconditional Requirements:

1. Horizontal and Side Bar Navigation (Initially - the members like it) - I use a menu module called Nice Menus which creates its own menu blocks available to include in any theme region.  There is CSS involved to adjust the backgrounds, colors, etc.  The module provides an option for horizontal (navbar menus) and vertical (sidebar menus).  The difference is that the horizontal menus pop out below the selected menu item and the vertical menus pop out either to the left or right of the menus.
2. Forum Topics and Replies to be maintained - Forum topics, in Drupal, are simply nodes and the replies are comments.  What differentiates a forum in Drupal is the additional functionality provided to the nodes and comments via a Forum Module delivered with Drupal.  I extend the standard Forum Module with the Advanced Forum Module and the Advanced Forum Module and the Author Pane Module.  Advanced Forum adds some navigation and styling goodies and the Author Pane provides the box with the profile picture and user stats in topics and replies.  Most of the SP forum data should be able to be preserved.  It should be noted that if you have private or semi-private forums, you might consider moving those to another custom content type since I use Groups for that kind of security and the Groups/Forum module (which implements Forums into Groups keeps reporting conflicts.
3. The Gallery images and comments maintained in their category/sub-cat order together with the existing underlying directory structure. A lot of the images in the gallery are referenced/shown within the forum topics - The Gallery category/sub-cat order is maintained via Taxonomy.  This will either need to be monitored during conversion, or perhaps manually established prior to conversion.  In terms of the location of gallery images, this is a little tricky.  If memory serves me correctly, there are 2 URLs stored for SP images; standard image url and thumbnail url.  These are complete URLS including the "http://" and the server name.  Drupal stores relative URLs (which makes migrating a site much easier).  This can be handled via the directories that established for image upload.  It might not be the most efficient or optimum structure, but it can be reproduced.  This would probably be necessary for URLs stored in the content within the database.  We'll have to look at possibly running a SQL updtae to remove the http://www.oneguy... part of the URL in the node descriptions once the data is ported to make it easier to migrate in the future.
4. The Members details kept (Except Passwords) - The User Profile Module delivered with Drupal contains very basic profile data.  It also provides a mechanism to create custom fields for a profile.  Everything that's captured via the SP profile is doable in Drupal.  The fields need to be created and then the import can simply map SP profile fields to those of the Profile Module.
5. Fast Search capability ( I currently have full text indexing on my MSSQL database and it is fast) - Drupal's search is robust, fast, and has a mechanism to cache searches which really speeds up searches after inital search.  It also provides a search string report to tell you what people are searching for.

Preferable Requirements:

1. To maintain exsisting Search Engine URL's pointing to various forum topics (I don't think this is possible though) - Ah but it is.  This is where the awesome Pathauto module comes into play.  You can even keep the '.asp' extensions if you desire!
2. To integrate the PHP based IBProArcade games module - We'll keep this on the radar.  Maybe this will become a community developed custom module.
3. Incorporate the Articles (Around 150 approx) into a suitable Drupal container/module - Easy.  Again, we'll need to port category/subcategories as Taxonomies, but this should be straight forward.
4. Incorporate the Sites SP Links Module into a Drupal container/module - See 4.
5. Calendar /Events Module - This will require the attention of someone who has had experience with the SP Calendar Events module. 

New Features Wish List:

1. Groups - See this site.
2. Books - Se this site.
3. Taxonomy - Used extensively on this site.  It will allow you to go n-deep.
4. Advertising - There's a great Ad Module which handles ads ranging from very simple like I have on this site to complex affilate ad linking and tracking.
5. Donations - Probably a piece of custom HTML you'd manually place in a manually created block.
6. Database backup - LOVE the Backup and Restore module!
7. Mobile compatable - Headed there right now with this site.  I'm blowing off the notion of browser detection since the browsers change more often than the browsecap releases.  I plan to handle mobile versions as a sub-site with a very specifiic limited mobile-friendly theme using the same data as the main site.  a URL of mobile.oneguy... would be set up to point to it.  This way, you have both main and mobile sites keying off the same data.  The only difference is the presentation.  Keep in mind that most Drupal modules that use heavy client-side javascript are built to degrade nicely to simple html when client-side javascript is not detected.

The only thing that you didn't mention in your requirements is what you'd like the site to actually look like.  I've used the Genesis Theme to create this site's theme (as a sub-theme).  It's really conducive to a SP look and feel.  You currently have a bunch of SP themes on your site with the Theme Changer block enabled.  These themes don't just grow overnight ;)  Is there any one in particular that you'd like to use as a starter?