Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Migrating an application from VFP ( sob! )
Message
De
02/02/2015 11:14:19
 
 
À
02/02/2015 10:13:34
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Divers
Thread ID:
01614670
Message ID:
01614760
Vues:
80
Craig,

I appreciate your balanced and thoughtful answer.

We do agree that the VFP apps will have to be rewritten some day down the road; we also agree that VFP is a frozen tech and some other new techs are more powerful, easier to use, etc. no doubt about that, just on-going progress as usual.

In order to reduce the risks and gain benefits earlier, FoxInCloud brings continuity into this process, reduce the disruption as much as possible: make one evolution at a time, at a pace that business experts can sustain (many VFP devs. come from a business perspective, not from a IT perspective), with quick and manageable benefits.

It would be great if we could setup some sort of cooperation with people like you (knowing both VFP and alternative technologies).


>If you look back at my responses, I already proposed interop to the existing VFP code as a *possible* solution. In reality, none of us, except Alex, know enough about his problem domain to solve his problem. All we can do is give suggestions of what to look at and what not to look at.
>
>I read once (can't find the link anymore) that on the average, applications are rewritten every four versions. There are various reasons why that happens. Most often it's due to technical debt. A platform shift is also common. There are patterns you can use in the rewrite that help reduce the costs and risks involved. Based on my experience, it's usually done the wrong way.
>
>As for your last point, that may or may not be a good option. Cultural and language differences can actually harm a project.
>
>
>>Hi Craig,
>>
>>OP has a 50 MB exe - this means at least 200 forms - rewriting this as a native app for iOS, Android, and Windows is just a non-sense for 99% of VFP-driven software companies, just unsustainable.
>>
>>No business user ever cares of UI differences between iOS, Android, and Windows; if ever they did, you can easily adapt the display using CSS.
>>
>>For hybrid apps making their way into app stores, Rick, you and I agree about this: (1) there are very few, if any, demand for business apps into app stores - mainly focused on games, social networking and general purpose apps so far (2) developers need to find a way in (3) when demand will arise platforms will need to adapt because any OS needs apps and users to survive (4) meanwhile you can use a shortcut on the 'desktop' (eg in safari 'add to welcome screen') - not perfect as Rick pointed out in his blog post, improved on latest iOS update, bet it'll probably improve even more in the next releases.
>>
>>Rewrite is not a viable solution - we've already discussed that in other threads and there are many examples around showing it's over risky to enter such a process for small S/W companies - any one serious needs a balance between keeping existing solution up and running and moving to another technology.
>>
>>Yourself pointed out that the OP would need to hire 'additional resources' - we both know that these 'additional resource' will have to be of a high degree - probably engineers - and will know nothing of the OP's business (payroll). Each individual may know one of the target segments well (native mobile apps, web apps, etc.) none of them can know all these segments and the payroll business as well.
>>
>>In the solution you would buy (rewrite), the OP will have to hire 2 or 3 additional engineers and teach them the payroll business for 6 month before they can produce anything consistent. This is a tremendous risk that the OP can rate for his own sake.
>>
>>The solution we propose is gradual; if you dare to flex your mind enough and accept to understand the migration strategy we propose, we never say the OP's company should use VFP for ever - we say that, by using FoxInCloud, he can move his UI to HTML/CSS/JS, then probably his database, then his server code, and this evolution can be made over time, is sustainable, as opposed to the big bang of rewriting.
>>
>>The OP can hire new people (web designers) to adapt the HMTL UI to various resolutions and devices while the server code remains in VFP, maybe gain some additional clients and/or license fee for this new feature, then work in a different thread on data migration, then on server code, etc.
>>
>>What we all know is impractical and unsustainable is to change everything at once, it's just common sense.
>>
>>I would be happy to have a discussion on this point (rewrite or adapt), hopefully with practical experience shared by companies who have started and/or completed a full rewrite of a serious commercial business software (100+ forms).
>>
>>One last point: for hiring VFP people, make sure to look outside your country - you'll find plenty of them.
Thierry Nivelet
FoxinCloud
Give your VFP application a second life, web-based, in YOUR cloud
http://foxincloud.com/
Never explain, never complain (Queen Elizabeth II)
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform