Walter,

I share your opinion that the real issue in the OP's project is whether he can complete it.

Some interesting reading from Joel Spolsky, CEO of StackOverflow:

Things You Should Never Do, Part I by Joel Spolsky

How To Survive a Ground-Up Rewrite Without Losing Your Sanity

The first, absolutely critical thing to understand about launching a major rewrite is that it's going to take insanely longer than you expect. Even when you try to discount for the usual developer optimism. Here's why:
- Migrating the data sucks beyond all belief
- It's brutally hard to reduce functional scope
- There turn out to be these other system that use "your" data
...
You you have to totally own the business value.
First off, before you start, you must define the business value of this rewrite. I mean, you should always understand the big picture value of what you do (see: Rands Test). But with rewrites, it's often the tech lead, or the developers in general, who are pushing for the rewrite -- and then it's absolutely critical that you understand the value. Because you're going to discover unexpected problems, and have to make compromises, and the whole thing is going to drag on forever. And if, at the end of all that, the Important People who sign your checks don't see much value, it's not going to be a happy day for you.
...
Worship at the Altar of Incrementalism
Over my career, I've come to place a really strong value on figuring out how to break big changes into small, safe, value-generating pieces. It's a sort of meta-design -- designing the process of gradual, safe change.



PS:
>* Windev
>* Servoy
>* Lianja
*FoxInCloud

Would you mind adding FoxInCloud to your list?
As a full SaaS platform, FoxInCloud takes in charge user state management across multiple servers, user security, audit trail, detailed execution time reporting, and more.

FoxInCloud implements the gradual change approach mentioned earlier.