No worries. Yes, as part of the sales process, we would pick one form and redo it in FileMaker.
From an earlier attempt, portals can't always be used due to the huge number of related records in some cases -- too slow to load all that related child data.
They have lots of dynamic code that colors grids that might be difficult to replicate. Lots of design work needed.
Thanks for your reply.
Good info, thanks!
take a look also here:
https://philosophyoffilemaker.com/why-filemaker-111
I always try to sell my apps, my business logic and very rarely the platform.
Most of the times they dont care about the platform only the IT departments that of course are always sceptical since its not oracle or sql and the apple brand behind claris hasnt much appreciation in the ITs. For an IT I also use the FileMaker Platform IT feature checklist from Filemaker 17 marketing kit
I've had trouble with this client when they heard "FlieMaker", but at some point, regardless, they'll know it's FIleMaker. Thus, I want to "show" them what FileMaker can do. Whether it can really compete with this VFP application without huge efforts is yet unclear.
One small example is that VFP maintains indexes in a separate "CDX" file so when you change the order, it happens instantly. FileMaker can take a "while" to resort the data every single time as I understand it.
VFP also programmatically allows you to modify / access almost every object at runtime.
Thus a totally different approach would be needed for a FileMaker implementation.
Since the client has so many little add-ons for things like PDF handling and DBFs offer ZERO encryption FileMaker brings good stuff in these areas.
Users here rule the roost and only want to use what's familiar. So, if their muscle memory doesn't match the new system by much, they probably won't use it.
Finally, this client feels burned with MS abandoning VFP and there is concern about yet another proprietary solution. An open source solution is certainly possible using some cost multiplier.
The "solution" is already written (in Visual FoxPro). It's thus a selling job to convince the client that another platform has features he is paying for now (like PDF handling) or important features he can't have (like EAR) using Visual FoxPro. This is a savvy client. A slick sales brochure or other "sales" approach would go nowhere.
There I wholeheartedly disagree.
Any solution created 20-30 years ago has serious lacks to adjust to the new ways of doing business. Back then, the phone was an important tool, and many processes inherently analog followed suit. If they havenât re-examined their business processes, chances are they are not as efficient as they should to support their growth or steady profitability. It might even explain underperforming. In such case you can calculate an interesting ROI for the project.
« Translating » what they think they have, in FileMaker, would necessarily cause you to use work arounds for stuff you canât reproduce natively.
It is advisable to create a performing solution in its own right, tailored to real business needs and processes. NOT to the current processes they have which is necessarily tainted.
For having done that exercise for a client, who had just put tens of thousands into the hands of a firm who had done something similar to what you are suggesting I can tell you it is a disservice to your client. 18 months after the beginning, a "solution" in dynamic Great Plains was delivered. It was incredibly slow, had way too much non native parts (i fear updates and upgrades would be horrible) and didnât accommodate more than 15% of the work it was supposed to support. They had to can it. When I did explore and map their business processes, i noticed that they were telling me what they thought the app should do based on the sequence of steps they had to do in the old system. What was not obvious to them was that these steps and methods were how they had been conditioned by their tool to solve their needs back then. Not by the best way to do things to achieve their business goals. By returning to their mission, and considering what the targets were (what they needed to deliver to achieve best customer satisfaction, retention or acquisition, in the current context in which they operate), it was possible to develop or update efficient processes and than see how THAT would translate in a FileMaker solution.
It is the difference between what the customer wants and what he needs. It is part of the consulting process making the customer see the delta between the two and getting him on the 'need' side.
@MonkeybreadSoftware talked about technical debt - which surely exists if the process is run on a decade-old software.
This is a challenging client who knows the score. They know the buzzwords, the consulting approaches, the whole bit. My approach would be to try to find some other little project we could do for them, but that requires the whole FMS infrastructure (since they want everything local).
Plus, they are not (yet) motivated to spend a nickel since their yearly outlay for $30 users is $0.0.
They know what they need. That's not the problem.
Thanks
Savvy clients can be convinced if they see that what you do is brilliant. Savvy clients are less likely to fall for marketing pitch rather then superior competence IMHO ..
I agree 100% with Cecile. Recreating the actual app as is in FileMaker, or any other tool - is running for trouble.
I had heard of such kind of development: a company had a custom solution built for them and went to a big ERP solution. They asked the selected ERP provider to customize the ERP solution so they can work the same way as previously with their custom made app. The result was a nightmare. Some parts of the solution were amazingly slow, the customer was mad at the provider, who simply realized their customer's wishes. And a fight started.
@OliverBarrett I read the posts added during me typing that reply. This customer knows what he needs - or thinks so - but is not knowledgeable of development. Danger Will Robinson, danger . . .
That seems an interesting approach. It did work to strengthen our expert position with a client.
Though it hasnât made them want to spend on their main system which needs rewriting.
Right. Agreed. I don't disagree with @Cecile either.
However, I never meant to imply we would try to re-create the app "as is". That would be impossible with all the SQL, object-based runtime stuff going on, index files, reports, etc..
I was just saying that the 'users', who truly rule the roost, won't use a system that doesn't closely match what they have now.
A difficult proposition.
Thanks
Yep, knowing this client, I'm sure that would be the same result we'd have! 
I havenât had the time to read through every post here, but it interesting.
Our own approach has always been to demonstrate something in FileMaker relevant to the potential customer. We are in a fortunate situation where weâve a core CRM system that has been used in a number of industries both as an SBA and AVLA solution, depending on whether it has to be customised or not.
It really has helped and utilising âa picture is worth a thousand wordsâ approach has been very successful for us.
That's a good idea. I think every time this customer asks for something new, I'll demo it in FileMaker. That will let me use one of my three "testing" web connections in FDS also! WIN-WIN. 
Great idea, thanks.
Totally agree!
The approach I have taken many times and with considerable success is to get potential clients to understand that what FileMaker is going to do is to make their business more efficient and if it becomes more efficient, it automatically becomes more profitable. FileMaker is a tool that will allow them to make those efficiencies, by automating and eliminating repetitive tasks at a speed that makes cost of development a small factor in their business but, much more importantly, time to deployment is extremely quick which means it costs less money to get there and they get to use it quicker.
It is, in my opinion, a mistake to try to re-invent the wheel by recreating exactly what they had before but in FileMaker. Find out which parts are actually being used and re-design that functionality.. Forget the rest until they tell you they absolutely have to have it.
For those clients who have a very outdted solution and simply want to convert it, I tell them that I can take their Model T Ford of a solution and make it look like a Ferrari but it is still going to drive like a Model T Ford. Uusally they decide that what they want is a Ferrari.
This client doesn't want to get roped in to an expensive proprietary solution and they're quite savvy and are not swayed in the least with "salesmanship". Currently, their solution is costing them $0.0 per year. A standalone executable that is serving 30 users. They are now leaning toward us creating a web application using Oracle or SQL Server for the back end that will scale to as many users as needed for the same license cost.