Migrating VB6 applications to .NET?
-
What the title says. For most people this (hopefully) happened some twenty years ago, but I'm going to inherit a lot of VB6 applications, some even still work with a dBase database. The programmer is going into retirement and this (reasonably large) company needs someone to take care of their software. Our (and their) first priority is getting off of dBase, the current programmer already started working on that. Next we'll need to move VB6 to .NET (Framework, probably). I know there used to be converter tools around, but I've heard bad things about them. They're usually not worth the effort. Ideally, I'd rather just rewrite everything to web-based and cloud-ready .NET 6 applications, but I don't think we'll have the time nor money. Any tips (other than "RUN!")?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
My company in a migration process from VB6 right now. First things first. I don't know anything about you application so anything said down here may not be relevant. My company have many million lines of code in VB6 and VBA compatible scripting language in the 3 main application. All of the are using the same core written in VB6. We started the migration 2.5 years ago. The process is like this. 1. Write a server side C# code and connect old UI to the new (C#, .NET Core 3.1, now upgraded to .NET 6). 1.1. Create core for "migrateable" components. 1.1.1. Connect server-side components to the old UI. 1.2. Migrate those components. 2. Create the new UI (C#, .NET 6, WPF). 2.1. Create core client-side components to show server-side components. 2.2. Migrate client-side UI components. 2.3. Create the tooling. Many processes are parallel. The smallest of the 3 main projects will be fully migrated at the end of this year. The second one is planned to be ready at the end of next year. Biggest biggest project is planned to be ready in 3 years (likely it will be 5 years). The good news is that whatever is migrated is used by the customers already.
-
What the title says. For most people this (hopefully) happened some twenty years ago, but I'm going to inherit a lot of VB6 applications, some even still work with a dBase database. The programmer is going into retirement and this (reasonably large) company needs someone to take care of their software. Our (and their) first priority is getting off of dBase, the current programmer already started working on that. Next we'll need to move VB6 to .NET (Framework, probably). I know there used to be converter tools around, but I've heard bad things about them. They're usually not worth the effort. Ideally, I'd rather just rewrite everything to web-based and cloud-ready .NET 6 applications, but I don't think we'll have the time nor money. Any tips (other than "RUN!")?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
We had to do what you have to do big time. But with todays knowledge, I would like to encourage you questioning not only VB.Net vs C#. Depending on the charactor of the application, having a Web Application might be worth thinking about. You may want to have a look at JMIX which is a Java Framework on top of Spring Boot which gives you almost the easy of good old VB6. It gifts you with all the typical features of a modern application and the sample apps they offer could be a good starting point for modifying them to cover the functionality you need. No, I am not getting paid by those folks :-) ... and I am still a strong supporter of VB (adopted it starting at Version 1.0). But now I heavily rely on JMIX and Windows getting independent from operating systems.
-
What the title says. For most people this (hopefully) happened some twenty years ago, but I'm going to inherit a lot of VB6 applications, some even still work with a dBase database. The programmer is going into retirement and this (reasonably large) company needs someone to take care of their software. Our (and their) first priority is getting off of dBase, the current programmer already started working on that. Next we'll need to move VB6 to .NET (Framework, probably). I know there used to be converter tools around, but I've heard bad things about them. They're usually not worth the effort. Ideally, I'd rather just rewrite everything to web-based and cloud-ready .NET 6 applications, but I don't think we'll have the time nor money. Any tips (other than "RUN!")?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I have done this before, and how well it goes depends a lot on how good an engineer the person doing the conversion is. Put enough time and planning into the design you want to go to. Use value engineering to determine what has the most value in the conversion process. Don’t just replicate how the business rules are implemented. Migrate them using newer features where there is value in doing so. The more the VB code used OO techniques (available in VB4 - VB6), the easier your job will be. Don’t try to replicate VB procedural programming design in C#. Are your users desktop or browser? Determine the relative SDLC costs between WinForms and Blazor. Development time is less and performance is better with WinForms than any web-based GUI, but deployment costs may be higher. If you choose a web-based GUI, go with Blazor, not the Javascript-based approach. You’ll have less development time, better performance, and fewer headaches. Don’t farm out the work to consultants, H1-B developers, or offshore developers. The end result will need a lot of repair and be more expensive to maintain. Make sure to use someone in-house who is experienced in VB6 and in C#/.NET. A successful port will depend on deeply understanding both. One last thing - VB6 can host C# DLLs, including user controls for the VB6 GUI, all written in pure C#, using COM Interop. I did this a while back and it works beautifully if the developer understands both C# COM Interop and how VB6 recognizes classes, interfaces, and events. That allowed us to migrate the app from VB6 to fully C# piece by piece, without wasted code. Best of luck to you!
-
Dude, all I said was moving to VB.NET isn't really a good choice because of its limited lifetime. If a conversion to .NET (anything) was going to happen, a more appropriate target would be C#.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakAppropriate, sure. I am one that totally agrees with you as I once had to deal with a pile of VB6 and it is no fun at all. As for getting signoff or access to resources or getting people to actually want to be forward thinking that are the final decision makers? This is a completely different issue and the bigger the company, expect the least ideal option being selected. And no it won't make sense. And yes, you will be frustrated greatly.
-
The problem is VB.NET is your target. VB.NET is not getting any new features. There was a time when MS said they were developing VB.NET and C# side-by-side, with the same features between the two. That has since been killed. VB.NET is going to "wither on the vine" without new features. I'm going to say your best bet is to rewrite from scratch in C# instead.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakIs VB.NET the target? The OP isn't clear regarding that, although his statement can be taken that way. The wording indicates .NET Framework, not a newer version. That said, I agree, C# is a better choice for the reasons you stated. At the time, VB.NET was a panacea for the extensive VB community, but as time has passed, so has the need for VB.NET, and MS has done less and less with it. I'd target Framework 4.8.1 instead of a CORE release. Why? Lifecycle. Framework has a lifespan as long as Windows contains it, which is 2029 for Win10, and I'm haven't checked for Win11. Even versions (v6, v8) of CORE have a 3 year lifespan, while odd versions (v7) have an 18 month lifespan. That places an excessive burden on IT to update applications for which there is no business reason to update.
-
What the title says. For most people this (hopefully) happened some twenty years ago, but I'm going to inherit a lot of VB6 applications, some even still work with a dBase database. The programmer is going into retirement and this (reasonably large) company needs someone to take care of their software. Our (and their) first priority is getting off of dBase, the current programmer already started working on that. Next we'll need to move VB6 to .NET (Framework, probably). I know there used to be converter tools around, but I've heard bad things about them. They're usually not worth the effort. Ideally, I'd rather just rewrite everything to web-based and cloud-ready .NET 6 applications, but I don't think we'll have the time nor money. Any tips (other than "RUN!")?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
>
Quote:
Ideally, I'd rather just rewrite everything to web-based and cloud-ready .NET 6 applications, but I don't think we'll have the time nor money
Well, do it right the first time, or you will spend more time and more money to do the rewrite of the rewrite, or worse, the rewrite of the converted mess. Speaking from personal experience.....
-
What the title says. For most people this (hopefully) happened some twenty years ago, but I'm going to inherit a lot of VB6 applications, some even still work with a dBase database. The programmer is going into retirement and this (reasonably large) company needs someone to take care of their software. Our (and their) first priority is getting off of dBase, the current programmer already started working on that. Next we'll need to move VB6 to .NET (Framework, probably). I know there used to be converter tools around, but I've heard bad things about them. They're usually not worth the effort. Ideally, I'd rather just rewrite everything to web-based and cloud-ready .NET 6 applications, but I don't think we'll have the time nor money. Any tips (other than "RUN!")?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
You answered your own question. Re-write. Whether you need to go to web-based is a solution analysis; there are very valid reasons that desktop apps may provide a better solution than web-based or a hybrid mix of both may be the solution. We started with a large conversion that was going to be all desktop but ends up having some web-based modules where they made sense. Those are mostly parts having existing functionality on the web where some redesign can make the apps usable for in-house applications. Convert? We moved Access to Postgres in the original VB6 code using ODBC as the first step. I wouldn't spend any time looking at "converters". First, none will do a decent job converting VB6 to VS22. The best you'd get is having to do a multistep conversion that will still leave a lot of broken functionality. If native printing was used in VB6, and I think most did, there can be a lot of work recreating documents to VS. Depending on the size and budget, that may be a place to look at a paid tool to do that function or play with an html2pdf in VS or as a web service, locally or cloud. I would also look into the chance that some existing SaaS products can replace and integrate functionality. If it's feasible, I would phase the transition by moving functions to your new platform while leaving others in VB6 for now. A lot of that depends on your client's ability to work with that and if you do end up moving to the web/cloud for some or all of the project. That serves to spread the money out over time which may help. Depending on the codebase and your available resources, it could be a long road.
-
What the title says. For most people this (hopefully) happened some twenty years ago, but I'm going to inherit a lot of VB6 applications, some even still work with a dBase database. The programmer is going into retirement and this (reasonably large) company needs someone to take care of their software. Our (and their) first priority is getting off of dBase, the current programmer already started working on that. Next we'll need to move VB6 to .NET (Framework, probably). I know there used to be converter tools around, but I've heard bad things about them. They're usually not worth the effort. Ideally, I'd rather just rewrite everything to web-based and cloud-ready .NET 6 applications, but I don't think we'll have the time nor money. Any tips (other than "RUN!")?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
My company is currently taking our primary VB6 app (serves 100s of clients via RDS RemoteApps) and is converting to .net6 backend / vue frontend. We first looked at all the tools that have been mentioned so far. We would have been happy to stay a desktop app if we could have converted from VB6. In each case the use use of 3rd party controls (grids, drop downs, calendars, etc.) pretty much killed each of those options. I am bringing it up as a warning, so you are aware of a possible impediment. We could have attempted to convert and recoded to an updated front end, we chose not to after testing. For us the rough calculation didn't make sense to attempt to convert. VB6 and Crystal Reports were often used together. You didn't mention if CR is part of your project. We also use Crystal Reports for about 125 reports. About 15 of them are complex enough that we can't easily depracate CR. We came up with a way to host CR in container to save having a separate .net framework VM.
-
You are better off leaving the existing application as VB6 and just do the change to the database layer, VB6 still works perfectly and will continue to do so for a long time. Then just develop new features in .net when required. We spent about 5 man years converting one of our applications to VB.Net and now its just as (not)supported by Microsoft as VB6.
Interesting answer. Really depends on a system analysis but you could be right. That said, VB6 is slated to possibly bite the dust in 10 or so years. Better long-term planning might be to gradually move it to some other platform. It's pretty easy to maintain DB compatibility with multiple platforms. I don't see VB.net "just as not supported by MS" at all. I'm not saying I wouldn't choose something different, but VB support in VS22 seems to be pretty solid.
-
What the title says. For most people this (hopefully) happened some twenty years ago, but I'm going to inherit a lot of VB6 applications, some even still work with a dBase database. The programmer is going into retirement and this (reasonably large) company needs someone to take care of their software. Our (and their) first priority is getting off of dBase, the current programmer already started working on that. Next we'll need to move VB6 to .NET (Framework, probably). I know there used to be converter tools around, but I've heard bad things about them. They're usually not worth the effort. Ideally, I'd rather just rewrite everything to web-based and cloud-ready .NET 6 applications, but I don't think we'll have the time nor money. Any tips (other than "RUN!")?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I had to migrate several projects from 6 to .NET back when. I found re-writing was pretty straightforward, the only thing that really slowed me up was not being able to use arrays of controls (which the VB6 projects used extensively). Worked out a work-around (which needed much more coding, but ran eventually). Good luck.
-
>
Quote:
Ideally, I'd rather just rewrite everything to web-based and cloud-ready .NET 6 applications, but I don't think we'll have the time nor money
Well, do it right the first time, or you will spend more time and more money to do the rewrite of the rewrite, or worse, the rewrite of the converted mess. Speaking from personal experience.....
Haha spoken as if OP has the power to make the decision between "Do it right" and "Do it right now". OP says VB6 dev is retiring. Therefore, there is a clock on the project and handoff. I suspect the decision makers will be more likely to take the straightest path, not necessarily the wisest path. I guess if I were involved, I would want it to be clear on whether this is purely a lift and shift migration project or a modernization project.
-
What the title says. For most people this (hopefully) happened some twenty years ago, but I'm going to inherit a lot of VB6 applications, some even still work with a dBase database. The programmer is going into retirement and this (reasonably large) company needs someone to take care of their software. Our (and their) first priority is getting off of dBase, the current programmer already started working on that. Next we'll need to move VB6 to .NET (Framework, probably). I know there used to be converter tools around, but I've heard bad things about them. They're usually not worth the effort. Ideally, I'd rather just rewrite everything to web-based and cloud-ready .NET 6 applications, but I don't think we'll have the time nor money. Any tips (other than "RUN!")?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
It's almost undoubtedly true that this code needs to be updated from an architectural standpoint as well. No disrespect to the soon-to-be retiree. I've been in a situation where the code was crap, but nobody on the business side could explain how it was supposed to work. Thus, reworking it was more of, "well, good luck, hope you figure it out." Hope you're not in that situation, Sander.
-
I have done this before, and how well it goes depends a lot on how good an engineer the person doing the conversion is. Put enough time and planning into the design you want to go to. Use value engineering to determine what has the most value in the conversion process. Don’t just replicate how the business rules are implemented. Migrate them using newer features where there is value in doing so. The more the VB code used OO techniques (available in VB4 - VB6), the easier your job will be. Don’t try to replicate VB procedural programming design in C#. Are your users desktop or browser? Determine the relative SDLC costs between WinForms and Blazor. Development time is less and performance is better with WinForms than any web-based GUI, but deployment costs may be higher. If you choose a web-based GUI, go with Blazor, not the Javascript-based approach. You’ll have less development time, better performance, and fewer headaches. Don’t farm out the work to consultants, H1-B developers, or offshore developers. The end result will need a lot of repair and be more expensive to maintain. Make sure to use someone in-house who is experienced in VB6 and in C#/.NET. A successful port will depend on deeply understanding both. One last thing - VB6 can host C# DLLs, including user controls for the VB6 GUI, all written in pure C#, using COM Interop. I did this a while back and it works beautifully if the developer understands both C# COM Interop and how VB6 recognizes classes, interfaces, and events. That allowed us to migrate the app from VB6 to fully C# piece by piece, without wasted code. Best of luck to you!
The engineer will be me and possibly an employee. Best of the best, top notch, outstanding, brilliant, and the employee ;p
MSBassSinger wrote:
The more the VB code used OO techniques (available in VB4 - VB6)
None whatsoever, the original programmer is known to use hidden controls to hold values because variables are too difficult :((
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
We had to do what you have to do big time. But with todays knowledge, I would like to encourage you questioning not only VB.Net vs C#. Depending on the charactor of the application, having a Web Application might be worth thinking about. You may want to have a look at JMIX which is a Java Framework on top of Spring Boot which gives you almost the easy of good old VB6. It gifts you with all the typical features of a modern application and the sample apps they offer could be a good starting point for modifying them to cover the functionality you need. No, I am not getting paid by those folks :-) ... and I am still a strong supporter of VB (adopted it starting at Version 1.0). But now I heavily rely on JMIX and Windows getting independent from operating systems.
It's not going to be Java.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
You are better off leaving the existing application as VB6 and just do the change to the database layer, VB6 still works perfectly and will continue to do so for a long time. Then just develop new features in .net when required. We spent about 5 man years converting one of our applications to VB.Net and now its just as (not)supported by Microsoft as VB6.
Member 15966771 wrote:
VB6 still works perfectly and will continue to do so for a long time.
It works, but that's all you can say about it. Development and installation are a pain compared to modern solutions. There also aren't too many developers who are willing to maintain and develop old VB6 applications, especially this one. Besides, it works because it works for as long as it works. If Microsoft pulls the plug, which they officially did in 2008, 15(!) years ago, this company can file for bankruptcy.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
It's almost undoubtedly true that this code needs to be updated from an architectural standpoint as well. No disrespect to the soon-to-be retiree. I've been in a situation where the code was crap, but nobody on the business side could explain how it was supposed to work. Thus, reworking it was more of, "well, good luck, hope you figure it out." Hope you're not in that situation, Sander.
Undoubtedly, this programmer is known to use hidden controls to hold values because variables are too difficult :((
agolddog wrote:
Thus, reworking it was more of, "well, good luck, hope you figure it out." Hope you're not in that situation, Sander.
I hope so too! :omg:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
The problem is VB.NET is your target. VB.NET is not getting any new features. There was a time when MS said they were developing VB.NET and C# side-by-side, with the same features between the two. That has since been killed. VB.NET is going to "wither on the vine" without new features. I'm going to say your best bet is to rewrite from scratch in C# instead.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakYeah, my preference is .NET web application if possible. For desktop apps either Uno or .NET MAUI. All in C#, of course. I used to be fluent in VB.NET, but use it or lose it, and I'm not using it a lot anymore. Of course the client gets to have a say in this too :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
What the title says. For most people this (hopefully) happened some twenty years ago, but I'm going to inherit a lot of VB6 applications, some even still work with a dBase database. The programmer is going into retirement and this (reasonably large) company needs someone to take care of their software. Our (and their) first priority is getting off of dBase, the current programmer already started working on that. Next we'll need to move VB6 to .NET (Framework, probably). I know there used to be converter tools around, but I've heard bad things about them. They're usually not worth the effort. Ideally, I'd rather just rewrite everything to web-based and cloud-ready .NET 6 applications, but I don't think we'll have the time nor money. Any tips (other than "RUN!")?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
The company I work for has a large VB6 code base. I am the project lead for updating the main application to .NET 6 WPF/MVVM. In the span of about an year, one other developer and me have migrated about 75% of the old application. I would definitely stay away from the automatic converter tools. While they do work, you will be left with the same mess of an application that you originally inherited. Now is the time to use modern design principals to develop a testable and extensible application. Not to mention multiple threads! We also made the decision to keep the same look and feel as the VB6 application. Users have 20+ years of experience with the VB6 application, so giving them something completely new that works differently was met with major objections. Instead of thinking "Run", think I have the opportunity to build something from scratch using a better architecture and use cutting edge technology. That sounds like a lot of fun to me.
-
The company I work for has a large VB6 code base. I am the project lead for updating the main application to .NET 6 WPF/MVVM. In the span of about an year, one other developer and me have migrated about 75% of the old application. I would definitely stay away from the automatic converter tools. While they do work, you will be left with the same mess of an application that you originally inherited. Now is the time to use modern design principals to develop a testable and extensible application. Not to mention multiple threads! We also made the decision to keep the same look and feel as the VB6 application. Users have 20+ years of experience with the VB6 application, so giving them something completely new that works differently was met with major objections. Instead of thinking "Run", think I have the opportunity to build something from scratch using a better architecture and use cutting edge technology. That sounds like a lot of fun to me.
Tyler Evensen wrote:
Instead of thinking "Run", think I have the opportunity to build something from scratch using a better architecture and use cutting edge technology. That sounds like a lot of fun to me.
Yeah, my thoughts exactly. These are not easy jobs, but they can be quite fulfilling. We plan to keep the UI more-or-less the same, but to give it a more modern look and feel. No big overhauls there anyway. Hopefully the client will say the same.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I migrate VB6 to VB.net and C#. It isn't as difficult as you think. Feel free to contact me by email.
ed
Slow Eddie wrote:
Feel free to contact me by email.
How?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
