I ported a couple of projects. The first was a C to C++ conversion of an open-source project. Primarily for future maintainability and quality gains. This wa

I ported a couple of projects. The first was a C to C++ conversion of an open-source project. Primarily for future maintainability and quality gains. This was on the smaller side, and it took a few weeks only. It had the advantage of being possible to convert piecemeal. Once I got the C code building with the C++ compiler, the code could be rapidly refactored to use C++ classes, smart pointers etc very easily, and the testsuite could be run every step of the way, so the conversion was not very risky (I found and fixed some small logic bugs the C compiler hadn't picked up as the code became more type safe). Straightforward and trouble-free. The second was a big conversion of a large decade+-old Java codebase to C++. This was an academic open-source codebase, where the consortium maintaining the codebase got a grant to provide a C++ equivalent to the Java version. This took around 18 months for the core part of the codebase, including major updates to a complex code generator from a large data model, and I worked on it for about 6.5 years in total to varying degrees over that time. My experience of the second was not as good as it might have been. The sheer scale of the work was, in retrospect, too much for one person. The nature of academic grants and the project goals were a bit in conflict with providing a good quality solution within the desired timeframe. One of the problems here was that due to the difference in the languages, the work could not be done incrementally--the system wouldn't be functional until the vast majority of the work was done. The other was the requirement to do a direct 1:1 port of the Java interfaces and classes; this made the porting more difficult and created interfaces with Java-isms which made it less pleasant to use from the perspective of a C++ developer. We did get a working solution in the end, which was almost completely compatible with the original implementation, but it came with some compromises. Before you start doing any work, I'd suggest spending a decent amount of time investigating and planning. It will reap dividends, and will let you properly understand the costs and tradeoffs of the various approaches you could take. Based on my previous work, I'd suggest asking these questions: - Do you need to port everything? Ignore the code and go back to the requirements. Which functionality is strictly necessary to meet those requirements? Which interfaces and implementations are needed by the users, and which are internal details which could be implemented differently or dropped entirely? In my case, some of the difficulties were due to a lack of detailed written-down product requirements, which made answering these questions impossible, and we ended up porting the whole implementation effectively line-for-line to ensure 100% compatibility with identical behaviour. - Can you access code written in the old language from the new language? Is it possible to wrap the old code so you can port bits incrementally? Or even leave whole parts untouched? - Make sure you've looked at the totality of what needs porting, not forgetting unit and integration tests. Also factor in needed third-party libraries; are there equivalents for your new language, or will you have to port them over as well? Look at all transitive dependencies, you might have some nasty surprises which will ruin your estimates. - Look at alternatives to porting. Can you do automated code translation? - Look at where language differences can have significant impacts upon the APIs. For example, Java GC vs C++ where I had to approximate it with smartpointers, because the whole codebase was written with the assumption of GC in mind. Likewise Java enum classes. In retrospect, if I'd had the flexibility to do so, I could have replaced ~90% of the Java code with an in-memory SQLite database and the end user would have been none the wiser. It would have eliminated a lot of the porting costs at a stroke. - What is the true cost:benefit of doing the port? Maybe the cost (once you've properly planned and estimated it) is too great. - What risks are you introducing by doing the port? Not just bugs and behaviour changes, but risks to the company if it can't be delivered on schedule with the available resources. That's just to start. Overall, just be sure this is the right path before committing to it, because it can be very costly.