Fitting this into the available categories was guesswork...

Suppose that I had a successful product deployed in many businesses and that it used exclusively native VFP tables.

Suppose too that many of those customers had long ago migrated their other applications to SQL Server or Oracle or whatever and that the product in question was the one remaining application NOT using SQL Server (or ???). By now several of these installations find the subject application to be a "PITA" if only because they no longer have expertise or because it spoils their "all SQL Server" status.

So I decide that my wisest course is to integrate "client server" into the application.

Now most of this application already uses (VFP) SQL - specifically Select and INSERT INTO. Many parts of this application uses, for lack of a better term, 'sequential SQL - Select' commands to obtain a result set. In other words there may be 3 - 8 Select - SQL statements in a row, one taking the result set(s) from prior commands and using them to eventually get at what's needed.

My understanding is that, using strictly 'passed-through' SELECT commands will NOT work in such cases because the result set(s) sit only on the local PC and so are not available to the (data) server for subsequent use.
But I also understand that these could all be used more or less as-is IF THEY WERE EXECUTED FROM A STORED PROCEDURE.

Assuming this to be correct, the question at hand is: Is it reasonable (maybe even 'expected'?) to require the installation of stored procedures into a customer's existing system?
My sense tells me it IS reasonable, if only because these stored procedures can be isolated to the specific database(s)/tables relevant to my application. But I don't know how such would be viewed/accepted given the myriad of factors about which I know nothing.

Your counsel is appreciated.