Migrating From Visual FoxPro

Question

I work for a company that had a large number of applications based on Visual FoxPro.

The company is now looking for a migration strategy away from VFP to another language for its desktop applications (and web applications using west-wind).

There are two consideration to be made in the coming years (support for VFP from Microsoft will last until 2012). Which database and which programming language.

The company is not set on any migration strategy yet but it looks like a worthwhile strategy would be to migrate the database to a more robust RDBMS, for instance SQL Server or MySQL, port any VFP Database specific code to the new database system then slowly move the applications away from VFP to another programming language.

The applications are based around three main areas, report generations (something that VFP excelled at), CRM Management and order management.

Does anyone on SO have any experience in migrating away from VFP? Does anyone have any recommendations on migrating code and databases away? Can anyone recommend a programming language (C#, Java or a scripting language) that would meet the needs of the organization?

Answer 1

The FoxPro / SQL Server combo is very workable. A option that I have seen (and been involved in) successfully used this scenario is to migrate the DB to SQL Server and make use of FoxPro views while retaining the original app. Then progressively rebuild the app from data layer up with .Net tools. If the apps are modular it is possible to take it module by module. Otherwise you have to find some other demarcation.

I understand this works with other RDBMSes but I have no experience of any other combination.

I suggest you spend some time before getting into the code side to ensure the data is sound. FoxPro tends to be more forgiving of data oddities (orphan records, etc). So cleaning this up before encountering issues with it on the target RDBMS is worthwhile. Audit the DBs for orphan records, mormailisation issues, etc and address them in the product you're presumable more familiar with (FoxPro) rather than stumbling across them during the migration proper.

Regards

Answer 2

This was one of the first tasks I did at my current job. They were 4 Foxpro web-applications using west-wind. The Foxpro applications were a mess but that was due more to my predecessor then the language. I went to a Mysql database and created Java versions from the applications. JDBC connections could be made to the Foxpro database and then to Mysql to do the DB transition. Other then that I don't think there are any type of migration tools out there. But really any RDBMS would work Mysql, Oracle, MS SQL server, etc... and for the application it self Ruby on Rails, Java, PHP, .NET etc .. take your pick.

Answer 3

We have done this for our application backend. We moved to SQL Server.

Since Microsoft wants you to upgrade to SQL Server/.NET it may be easier to go that route. FoxPro 8&9 have built-in "Upsizing Wizards" for migrating the data, and I believe that there is a fair amount of information out there on the FoxPro to SQL Server migration:

http://blogs.msdn.com/sqlcat/archive/2008/01/25/foxpro-to-sql-server-migration-experience.aspx

http://msdn.microsoft.com/en-us/vfoxpro/bb190277.aspx http://www.foxcentral.net/microsoft/NETforVFPDevelopers.htm

My experience is similar to Karl's with regrard to the data clean-up. FoxPro allows data that is bigger than the stated field size. For example: if you have a field that is an N(6,2), foxpro will allow 999999 in the field - where the largest number it should allow is 999.99. If someone did a typo and entered data bigger than the field size, then when you try to import this into the same size field in SQL Server - it will blow up. Date fields have similar issues.

If your FoxPro apps are similar to ours, you will have to do a significant amount of redesign where the use of data is concerned. What worked quickly in FoxPro, may not work the same way in an RDBMS. The use of SCANs and other FoxPro specific logic either does not work at all in other languages, or works much slower. If your indexes are using Rushmore logic they will have to be re-designed as well.

Honestly, I don't think it makes that much difference what programming language, or RDBMS you go to - the same work will have to be done for any combination. Microsoft has probably made the SQL Server/.NET change easier - with more documentation available.

Answer 4

Whatever language and database you end up with, evaluate the reporting options that your choice gives you very thoroughly, because in many ways you will find it hard to match what VFP gives you out of the box in this regard.

Answer 5

I worked for a company that developed an application that was completely VFP. I worked on migrating the back-end from VFP Tables to MS SQL Server. That was step one for us. I built all the update mechanisms into a number of small, custom applications that were called by our installer. After the migration we went through and started moving pieces of the application to modular .NET components.

To make the migration more seamless to the user you can start by building each part of you application as a seperate modular .NET EXE that you could call from your VFP application. As more and more (back-end) components are moved to .NET you can decide when to make the final switch. I would switch over all the back-end processing pieces first to harness the power of .NET and then when all of that is done, start re-engineering the front-end. You can also convert all your modular executables into dlls when you are done.

Alternatively you could used the Sedna and start building some migration tools or interop dlls that you could use.

If you have any more questions feel free to ask. :D

Aniket