>>>>- As far as your claim of 1% to 2% code adaption. I don't buy that. We have gone through that process before for a relatively small project and it was far more complex than just code adaptation.
>>>
>>>If you say so, you probably know better than me what code adaptation is about.
>>>Ah yes (slap on the forehead), judgment matters
>>
>>We have integration with Crystal reports, using a dozen activeX controls, automation with Word and Excel and this all has to run over the internet over a browser. Sorry but this needs a total different approach.
>
>Bad luck Walter:
>- Crystal Reports: we have FoxinCloud applications in production with dozens of crystal reports
>- activeX: we support treeview, PDF, rich text and IE; we can support any other activeX with a sponsorship and use controls that you probably end up using in your web app
>http://foxincloud.com/tutotest/bs/treeView.tuto
>http://foxincloud.com/tutotest/bs/ie.tuto
>http://foxincloud.com/tutotest/bs/report.tuto
>- word automation: we have apps in production with libre office automation, no doubt it’d work the same with MS office.
>
>You want to kill your VFP code, fine… no need to spread fake news on FoxinCloud, even if you have a negative bias.

First, our application contains more things that fox in cloud cannot handle, You cannot handle the frontend of CR as you cannot bring the activeX control to the (any) browser with the functionality we need, like editing the templates and the interactive viewer. Same goes for libraries like our Commandbars library. Al the code surrounding that need to be redesigned. Then I'm not even talking about automating word allowing for users to open word to design templates, scanning documents, image capturing of microscope cameras etc. It just does not work through the browser no matter how good your product is. That is not 1 to 2% code adaptation, that is a serious redesign of large chunks of our application.

Therefore I think you missed the point.

We are maintaining and enhancing the current applications for an x number of years, but Business wise need a new approach for the future, away from ActiveX controls, away from MS office COM automation, away from the Crystal Reports XIR2, away from the VFP language. Its outdated, riddled with problems and will not take us another 20 years forward. We have been extending VFP to what is possible, but we are going to develop it from the ground up with another approach while keeping the current product in maintenance mode. Its not worth it to invest anymore into the old architecture. We have made a business analysis and we have come to the conclusion we need to switch technologies now (still filling in the details). We are now analyzing the available techniques, tools and GUI libraries we need to make that happen. We want code to be maintainable by developers you can hire everywhere in stead of scrambling for VFP talent around the world.

Lots of the complex calculations, the data munging has now moved to the SQL server as we now have dedicated to one single backend: SQL Server. That has made the client much more straightforward and thus migration itself a lot easier.

We skipped wi forms, vb.net, WPF, Silverlight and other technologies, but now its time to look at what you would use if you're do it from scratch.

Our company is about 30 people large. Lots of people have to eat, also in the future and therefore we have to invest into that future.

Walter,