FoxPro Migration Consternation
March 12, 2009 3:59 PM Subscribe
How difficult is it to migrate a DOS-based FoxPro database application (including 15 years of legacy data and dozens of customizations ) to a more modern, web-enabled database platform (say, Microsoft .NET using SQL Server, or preferably, MySQL)?
More info: the database currently runs on FoxPro v2.6, and has been faithfully in operation since at least 1996. It is a completely custom staff scheduling/payroll application that has been tweaked dozens of times over the years as the company using it has expanded. Unfortunately, it has no web front end, very rough email integration, but also quite nice custom integration with both the front of the house sales system, and back of the house payroll/accounting apps. Client would absolutely like to preserve historic data, scripts, logic rules, etc. in the new web-based system. Which platform should the client migrate to (is one system easier to port the data to than others), what are some of the pitfalls of migrating the data, and should the client consider scrapping the current system altogether and building anew on a new platform?
More info: the database currently runs on FoxPro v2.6, and has been faithfully in operation since at least 1996. It is a completely custom staff scheduling/payroll application that has been tweaked dozens of times over the years as the company using it has expanded. Unfortunately, it has no web front end, very rough email integration, but also quite nice custom integration with both the front of the house sales system, and back of the house payroll/accounting apps. Client would absolutely like to preserve historic data, scripts, logic rules, etc. in the new web-based system. Which platform should the client migrate to (is one system easier to port the data to than others), what are some of the pitfalls of migrating the data, and should the client consider scrapping the current system altogether and building anew on a new platform?
Step number 1: Seperate the database from the user interface. You could move the database to SQL Server, and keep the user interface in FoxPro, or move the User Interface to ASP.NET and keep the DB in FoxPro.
Step number 2: Convert the other part.
Step number 3: There is no step three.
Either way, it's going to be a lot of work and probably require someone who knows FoxPro, SQL Server, and .NET, so you're probably looking for someone who has been programming for a while, and has a lot of experience with both. Not an easy task.
I'd recommend breaking free and creating a new system and importing the data.
posted by blue_beetle at 4:40 PM on March 12, 2009
Step number 2: Convert the other part.
Step number 3: There is no step three.
Either way, it's going to be a lot of work and probably require someone who knows FoxPro, SQL Server, and .NET, so you're probably looking for someone who has been programming for a while, and has a lot of experience with both. Not an easy task.
I'd recommend breaking free and creating a new system and importing the data.
posted by blue_beetle at 4:40 PM on March 12, 2009
Best answer: I've done a few similar projects, and they all took longer and used more resources than the client ever imagined. "These things take time" is an especially apt phrase, especially if your development team is small.
It's much, MUCH easier to build something from a clean sheet and migrate the important data to it than to envision this as any sort of "conversion" of the current system. And while "Client would absolutely like to preserve historic data, scripts, logic rules, etc. in the new web-based system.", may sound like a good idea, the reality is that these things will need to be replicated in the new system. Expect to create new functionality based on the old, probably with some differences and limitations, and set the client's expectations accordingly.
Honestly, I think managing the client's expectations may be the greatest challenge with these sorts of projects, as things are ALWAYS messier than the client imagines them to be.
One final suggestion: start one person or small team on data cleanup immediately. As boo_radley said, non-normalized and inconsistently formatted data is a real time suck with these projects. And with 15 years of historical data to sift through, there's going to be a lot of that sort of thing to deal with.
posted by mosk at 4:56 PM on March 12, 2009 [1 favorite]
It's much, MUCH easier to build something from a clean sheet and migrate the important data to it than to envision this as any sort of "conversion" of the current system. And while "Client would absolutely like to preserve historic data, scripts, logic rules, etc. in the new web-based system.", may sound like a good idea, the reality is that these things will need to be replicated in the new system. Expect to create new functionality based on the old, probably with some differences and limitations, and set the client's expectations accordingly.
Honestly, I think managing the client's expectations may be the greatest challenge with these sorts of projects, as things are ALWAYS messier than the client imagines them to be.
One final suggestion: start one person or small team on data cleanup immediately. As boo_radley said, non-normalized and inconsistently formatted data is a real time suck with these projects. And with 15 years of historical data to sift through, there's going to be a lot of that sort of thing to deal with.
posted by mosk at 4:56 PM on March 12, 2009 [1 favorite]
Just virtualize it and keep running it. Moving it to a VM will mitigate a lot of issues with maintaining a machine old enough to run DOS well plus it will give you a lot of remote management feature that make it pretty easy to deal with.
posted by GuyZero at 4:58 PM on March 12, 2009 [1 favorite]
posted by GuyZero at 4:58 PM on March 12, 2009 [1 favorite]
Best answer: mosk has excellent advice.
Odds are that what was once considered custom software for you in 1996 is a configuration of a packaged product in 2008. Use this as an opportunity to make a clean break.
Having lived through migrations of this sort, my advice is this- export whatever data you can into whatever non-proprietary format is convenient, put it on a disk, run whatever reports you need to get a picture of that data, and walk away. The only thing you should bring into the new system is config.
Historical data? Forget it. You'll be spending months, if not years, trying to import and reconcile it in the new system, only to find that it either (a) doesn't work at all or (b) isn't actually needed.
posted by mkultra at 6:37 PM on March 12, 2009
Odds are that what was once considered custom software for you in 1996 is a configuration of a packaged product in 2008. Use this as an opportunity to make a clean break.
Having lived through migrations of this sort, my advice is this- export whatever data you can into whatever non-proprietary format is convenient, put it on a disk, run whatever reports you need to get a picture of that data, and walk away. The only thing you should bring into the new system is config.
Historical data? Forget it. You'll be spending months, if not years, trying to import and reconcile it in the new system, only to find that it either (a) doesn't work at all or (b) isn't actually needed.
posted by mkultra at 6:37 PM on March 12, 2009
Response by poster: Thanks everyone for validating what I suspected all along was the best path forward.
posted by piedrasyluz at 4:27 PM on March 18, 2009
posted by piedrasyluz at 4:27 PM on March 18, 2009
This thread is closed to new comments.
From your overview, I'd be concerned that the data's not in any normal form. Commonly with tools that grow organically like you describe, you might have to watch for a lot of data type exceptions, where someone lazily used e.g. a string field to maintain numeric data.
posted by boo_radley at 4:12 PM on March 12, 2009