Yeah, I'd agree. In my experience, you have to re-evaluate the design goals from scratch and then see how the solution architected with SQL Server in mind from the get-go can be grafted on what you actually have.

And this reminds me of the FP-DOS to FP-Win or VFP conversions that were common 10+ years ago. The good apps were the ones rethought - the bad apps were upsized and made to work nominally.

Even if you design an app using VFP native data with the thought that it might be upsized at some point, the reality is that there will be a lot of change and recoding. Views, for example. Stored procs as opposed to native direct data access. The list is huge. Plus, if it's a web app, you have to worry about session latency, postback concerns, license issues.....mamma mia.

>My point in this discussion is that "UPSIZING" is much more than simply changing where the data is. To asnwer your direct question, sure any application can easily have its data moved from one data store to another and all that has to be change is the syntax of the code that accesses the data directly. However, Upsizing an application connotes more than moving where the data is stored. It means making the app able to hanlde larger amounts of data and a number of divergent front ends and more.