It's hard to give you good strategy information without knowing more about your application architecture. I would recommend that you attempt a pilot project first with a piece of your current application or with a new feature to get your implementation team and your architect (or lead designer, or your most trusted tech guru) up to speed on the .NET. There is nothing like a *real* project to help crystallize your understanding of new technologies. I would also recommend that you run your full process on your .NET pilot. Specifically, write your specs, do formal design, design reviews, QA, acceptance testing, etc. In doing this you will get the best understanding of how this new framework will impact all aspects of your development organization.
At that point, you should be in a better position to understand your migration strategy. The nice thing about XML, Web services architectures and Microsoft's .NET is that you have powerful tools to help out with sticky legacy issues. In particular, you can take an approach that wraps critical pieces of your existing technologies as XML enabled application components and integrate these with your new .NET work without physically having to port all of your old code.
With what little I know about your project I can't give you too many specific instructions but I can give the following advice. Pick a small aspect to implement in your new technology and then attempt to implement it "formally". Follow all your current process and see what breaks. This is in comparison to running a side project to understand the technology. A "side project" will give your technology people an understanding of what's what but you will not understand the broad-reaching impacts that new technology has on everything from coding conventions to QA unit testing to design idioms and so forth.
Dig Deeper on Topics Archive
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.