Hey Colin, congratulations on making the move!
(1) My first advice, though, would be to be prepared for a lot of pain. A lot of .NET is really, really nice, but it is a LOT to learn before you will be able to use it in the workplace. If you try and roll it out too fast, your productivity will plummet, and you will get fired -- I promise you.
So be warned.
I am very serious.
That said, you have to start somewhere, so kicking around code on the side and using it for your own projects at first will get you up to speed. When you are ready, you will be able to use it in the workplace.
If you are using Automation -- as opposed to making an in-process add-in -- the first problem you will hit will be the "hanging Excel application" issue. You should have a read of the Automating Office Programs with VB.NET
tutorial to help get you started.
(2) I would also advise you to stick with VB.NET, at least for a while. Do NOT be tempted by C#, at least not within your first year or more of .NET development. For what it's worth, I have switched over to C#, and I do prefer it, but for your first year or so development will find it very, very convenient to be able to copy paste code from VBA to/from VB.NET or back. The copy paste will not be 100% viable, but close, with only a little bit of tweaking, the code is essentially identical. To be honest, there may never be a reason to switch over to C#, VB.NET really is much better designed for working with Microsoft Office products such as Excel.
(3) You will need a good VB.NET book in addition to the VSTO book. There is an outstanding VB.NET book by Paul Vick that I think is the best place to start. If you want to get more advanced in VB.NET then look for books by Francesco Balena (but I would start with Paul Vick).
The "VSTO For Mere Mortals" book you mentioned is an outstanding book on VSTO, I highly recommend it.
Also if you don't have it, get the Bullen/Green/Alexander "Excel 2007 VBA" book. It does not touch .NET, but it is the best darned Excel VBA book on the planet, and it has been very nicely updated for Excel 2007.
(4) This is just my opinion, but I think you should think of your development as being (a) Excel 2003 and below versus (b) Excel 2007 and above. The object models are so different with respect to using the CommandBars in Excel 2003 and below versus the Ribbon in Excel 2007 above that you really have to think about them this way.
I know that using .NET tends to make one think in terms of Excel 2003 and above (or maybe Excel 2002 and above in some cases), but this is not a good way to view it.
(5) The next thing to think about is what current solutions you're making will drive the decision about using .NET versus using VSTO -- they are not necessarily the same thing. For example, I have yet to use VSTO to any great degree, but it will be shortly. VSTO's main advantages are the following:
(a) A drag-and-drop Ribbon visual designer that allows you to create a custom Ribbon solution without even having to touch any XML code.
(b) Allows you to utilize standard .NET forms controls within an Excel worksheet.
That's it. But these are big, if you need them.
For me, the second issue is not very important -- I am perfectly happy using standard ActiveX controls on the worksheet, and I very rarely use these kinds of visible-workbook solutions in any case. (I mostly make add-ins that only show their presence through toolbar controls and menus and never display any worksheet or workbook to the user.)
So, for me, the only real reason to use VSTO is to be able to make use of the drag-and-drop Ribbon visual designer -- but for this alone it is worth it. This also means that I will only be using VSTO for Excel 2007 solutions and above, I have no use for it otherwise, and VSTO is not really compatible with versions below Excel 2003.
So I am using .NET for all versions of Excel, but I am only using VSTO for Excel 2007 and above. I also use a smattering of VBA and VB 6.0 in all versions as well -- sometimes these "older" technologies are still useful and can execute far faster, because they do not have to work through the .NET Interop. That is, they execute as COM add-ins natively. Where speed counts, VBA and VB 6.0 is still the way to go.
I hope this helps Colin! This is a very long road... but what I hope you find to be rewarding.