By Ghulam Nabi Shah | Published on March 2nd, 2021 |
Migrating from Visual FoxPro to .NET requires a solid strategy, effort, and a well-trained and skilled implementation team. Macrosoft has completed many 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 do not want that to happen to you so here are a list common mistakes and how to avoid them when converting Visual FoxPro to .NET..
Be sure that you engage all project stakeholders across all departments. Stakeholders must clearly understand 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 are 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.
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 tool can be used to generate a code matrix to estimate migration efforts. Upfront, 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 to create a realistic effort estimate and timeline.
Hands-on experience is 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. Currently, there are developers with strong .NET and Java skills, but not a solid understanding of VFP. A VFP 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. Do not hesitate to ask for references.
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. 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.
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 include 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 that can seamlessly replace the existing application without any delay.
Ask any software tester or quality assurance engineer about migration, they will have a similar answer which says that when it comes to migration, software testing and development go hand in hand. When compared with a software development project where a project is divided into sprints, the migration process is a marathon. Quality assurance has to be an integral part of the process, it is better to be safe than sorry, as VFP coding is both object-oriented and data centric as well. Where the business logic, front end, back end, and reports are all in one single class. All the interconnected and intertwined as the program moved on in its life cycle. As the conversion progresses, the complexity increases, solid quality assurance can provide check points at regular intervals.
When it comes to VFP to .Net migrations, the ideal team would a group of professionals with a mix of skills and knowledge. A project manager who has a history of working on and overseeing migrations. The software testers should be professionals who like the daily grind of going through loads of new codes. When it comes to the developers, things get complicated. In the case of developers, we need to look for three things, target platform expertise, source platform expertise, and application knowledge. The developers will be a mix of VFP and .Net developers and some developers who understand the business functionalities of the software. Software developers who understand the software act as the stabilizing agent for the migration process as they navigate the other sets of developers to their functionality target.
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.
