Mark I think you already know your answer, as you said you will be working on that app for a few years, so do you really want to bet your development on VFP who by reasons that we can't control is being discontinue (and please don't start coming with support until 2014 and other things).
IMO you should start looking into .NET es pecially as you say you will be using SQL Server and not DBF's.
Now about the framework I personally prefer to develop my own gives you more flexibility for the future, but that's me what I can tell you is that I develop my own but use 3rd party controls, e.g. I use Component one controls and like them, since they have similar controls that works on windows, ASP.NEt and also on the compact framework.

Now as Keith said you should hire 1 top .net developer and that may be the tricky part, since u may get lucky and get a good developer or on the other had u may end up choosing a bad one and that could make more harm then good.
Also give a look into http://www.learnvisualstudio.net/ this can give you a very good help and more important is not alot of money so no reason why not to sign it.
And I would also have a conversation with the client and would put the cards on the table and explain why changing from VFP to .net platform and that cause of that this project time frame may not be that short.

>Hi,
>I would like advice on whether to switch from VFP to .NET windows forms for our development. Please respond to anything here – I am very interested to hear people’s thoughts – even if strongly contrary to my thoughts.
>
>Background:
>We develop custom business software and have done many projects, over four years, for our largest client. All apps have been developed using VFP (v.6-9). We’ve been using SQL-Server for about 6 months now and love it. The apps we’ve written are pretty complex. We are about to start a large app which we’ll be working on/with for a few years and I want to decide on the development platform from the get go. I am considering going with .NET window forms.
>
>Beliefs:
>It will benefit our client to have .NET apps rather than VFP. It will increase the value of their company if a major in-house app is done in .NET. They may want to sell in 5+ years. It will also allow us to use same classes, code, etc. if/when we do web apps for them. My future business prospects are greater if we know and have developed sizable apps in .NET. Being experienced developers designing, developing, and deploying larger apps will be much more valuable doing so in both .Net and VFP rather than VFP only. Even though our apps are top-notch, when people hear we are using VFP they look at me as though I said we’re using assembler.
>
>Real-life:
>We can develop these apps in VFP knowing we will do a bang-up job and meet deadlines, avoid bugs, etc. My client wants development to be as top-notch as past development and doesn’t care what development tools we use. Our client is very happy with what we’ve done and that is why we do so much work for them. I do not want to risk their satisfaction by going with .NET. Most importantly, we have a track record of successful projects. Long development time with buggy apps will have a really negative effect – big time.
>
>Frameworks:
>I’ve been told that it would be nuts to develop these apps without using a .NET framework. People have suggested CSLA and DevForce from IdeaBlade. Is Mere Mortals a stronger candidate since it was developed by same people who did VFP framework? What other frameworks should I be considering? Feel free to email me at sqluser@verinow.com if you don’t to comment on Mere Mortals or other frameworks on the UT.
>
>FWIW: Another developer and I do all of the work – just two of us.
>
>For answers to these questions, I’ve looked into my alphabet soup, flipped coins, read stuff on the web, and looked at, and even read a few pages of some books. I am still not sure which way to go. The advice I get here is guaranteed has got to better than what I got from my alphabet soup.
>
>Thanks for reading this far. I would really appreciate any thoughts.
>Thanks,
>Mark