A lot of this is going to depend on the factoring of your classes.
In the work that I do, I try to treat the C++ classes I model as hidden implementation details that I wrap into appropriate C++/CLI classes. For the most part, I can get away with that by having managed interfaces that are NOT particularly granular. When your implementation involves directly implementing every detail of the underlying C++ code, then you'll end up with a very "chatty" interface that will involve a fair amount of cost in managed/unmanaged transitions.
In particular, if your unmanaged C++ classes use stl, especially stl collection types, you will likely find yourself in for an unpleasant surprise when you discover that every iteration through your stl collections involves several managed/unmanaged transitions. I had an image decoder that used stl heavily and it ran like a dog because of that. The obvious fix to put #pragmas around the code that accessed stl types didn't help. What I found that did work was to hide all of that in a handle-based C interface that hid all the C++-isms behind an iron curtain. No stl exposed anywhere meant that it was allowed to exist as unmanaged code.
I think your biggest issue is going to be in how you handle collections (if you use any) as the C++ collection philosophy and the .NET collection philosophy don't match up well. I suspect that you will spend a lot of time mapping .NET collections of adapted classes to your C++ collections of classes/types.
EDIT
Here's a blog article I wrote about this issue some time ago. It uses the managed C++ dialect, not C++/CLI, but the issue is the same.