The three points you listed seem fair: > It is a fairly important project so it has to work - a C# solution would not be as stable or work as well as the existing a VBA-based solution. Indeed, later, you tell: "I would like to take this opportunity brush up on my C# skills as **I am currently not as competent in C# as I am VBA**" (emphasis mine). In other words, you have a solution which works and went through intensive user testing. You want to throw all this and rewrite everything in a language you don't know well. See the problem? > We would have to throw away what we [I] had done in the VBA solution and recreate it from scratch in C#. [Things You Should Never Do][1] comes to mind. You are throwing the code, as well as the user testing. Not a good thing. > Someone will have to support two separate solutions, one in VBA and one in C#. [actually, they currently do not have anyone for support, I usually step in]. If the VBA version would still be used, the rewrite is indeed even more problematic. Why would you have two disparate systems which require your attention, when you may have only one which already works and which you can refactor and add features to? --- Some of your points, on the other hand, can be criticized: - **Unit testing.** [You can unit test your current project as well.][2] If there is no convenient framework for that, create one. - **Source control.** Source control deals with text. Your current code is text, therefore you can use source control for it. The language, the operating system, the framework or the ecosystem are completely irrelevant. You can (and should) use source control for any code you write: code in Visual Studio, or a piece of code you draft in a few minutes in LINQPad, or PowerShell scripts which automate a task, [or database schema][3], or Excel macros. - **Code documentation - for knowledge transfer to other support persons.** Agreed. - **Better coding conventions - can use things like ReSharper to enforce better naming and structure.** Define "better". Are there coding conventions for Excel's macros? If yes, use them: they are not better or worse than any other. If not, create ones and publish them so that other people can use them too. [The answers to a question posted in 2010][4] seem rather disappointing, but there may be new tools available since then. Note that the important part of coding conventions is that they should be enforced on commit. - **Better IDE - fewer mistakes due to error highlighting.** Agreed. The fact that [we can't write macros in Visual Studio][5] is very unfortunate. - **More modularity through assemblies - can promote re-use in future tools.** I'm pretty sure your current product can use some degree of modularity as well. - **Managed deployment - can control who this tool is used by.** Agreed. --- Instead of a complete rewrite, you might search for a way to **progressively** move code from the macro to an ordinary assembly written in VB.NET. Why in VB.NET? Three reasons: - There is no much difference between C# and VB.NET. - *You* know VBA better, and this alone is a good reason to use VB.NET instead of C#. If you want to "brush up on your C# skills", do it with your personal projects, not business critical stuff. - Any rewrite from a language to another leads to potential bugs. You don't need that for this project. Moving to a .NET assembly can give you the convenient environment of Visual Studio, with the convenient unit testing, TFS and error highlighting you currently use in other projects. At the same time, if you move your code step by step, you don't take the risk of a complete rewrite (i.e. spending four months creating something nobody wants to use because the high number of new bugs). For instance, you need to work on a specific feature? Think how you can move this particular feature to .NET first. This is quite similar to refactoring. Instead of rewriting the whole thing because you learnt some new design patterns and language features, you simply do small changes on the code on which you work right now. [1]: http://www.joelonsoftware.com/articles/fog0000000069.html [2]: http://stackoverflow.com/q/1792188/240613 [3]: http://blog.codinghorror.com/is-your-database-under-version-control/ [4]: http://stackoverflow.com/q/2131350/240613 [5]: http://stackoverflow.com/a/23173972/240613