Me too! Dislike the Ribbon-UI introduced in Office 2007. Don't care much for any of the new features (except spark-lines in Excel, *sigh*). 2003 can read / write later versions' XML-based fileTypes docx / xlsx / etc. albeit only after installing the Compatibility-pack-update. But the main benefit, the icing on the cake: Starting ye olde Excel 2003 takes as little time as starting the calculator or notepad :-) While even on a very powerful, up-to-date PC with NVMe-SSD, many cores and all bells and whistles starting one of the later MS Office programs takes forever, thanks to all the bloat (and animated splash-screens and stuff). Current LibreOffice isn't much better either in that respect.

I'm currently in the last phase of converting a ~250.000 line project from VBA (!) to C# and I agree that re-writing it as a functional clone would have been the better way. But here is how I did it: 1. VBA -> VB6 (not your issue but included for completeness' sake) - acquire and run an old VB6-IDE - import/convert VBA-project - fix compile-errors 2. VB6 -> VB.NET - acquire and run an old version of VisualStudio (those still had a converter for legacy-VB6! I think I used 2005) - import/convert VB6-project - fix compile-errors -> now we're in .NET-wonderland! 3. VB.NET -> C# - run an old version of "SharpDevelop" (I used v4.4 - as far as I know the feature in question was removed in v5!) - open/import VisualStudios VB.NET-project - convert to C# - open/import in VisualStudio - fix compile-errors -> now the code-base is where it's supposed to be - in C# and in VisualStudio! During these conversion-steps I often treated the codeFiles not only within the respective IDE but also as "normal" text-files in . For that phase I recommend - EditPad (for the actual search-and-replace-stuff) - Agent Ransack (for identifying the codeFiles in need tampering) - and a good and healthy dose of regEx! When arrived in VisualStudio I recommend - StyleCop - ReSharper They both are very good at spotting code-habits that stem from VBA/6 and were simply converted! Fixing the (comparatively few) comile-errors introduced in each conversion-step didn't take too much time / effort. - the vast majority of those were of the same few types and quite simple to fix. Again: freshing-up on regEx is highly recommended :-) - Most time went into replacing some filthy VBA/6-only stuff that doesn't have an 1:1 equivalent in C# (for good reasons). But this kind of code needed re-writing either way. But: While the outlined approach worked very well and took surprisingly little time, the actual work is then only starting :-( - yes, VBA/6 and C# do stuff in different ways - and they especially lack a lot of C#s capabilities so the resulting code - while working - is almost always very clunky, verbose and un-elegant I repeat: looking back, re-writing the code as functional clone would have been the better way! Perhaps there is a middle way: convert the old code to have some kind of quarry for quickly looking up / copying old algorithms where necessary (without having to do the same steps of syntax-conversion over and over again)...?