The body of available native code is extensive. It will be awhile before the breadth of managed code nears that of native code. Until then, there will be plenty of opportunities to port native code to manage code. Regardless of the level of familiarity with the native code, port the native to managed code as new code. It does not matter how many times the native version has been tested and deployed. Don’t automatically trust that code. What worked in Microsoft C++ or Visual Basic 6 may not work well in the managed environment. This is particularly true about any code that involves memory management since that responsibility is now delegated to the Common Language Runtime (CLR).
All ported code should undergo the same rigorous testing as any other code. You should then run regression tests to confirm the health of the overall application after assimilating the ported code. Test not trust is the perfect policy when porting native code.
Furthermore, ported code often requires an extensive rewrite and may retain only a few vestiges of the original native code. Treat that code accordingly. It is not so much ported code but new code. As such, porting code to the managed environment is much more than translating individual lines of code. You are also changing the programming model and environment. That might necessitate other changes. Keeping the old programming model is a sure way to introduce the new code and a handful of software bugs to your application.
