Hi , i there is VB 6 app that our client has which must be converted to VB.NET/C# .
The application is a database application and application logic is stored in VB6 code and about 8 stored procedures.
There is a Test environment and there is a Production environment which are not the same.(The test environment SQL tables aren't updated , and some table/stored procedure structures are not the same)
I don't understand the full system.
How do I go by understanding the system?
I've tested a Visual Basic 6 upgrade assessment tool that predicted the conversion of this would take 3.64 months.
There are 20 forms.
Would I need a table comparing tool like Redgate.
My experience is not a lot . My c# knowledge is more than vb6.
Although you can upgrade some projects it doesnt really convert them to .Net. You are better off starting a new .Net project and just using the old project as a guideline for what needs to be recreated.
Step 1: First off, you need to validate your dev/test environment and reconcile the differences with production. It sounds like test contains an in-progress release. Figure out what things are out of sync with Prod and which how/if they are supposed to be finished and move to prod.
Step 2: Per TomW's implication, decide what "really .NET" means for this application. If you do not do this, it does not matter how the .NET code is created, it will not "really" be .NET. Unfortunately, if you ask 10 people you will probably get 10 different answers for what "really .NET" means. But the point is, you will have to invest time to learn about the many design options available in .NET followed by some good old technical analysis and design work to decide how you should do your app in .NET.
Step 3: The other point TomW made is also critical, get ready to *use* the old project as a guideline for what needs to be created. Make sure you understand how to exercise and validate the functionality of the new app. 20 forms and 8 procs implies a very small app by VB6 standards, but its impossible to judge from those facts alone. There could easily be hundreds of business rules and UI design decisions defined by the VB6 code and you will have to systematically understand and re-implement those rules in a way that fits the "really .NET" design decisions you made in step 2.
I always use tools to help do migrations -- I do the technical design by hand, and I leverage tools to help me *use* the legacy code: to capture all functional requirements from the legacy source and to faithfully implement the functionality in a way that fits my design. This is called a "tool-assisted-rewrite" and I use the products from Great Migrations to do it.
If it is a database program, rewrite the whole thing into Access. Access has more options and less need for so many forms. If you are unable to complete the project, you will have to hire someone who is proficient in this type of project or tell your client it is not within your means to complete the project.
Don't mislead clients into thinking you are capable of doing something if you cannot convert the project satisfactorily. A client will respect you more if you admit that you cannot do the project.
Handling this type of project will take you away from other clients whose projects are probably less incumbrent and more easily completed.
The "too hard basket" is nearly always full. Perhaps top it up with this project?
Either the thread starter or a moderator has marked this thread as solved. You can most likely trust the responses and answers given. There is most likely no reason for any further responses to be posted here. If you have a related question, please start a new thread in this forum instead.
This thread is more than three months old
No one has posted to this discussion for at least three months. Please let old threads die and do not reply to them unless you feel you have something new and valuable to contribute that absolutely must be added to make the discussion complete. Otherwise, please start a new thread in this forum instead.
Marked 
