By Ghulam Nabi Shah | October 7th, 2015 |
Migrating from Visual FoxPro to .NET requires a solid strategy, effort, and a well trained and skilled implementation team. Macrosoft has completed quite a number of successful migrations to .NET. When converting from VFP to .NET, knowing what to plan for is just as important as knowing what to avoid. One missed step could mean months of additional work. We don’t want that to happen to you so here are 5 common mistakes and how to avoid them when converting Visual FoxPro to .NET.
1. Not all project stakeholders have bought in.
Be sure that you engage all project investors across all departments. Stakeholders must understand clearly the goals of the .NET migration, the importance of the project, and the scope of the project. Different people may describe their goals in different ways, e.g., technical stakeholders may want to keep software and technologies current, whereas the marketing department might put more worth on a specialized and discerning user interface, and end users may want something totally different. Spell it out. Like all projects, buy-in and support from key stakeholders is crucial to the success of the project. Knowing you have their support when things get tough can mean the difference between a project that moves forward and one that gets cut.
2. .NET migration estimates are not well defined or miss the mark.
Don’t get stuck with an unrealistic migration plan! Estimating the effort and risk of a migration project is key to developing a solid migration plan with a realistic timeframe, resource demand, and effort expectations. It is important to know what metrics you should consider in order to draw up a good estimate. For instance, Macrosoft’s FoxPro Code Matrix (MFPMatrix) tool can be used to generate a code matrix to estimate migration efforts. Up front, it creates a spreadsheet to define the technical difficulty/complexity of the migration (e.g., number of reports, forms, menus, etc.), the project risks involved, identifies data migration issues, and other UI parameters in order to create a realistic effort estimate and timeline.
3. Resources do not have the required skill set to migrate to .NET.
Hands on experience are needed going into the project. Learning how to migrate VFP to .NET is not something to try when your business-critical applications are on the line. If your team does not have the internal resources available with the skill set needed to migrate VFP to .NET, look for a team that does. At one point, the VFP development community was large and had many resources available to it. Currently, there are developers with strong .NET and Java skills, but not a solid understanding of VFP. A VFP to .NET migration requires the application team to understand both ends of the equation to make the conversion successful. If you go outside, choose a vendor that has experience specifically in VFP to .NET migration. Don’t hesitate to ask for references.
4. Underestimating the value of value-adds.
One of the more beneficial aspects of converting Visual FoxPro to .NET is the ability to add functions and features not accessible in Visual FoxPro. These are called value-adds. .NET brings a whole host of new value-adds to your applications such as resizable forms, mobile device support, multithreading, security, service-oriented architecture, and web services — the list is quite large. A development team experienced in Visual FoxPro to .NET migrations should be able to help you understand what is available to you and would benefit your application most.
5. Major changes were made to the legacy application while the migration in progress.
If the VFP application functionality you are planning to migrate is a moving target, there is hope. It is important that business continues during the migration process and it may be necessary to continue adding new features and functionality during that time. A good migration plan will schedule the migration team to evaluate functionality at the end of each major milestone to true-up the functionality. Remember, .NET applications are built to be scalable. If the business has added new features, the best way to add them can be assessed by the team during these sessions, so that by end of a migration project, the final result will be a fully up-to-date application which can seamlessly replace the existing application without any delay.
So, what’s next? That’s the number one question developers are asking themselves by now. There are many potential pitfalls when conducting a migration effort. Remember, forewarned is forearmed.
As you start to plan your .NET migration project, please fill out our comment box with your thoughts. We’d very much appreciate your questions or feedback.