Modernizing a Legacy .NET App with GitHub Copilot

Key Takeaways

[music] >> Hello and welcome to this episode of Siping Sync with Azure. In this we're talking about modernizing a .NET application using GitHub Copilot. And I've got a returning guest today, Crystal Folks. I'm going to give her a call and then we get started. Hey Crystal, how are you? Hey, nice to nice to be back. I'm so excited to talk about app modernization um and be able to show all the cool things we have to do with GitHub Copilot. Awesome. Well, let's get started and excited to see it. Awesome. Let's jump into the demo. So, when I think about this application that's shown here, we have uh some open source applications. So, when we were doing some of this testing for this, we used um this eShop modernization. It's a Microsoft reference app. And we use this application because it has .NET Framework 4.72 as ASP.NET Web Forms, Entity Framework, Autofac, and dependency injection. So, there's some old packages, um some things that are in there, and we wanted to really uh see how we can use our app modernization tools and extension for .NET to be able to show customers how true brownfield applications, legacy applications could be modernized. And so, you'll see here um we'll have the old legacy app solution here, and we're going to convert all of this into an actually uh .NET 10 modernized application. And we have some actual uh information that's shared within the databases as well. Uh so, when you think about some of these legacy applications, there's a big chance of having stored procedures locked up in the SQL database. And that's actually a very common uh problem that a lot of our customers have, where they're trying to extract the business logic from uh the web forms that are stored in the storage procedures in the SQL database. So, uh we created this actual repository to actually go off and uh look at ways so that we could actually modernize the application, and this is how we're going to do it. Before you dive into it, one of the biggest questions that most people have is these applications are written in way different thoughts and frameworks in mind from that time, right? Um and most of the enterprises have these types of uh legacy applications. How do you how do you define the complexity or or break down that complexity into how Copilot is going to ingest it? Or do you not have to do any of that, and you just let Copilot figure it out? Absolutely. So, we do have some extensions built into that, but the way that we uh suggest suggest and help customers do that is by using the plan mode. So, we actually suggest taking a step back, understanding the plan, and making sure that we have a uh GitHub Copilot has a great understanding of that context and that core knowledge base about what it's about to do and take implement that task. And so, it builds upon that not only our uh app modernization extension, but I've got have some other built-in tools to help actually get that along. And so, it has some security tools that you can do, and the fun part about this is uh if you're a customer that also have restrictions with MCPs, we could do this all without any MCPs. We're just using the exposed through tools through the GitHub Copilot um agent. Great. All right. Well, let's see the next step. Awesome. So, when we look at here into the code, we actually have a an agent and skills and prompts. So, we built a a one uh a modernization for the customer, so we built one skill here and basically it's a reusable skill, so we could take any .NET to .NET 10. Um and so we have it built for our customers to go through all the paths. Um and it takes on some of the frameworks, so it uses our app modernization extension that's built into VS Code and Visual Studio. And then it also takes our amazing open source repository that has Asam Co-pilot and it takes the best uh prompts and examples to go and use that .NET upgrade. So as things change, as the community is contributing, we're actually leveraging that as part of the script as well. And then we also have some phases, so it actually does a legacy assessment, it detects some of the things. It also installs App Cap, which is also part of the assessment tool of our app modernization, and it actually runs the assessment and gives it a score, and then we also do a security baseline. Uh so based on that, the next phase will go into a security baseline. And basically in our security check, we'll actually look at all the tools. We use an open source tool to actually determine which tools is needed based on the language and um and based on the database framework as well. And it will do a scan of everything. So before we even modernize, we're taking a step back and giving a security baseline. From there, we'll come up with a modernization plan. And then it will create that plan and then work to do those tasks accordingly and then upgrade the code as well and check for patterns that are making sure we address any security patterns while we're doing the modernization. So that's the kind of extended piece that we're taking here from the just using the traditional Git App Mod tool uh for .NET is we're taking the security suggestions and interjecting that so that when we upgrade, we're not also uh introducing more vulnerabilities and we're making sure that's addressed while it's also doing the upgrade. Great. So once you have all of these things planned, um how does GitHub co-pilot then go ahead and implement on this plan? Yeah, so between the next couple phases, we did an implementation plan where it actually does the out of dedicated output, as well as a database migration plan. So, a lot of our customers are also interested in upgrading and moving our their database from on-prem into Postgres SQL or other platforms so that they can get more opportunity to do more modern architectures. And so, that's one of that. We'll do another security baseline, and then we also do some test coverage. So, what does this look like when it's actually done? So, let's go back into the actual repo. And what it actually happens is it creates and actually does this plan here from end to end. So, what happens here is when we get to the one prompt script, all it needs is to do {slash}.net temp modernize agent upgrades. And so, basically we'll take this and create a a new take the legacy application and rerun this full modernization through the process and steps that I showed. What actually comes back at the end of it is a docs folder that has all the migration of the assessments and the the baselines so that we can actually work through the application. So, what happens here in this docs folder will actually have all the assessments that we we just talked about once it's done running in Gap co-pilot, and it will provide all these assessments. So, it actually does the baseline, and it understands a target .net legacy, and then it takes it to .net 10. It actually gives an understanding of the project structure, and what's really important here is a lot of customers when we're talking about app modernization, the big key here is once they do all the assessment right now does a couple of lines of code and says, "Hey, these are all the changes that will be made." But sometimes you want to see that in diagrams, in some wireframes, and understanding how the structure in the app the how the database will change and what changes that need to happen throughout the full life cycle to do a migration project. Um and what database schemas will need to change. So, these are all the things that come back from our assessment, which is really important. It gives a business logic map as well and it where the future state for all the storage procedures, which is locked up in the DB. Um so, it's very helpful to help understand what the business rules they want to extract um and the dependencies of the packages before we start actually getting to the uh modernization. What happens there, we also do a security assessment, so it actually looks at the tools. And so, this is a way if you are trying to do local testing to understand any of the vulnerabilities that are built into your current application before we start actually doing the migration. And I said this is important again because this helps us understand what are patterns that we already have that we need to fix, so we're not introducing those new patterns into um our migration. So, this had some findings and critical findings that needed to happen and change here. Um so, this is assessment here and any attacks that they need to do. Then we had a modernization plan and then it comes up with a plan here. Um so, Copilot uh comes up with a plan and how to do the migration of those packages, what will be in the previous and um what needs to be a security fix and now it's going to take that into consideration as it does the migration. And this is actually going to call still calls our extension tool, but before it does that, it's going to have that influence and some of these prompts in these actual uh documents as it's doing the plan. So, it's actually leveraging our tools, but it's just adding some more details so that it could be more concise on how it does the implementation. Um when it does the database migration, it will actually move this one from SQL to Postgres. Uh and so, this is kind of one of those things that I wanted to do as a lot of customers want to move and modernize their DBs and that we actually use tools for that. So, does it matter which step the wants to or the team that is dealing with this wants to upgrade or modernize their database versus versus that handle the security bits versus modernize the code or do you is there a sequence that that they need to follow after this or it's just up to what the scenario is? Yes, it's up to what the scenario is, so it is customizable to your specific scenario as a customer, which is really great and it allows teams to work often and step in silos. So, if a security team and the your DBAs and your data your database administrators really want to focus on the the database migration piece, they can work on that specific piece and then they have a reusable prop for that stage as well. So, it can be broken down into those specific phases as well as if they want to kind of lead it to do it all at once, they could do that as well. We're working with some customers who are using the CLI to break up all of those phases and also do that to kind of work to really establish a dented workflows and breaking that down, so it's really reducing the time savings of a as an organization on modernizing the applications at all at scale. Yeah. And what I love about it is the is the plans are so customizable as well in terms of what format you want it to be, like if there's connectivity and dependencies that we want to see in the plan for like which service is going to be affected by which other service, how are they connected? Like you you have a table there, but there's definitely possibilities to do like a mermaid diagram or things like that where you could really visualize how your services are connected to each other, so then you modernize and or how how are you going to handle each of those? If you want to even go from a monolithic to a microservice architecture as you do this, you could think about some of those things as well. Absolutely. And I actually did think about that. So, it actually does do some my diagrams as well. And it actually does some mermaid diagrams and actually shows these structures in it. I'm just getting ahead of you. So, yes, please show that. Absolutely. That was the biggest ask was how do we actually get the you know, visualization of that? >> Yeah. Uh because as the architecture change, a lot of the customers that we see that are using our tools would love to see like in a diagram like what was actually architecturally changed since doing this modernization, which I feel like that's a thing that's coming up very soon within our product and we've been giving them that feedback because customers really do want that feature to know, hey, what really fundamentally changed in the architecture? Uh and the flow requests, right? As as we're going through that and we're actually thinking about deploying this to cloud, what is the changes in the architecture flow, the networking that will happen, um different tools and services that are introduced and how that would flow with those tools as well. And then last but not least actually that happens here is in the phase eight of the deployment plan, it actually uses the AppCat and also works with that to figure out a deployment plan for which service to put it on. It uses the same recommendations from AppCat because it is leveraging that same reporting. And then actually will give you the cost estimates and ways to containerize it and move it over. So, it actually uses the containerization feature to make it into a microservices as it does the upgrade as well. So, depending on that, it could also deploy and do that. In my example, I did choose a a Kubernetes architecture at the end of the modernized application and then you could see in the .NET the GitHub repo that you could see how the application got modernized into a Kubernetes application. And it's really cool where it's able to go and build and deploy and then you can use your infrastructure as code to be able to, you know, integrate that into your continuous integration continuous deployment process. Great. And then once you have this, then how do you trigger the the the code and starting to to actually implement this? All right, it's still with that one um so my assets here does it end to end. So that one prompt is all you need. It's one click and go and then as you go through the phases if you want to break them out, you can put into any human gate processes that you need to be able to do reviews at any stage. Thank you Crystal for joining me today and showing us this end-to-end journey of how to modernize an application, not just a .NET application, but I think this can apply to any application you're trying to modernize. So great great demo. Um where can people find the links for all the things that you were talking about to get started? Axel, it's a pleasure to be on. Um we can see the the files and resources will be down below in the description box where we can get to the GitHub repo exactly where you can learn about about the resources as well as the GitHub Copilot at mod extension. Please go review that and we'll leave details about how to use the .NET extension as well. Great. Well, with that, thank you so much for joining us today. We'd love for you to give these resources a try and if you ever get stuck anywhere or if you have feedback for us, please put that in the comments. We do get back to you in those as well. Looking forward to hearing from you and with that, see you next time.