>That's why the argument for Azure hosting is becoming more and more practical.
>
>I agree with Christian and was going to make that point to Sandy - was just curious what version of SQL Server they were using.
>If they were using the Enterprise edition of SQL 2012 or greater, there are many significant features in the database engine that are worth tapping into.
>So like I said, unless there is a compelling reason to need to stay with Fox tables (and if Azure for hosting isn't an option), I don't agree with an app supporting both Fox tables and SQL tables. That kind of dual support is likely more driven by the developers that anyone else.

Not sure 'agree' or 'disagree' is the kind of answer the OP is looking for…

What needs to be correctly evaluated is the path to migrate a given population of clients who:
1. don't all want to pay for the migration, or may not want to change anything in the way they work or whatever - you can't force a client to migrate
2. have different sets of data
3. may different functionalities in the software if they have paid for specific extensions

The other point is how to manage the migration without cloning the code base into 2 versions; if the software has frequent evolutions - eg a payroll s/w that must include the latest regulations - it will probably cost much more to maintain 2 versions in parallel than to have a single code base that can address 2 different kinds of DB.

Just had a closer look in Cursor Adapter, made some tests against VFP and PostGreSQL: frankly, it is very very easy - with a little OOP sauce - to make the same CAD address either DB at run time.