Wow, Evan, thank you. You probably will not believe this, but your steps are basically the same as in my outline I have written now (without the hardwork of pros/cons that need to go before it). :o)


>This sounds very similar to what I have been doing for the last few years. In 2000 I rewrote a monolithic clipper DOS app into 3 tier Visual FoxPro app. VFP was used for all 3 tiers. In 2003 because of dept growth to a large regional area, we moved our VFP app to the web by re-writing the UI to ASP.NET using C#. The business tier was compiled into a COM component and the data store left as VFP tables. Though it took a while to create the UI in C#, the new web app was very stable since it reused existing code with minimal changes. In the last few months, we have re-written the biz tier into C#. This weekend, we are changing the VFP database to SQL Server.
>
>I guess the point of my long story is, try to break down this huge project into smaller chunks. This will allow a few things:
>- the application to stablize as you transition between phases
>- reduce the risk of the entire project failing by breaking it down into parts, some of which my succeed, some may fail.
>- between phases you can do a few important enhancement requests for your customers, enabling you to keep them and keep them happy
>- this allows you to learn .NET or SQL Server in more managable chunks. In my opinion, learning to code in C# for a business tier is far easier than learning C# to code ASP.NET pages.
>- if management changes (a new boss) or changes their mind about the project part way through a large project, you waste time and money. With several smaller phases you will have finished off some of the phases, and can probably wrap up the one you are in the middle of
>
>Consider doing the following.
>
>Phase 1: modify the app into 3 tiers, all with VFP.
>- this will help you understand the application completely since you will have to map out the business classes
>- because data access will be encapsulated into a few classes, the later change to SQL Server will be very easy
>- the good thing is that you can recode a form, deploy it, onto the next, then deploy until you have completed this phase
>
>Phase 2: change the data tier to SQL Server
>- at this point, this will be a fairly trivial rewrite of a few data access classes
>- your reports will be the big chunk of the work since they will probably access tables directly
>
>Phase 3:change the UI to winforms or webforms
>- these will be almost empty skins at this point if you can rely on your biz tier
>- you will need to compile the VFP biz objects into COM components
>- I find webforms pretty fast to code, unless you are trying emulate a rich Windows interface, then things get complicated quickly
>
>Phase 4 (optional): change the biz tier to C#
>- you might be able to convert a biz class, deploy, then next and so on allowing the app to stabilize
>- at this point you will be a C# expert
>
>Some other random tidbits
>- I found that calling COM components from ASP.NET was less stable that calling .NET business objects. Every few weeks we would get a strange crash of the ASPNET worker process. This doesn't happen with pure .NET code.
>- I was shocked to see that business objects written in C# pulling foxpro data throught OLEDB were about as fast as VFP COM components
>
>>I have been tasked to create a white paper for inhouse use to look at the business considerations in rewriting a major application (took 10 years to develop completely and is now in VFP9 but still has data handling code throughout accessing tables directly - no ntier development but many classes and new features have been added overtime) from VFP to C# using SQL Server 2005 as a backend. WOW.
>>
>>I have six weeks to complete it. A lot to consider and right now I am looking at the below options to include:
>>
>>Front End VFP, Middle Tier VFP, Backend SQL Server 2005
>>Front End C#, Middle Tier VFP, Backend SQL Server 2005
>>Front End C#, Middle Tier C#, Backend SQL Server 2005
>>
>>
>>Right now there is no TRUE middle tier but if it is rewritten then it should be done with one to allow for the greatest options down the road for future modifications.
>>
>>using C# it would include options of winforms or webforms
>>
>>If we do this, then the company will invest in formal C# training (wow, what a terrific opportunity). Right now I only have my experience learning on my own at home).
>>
>>I know the benefits of using VFP data handling but there are many business cases for creating a separate dotnet frontend and even using data handling in net (yuck but it must be seriously considered). I do not have to present that information other than to list the pros and cons but will focus on the benefits and drawbacks (as a business, as developers, and from the customers perspective - sales) of each option listed above and the estimated manhours to complete each one. The original app may still exist if the rewritten one is strictly thin client. That will be determined as well. We have over a thousand customers so the need for thin and thick clients exist.
>>
>>Please do not respond with "WHY even consider this?" The task was assigned and I will do my best to complete it honestly and in a professional manner listing all aspects.
>>
>>Previous documentation and experience anyone is willing to share would be GREATLY appreciated.