AI-Powered Migration Plus Raw Experience With Mike Rousos  ## Metadata - Author: [[Hanselminutes with Scott Hanselman]] - Full Title: AI-Powered Migration Plus Raw Experience With Mike Rousos - Category: #podcasts - URL: https://share.snipd.com/episode/407df919-a821-4fbd-ac00-13f4c5cba0a2 ## Document Notes ## Highlights - **Embed Engineers With Customers** - Show up with customers to learn their real problems before you design fixes. - Bring feedback back to the product team to improve docs, bugs, and future releases. Transcript: Mike Rousos Yeah, it's a pretty unique role. So like you said, I'm part of the customer engagement organization inside of Core AI Platform. And it's a customer facing part of the engineering group. So, you know, we're part of the product group, but our role is to interact with customers as they're getting started with new technologies that we're developing. So I focus on.NET. We also have engineers who focus on Java, but for me, that primarily means helping customers get started with new versions of.NET, getting started deploying those applications into Azure PaaS environments and just anything related to sort of whatever, you know, the product group is working on, making sure that we're on the ground with customers, understanding Firsthand what that experience is like. So it is very much like being a consultant, except that, you know, we don't charge anything. We just show up. The way we get paid is in learning. We show up, we help make sure that customers are successful getting started with these products. And then we bring back to the product group, hey, here's where it worked. Here's where it didn't. This is what we need to fix in VNext. This is what we need to clarify in documentation. Here are bugs we need to address, whatever. ([Time 0:02:36](https://share.snipd.com/snip/0143414b-7886-460e-ac20-e7df6c8d921a)) - **Modernization Is Multi-Dimensional** - Migration means many different things: runtime upgrade, platform move, and refactor. - Break large modernization efforts into smaller, targeted tasks and tackle them step by step. Transcript: Mike Rousos Because when customers come to us and say, hey, we need to migrate, the first conversation is, well, what do you mean by that? Because sometimes it means, hey, we got this stuff on.NET 5, we need to go to.NET 9. Sometimes it's.NET Framework, you know,.NET Framework 4.8 or.NET Framework 3.5 coming up to either, you know,.NET Framework 4.8 or up to.NET 9. Sometimes it's moving into Azure. It's like, hey, we're on premise. We want to get into Azure App Service. Sometimes it's refactoring. We've got this giant monolith. We need to be more service oriented. And yeah, in this case, this particular customer, it was kind of a little bit of all of that. ([Time 0:06:35](https://share.snipd.com/snip/08a51b67-90a3-48be-97d1-5b001328bd85)) - **Prioritize Upgrades For Active Projects** - Upgrade active projects for performance, support, and ecosystem access. - Prioritize upgrades when you need cross-platform support, better hiring, or newer libraries. Transcript: Mike Rousos Actually a really good question. And actually, there have been times when I've told customers, you know, maybe you don't need to upgrade everything all at once right away. But there are benefits to upgrading, right? Like, and again, depending on what we mean by upgrade, the upgrading to the latest version of.NET is, that one's primarily going to be about performance, about supportability, about Cross-plat support. You know, if a lot of times, so this customer we're just working with, they had stuff targeting.NET 5. That's an easy upgrade because.NET 5 is out of support. You got to get up to.NET 8 or 9 if you want to be in support. Coming from framework,.NET Framework 4.8 is in support, will be indefinitely. So there's no supportability reason you have to upgrade. But if you have a project that's undergoing active development, there's a lot of benefits to getting onto.NET 9. Obviously, huge performance wins. You get the opportunity of running cross-platform if that's useful. You get access to the latest language and runtime features. The ecosystem is continually evolving. A lot of new packages now don't even support.NET frameworks. If you want to take advantage of all of that, you need to be on.NET 9. ([Time 0:07:20](https://share.snipd.com/snip/86122006-9f58-4ad4-ba4a-f7959d25a176)) - **Use PaaS To Reduce Operational Burden** - Move apps to PaaS to shift maintenance and patching costs to the cloud provider. - Evaluate cost and operational risk to decide if App Service or other PaaS fits your needs. Transcript: Mike Rousos Yeah, absolutely. I mean, so that migration into Azure is sort of that other type of modernization we were talking about in that one. It really is all about where the costs are, where the risk is. Cause yeah, if you've got this VM that you were running your blog on, you have to keep that up to date. You have to patch windows. You have to worry about all of that maintenance of the, of the, of the server. Whereas you go into app service, that's taken care of for you. All you have to do is, you know, focus on the thing you want to do, which is create the blog. And so, yeah, the customer that you were talking about that we were working with most recently, that was their motivation. They had worked with our account team to understand the cost benefits of being in Azure PaaS and not having to worry about maintaining this data center, not need to worry about all of That maintenance work that now becomes Azure's responsibility. ([Time 0:09:26](https://share.snipd.com/snip/a7c43834-53df-4723-838b-3ffac94e04b2)) - **Profile After Upgrading** - Profile and find bottlenecks after upgrading to realize performance gains. - Fix hotspots like slow SQL queries or network latency to let the runtime improvements shine. Transcript: Mike Rousos Hard to say. It really depends on the scenario. It will typically be noticeable. I'll say that. I mean, the details are going to depend from scenario to scenario. And I will also say that when we work with customers, we tell them it's not only upgrading to.NET 8 or 9 or 10, but it's also profiling, understanding where your bottlenecks are, because I have had scenarios where customers have upgraded from, you know,.NET Framework 4, 5 or whatever to.NET 9. Then they come back and say, oh, it's the same speed. We go and we look. It's like, well, it's because, you know, you've got this bottleneck in your code. Right. It's the same bad SQL query. Scott Hanselman Yeah. Yeah. You've got this SQL query that takes forever. Yeah. Network latency is a thing. You can't change that. Mike Rousos The way I explain it to customers is that when you upgrade to.NET Core, especially something modern like 9 or 10, the ceiling for what performance is possible goes way up. Now it's a question of, is your code set up to take advantage of that? But, you know, you've got all sorts of tools now in Visual Studio to easily profile that and help you identify where those issues are. ([Time 0:11:13](https://share.snipd.com/snip/c3bedb2f-522c-4f9c-8843-55b749466427)) - **Most Apps Lack Tests During Big Migrations** - The customer migrating dozens of apps had only one app with automated tests. - Operations teams often end up upgrading apps they never originally wrote and struggle to validate behavior. Transcript: Scott Hanselman Now we're not going to mention this company's name and I don't want to test shame them, but you know, they had 50 plus apps that they were migrating and only one of them had automated tests. One had tests. Yep. That's not cool, man. Mike Rousos Problems that upgrade these apps and then go to try and validate that they were working. And the other thing that complicated it was oftentimes the, the people who own the applications don't have time to do these upgrades. So you end up with a central like operations or it or cloud, you know, best practice team or someone owning these, these sorts of, uh, you know, upgrades. And now this person who's never seen the app before is responsible for making sure that it works on.NET 8, that it works in Azure, and they don't even know what the app's supposed to do. So one of the challenges we often help people with is to understand, hey, you got to make sure you've got a way of validating that this is good. ([Time 0:12:53](https://share.snipd.com/snip/edca1007-5b4f-4273-b043-2e430aec1861)) - **Validate With Tests Or Recordings** - Create tests or recorded playback to validate behavior before and after migration. - Use generated tests or Copilot to speed up validation when tests don't exist. Transcript: Mike Rousos You know, if you don't have tests up front, hey, record some stuff with play, right? Use GitHub copilot, generate some tests, something so that once you're done with this work, you can go back and say, okay, yes, it's, it's functioning the way it's supposed to, because. You know, the, the, the modernization itself is one chunk of time, but then often the, the validation of the app takes just as long. ([Time 0:13:47](https://share.snipd.com/snip/b3c7701c-b98e-4091-a05b-9303e7f56b13)) - **Tiny OS Assumptions Cause Big Breakages** - Small platform differences like slashes and registry access break cross-platform runs. - Expect OS-level differences when moving Windows apps to Linux and plan for them. Transcript: Scott Hanselman Right? Like, oh, this is a harmless little text file. It'll be fine. Hard-coded. You go to a Raspberry Pi. Yep. And then system.directory and the next thing you know. Or I had time zones where we were loading time zones out of the registry and registries don't exist on Linux. And then you're off and running. Absolutely. Yeah. Mike Rousos No, I mean, the time zone stuff's all managed by the operating system. And so it's going to be a little different. ([Time 0:16:40](https://share.snipd.com/snip/7b8117bd-7560-4b0e-ad3f-ab4e797eb0f4)) - **Scan Code For Cloud-Incompatible APIs** - Use static analysis tools to scan code for APIs that behave differently in the cloud. - Review tool reports and decide which differences require code changes before migration. Transcript: Mike Rousos For sure. Because we do have GitHub Copilot-based tools now that help with these experiences. Just about a week ago, we GA'd the GitHub Copilot app modernization tool, which is part of Visual Studio. And for your.NET apps, it will help you upgrade between versions of.NET, help you get them ready to run in Azure. But it is sort of an interaction between GitHub Copilot and documentation, guidance, static analysis tools that can help spot these sorts of things. We have an older tool called Azure Migrate Application and Code Assessment, which is just a static analysis tool, but it'll go through your whole solution. It'll find all of the.NET APIs you're calling that might behave differently in an Azure PaaS environment and put them in a list, in a report. So you can go look at it and be like, hmm, is this going to matter? Do I need to change anything? And it helps you not have those blind spots. ([Time 0:18:40](https://share.snipd.com/snip/ae106c91-f8cc-4bf4-bf40-66e2f647ab3a)) - **Pair Deterministic Tools With Copilot** - Use GitHub Copilot to orchestrate migration steps and handle ambiguous edge cases. - Combine deterministic tools (Roslyn analyzers, CLI) with Copilot for intelligent error handling. Transcript: Mike Rousos And then also this tooling that we have. Now it's brand new. Some portions are still in preview, but being able to have a tool that can use a knowledge base that's provided by a built-in MCP server and use that knowledge base to understand how some Of these transformations have to happen, well, then it can take that code, do some of the transformation for you, and get you ready to do whatever it is you need to do in the new world. Scott Hanselman That's a great point. I think that a lot of people think that LLM- migration is copy pasting 10,000 lines into a thing and like figure it out. But there's a programmatic aspect to it. There's tools, there's MCP servers. There was a really solid migration experience long before AI was a thing. Most of my migrations were done with the actual, you know,.NET migrate command line tool. Yeah. That still exists, right? So like putting the LLM around the edge cases is helpful, but it's going to be calling into actual tools, Roslyn analyzers that know how to do stuff, right? Yeah. Mike Rousos Yeah. Was that the tool that, um, it was sort of on the command line, you'd give it a.NET framework project and it would transform. Scott Hanselman Yeah exactly there was a command line one that was kind of a uh do it you know update your csproj and then it moved into visual studio and they gave it a visual thing and then now the one in Visual studio has a prompt and i think that there's tools and tooling wrapped around it wrapped around that yeah and that's the direction we're going is to have copilot sort of be part Mike Rousos Of the process. Not that it does everything, but that it orchestrates, it fills in gaps. ([Time 0:20:20](https://share.snipd.com/snip/2d28fa57-37e6-480e-a469-378f603473a7)) - **Each Migration Is Its Own Beast** - Every migration reveals unique, unexpected problems; no two apps are identical. - Treat modernization as individualized work despite common patterns and tooling. Transcript: Scott Hanselman You just said something I think is really important. You said unexpectedly. And this is the thing I think people don't realize is that I think I'm starting to realize it. And, uh, it is that LLMs deal with ambiguity, but if it's deterministic, it needs to deterministic. So there are things like what you need to do to upgrade a CSproj, what you need to do to make your startup.cs work correctly. These aren't these aren't opinions. They are best practices. Right. But then everybody's got some edge case. Everybody's got them something ambiguous. And that's where the LLM adds adds value. I think it's the mix of a proper migration tool that's that's like hardened for lack of a better word based on experience and then they're like oh this is weird yes send that and there's Mike Rousos Always something weird you know for the longest time you know before we had you know co-pilot we were trying to do the best we could with these static tools and they were okay. They got you, you know, 80% of the way there or whatever, but there's always something unusual. It doesn't like guaranteed you sit down with the customer, you try to modernize their app. You're going to hit something weird. You know, maybe I worked with a customer who, uh, had created this whole plugin model using system.added, which doesn't exist in.NET Core. Well, you don't see that very often, but it's out there. You know, I've got another customer who had this fancy remoting setup. There's, you know, there's always, there's someone I work with at Microsoft, one of my colleagues, she had a great expression for this. She said, helping customers and partners modernize apps is like a herd of unicorns. There's a ton of them, but they're each individual. ([Time 0:23:32](https://share.snipd.com/snip/c1437ffc-7fe2-4d74-b1ed-2f1fd89216d3)) - **Use Iterative Steps With Copilot** - Break large modernization tasks into smaller steps and use Copilot to create docs and tests. - Iterate: document, generate tests, then transform code rather than attempting one-shot migrations. Transcript: Mike Rousos Got an app that, you know, like this customer you're talking about at the beginning of the, of the show where they've got no tests, they've got 50 apps, a hundred apps, whatever. Maybe the place you start is you say, Hey, Hey, co-pilot write some documentation for me about how these projects work. Cause they're not well-documented. Okay, cool. We spend a day doing that day to co-pilot use these documents as input. Now help me create a good set of unit tests or some integration tests that are going to validate these work. Cool. Okay. Now that part's done. And you sort of incrementally walk through this process. Not that you just tell Copilot, Hey, here's a hundred thousand lines of code. It's got to run in Azure this afternoon, but you, you break it down and Copilot helps with each piece along the way. And that's where you really get the benefits of the, of the LLMs. ([Time 0:26:06](https://share.snipd.com/snip/0ae606a6-be89-4e51-a5d2-ed8c9641ece1)) - **Prompt Structure Improves Copilot Results** - Use structured prompts and templates to make Copilot perform reliable code transforms. - Define task lists and success criteria so Copilot generates reproducible, auditable migrations. Transcript: Mike Rousos Yeah, that was something our team came up with. Yeah, so that's one of the engineers on my team, Manfred, came up with that originally, and we've all sort of adopted it. What we discovered is that there are certain patterns of prompts that work well for Copilot. Copilot responds well to having a lot of structure in its prompts. It responds very well to having a detailed task list of steps it needs to walk through, like having like a to-do or a progress.md. So we found these best practices that made Copilot effective at code transformation. So what the X to Y transformation is, is it's really just a codification of that where we have a template that has all of these sorts of best practices embedded in it. So then when you want to transform your code, let's say you've got a problem, you need to update your code to log with library Y instead of library X. Instead of just saying to Copilot, please update my code to use library Y instead of library X, what you do is you tell Copilot, use this template that has a lot of best practices in it to Create a prompt that will move my code from X to Y. Make sure you follow this template that has all of these best practices in it. And so Copilot now makes you the prompt. Copilot doesn't make the change. Copilot makes the prompt. Then in a new session, you have Copilot execute that prompt and it's got all these best practices like, hey, it's got to use this task list. It has clear success criteria defined. All of these things that we've learned over the past year or two that make Copilot effective get put into that prompt so that it just works a lot more effectively than you just running In and like you said, just one-shotting it saying, hey, get rid of X, put in Y. ([Time 0:29:24](https://share.snipd.com/snip/11b5a78a-86ff-4039-82f0-1f8f958c07fa)) - **Experience Amplifies Copilot Value** - Copilot benefits vary by experience: seniors report larger productivity gains than juniors. - Junior developers may need guidance on what to ask Copilot to extract value. Transcript: Mike Rousos It really depends on the, on the customer. Cause it varies, but yeah, generally customers are telling me that they're 25% faster or whatever it is. It does depend on the kind of work they're doing. One of the things I saw recently with a customer was that it was the senior developers who were telling me these 25, 50% numbers. And the junior developers were like, no, it didn't make me faster. And when we dig in, I think there's a few factors that go into that. First of all, one junior developer told me, I don't use Copilot because I don't know what to ask it. I said, well, that's interesting. You sort of have to know enough about your problem space to know how something like GitHub Copilot chat's going to help you. But also it depends on the kind of work you're doing. I think Copilot always can be involved, but how much it's going to help depends on what it is that you're working on. If you're debugging something, yeah, you'll bounce some ideas off of it. It helps a little bit, but you know, maybe, maybe the, the savings is more limited. If you're, if you're generating a lot of code that, you know, you can describe how it's supposed to work. You can give a nice, you know, spec for it. Hey, cool. I can go off and it can do a whole day's worth of work in 20 minutes if it's the right kind of work. ([Time 0:31:56](https://share.snipd.com/snip/a83e1c2f-2b20-41f5-bb50-3756aa51f5c6)) - **Crossing The Finish Line Matters** - Seeing migrated apps run in production is a strong motivator and validation of modernization work. - Real performance wins and completed migrations make the effort worthwhile. Transcript: Scott Hanselman Well, I think it all comes down to exposure. You can't be successful unless you get exposed to these things. So you as a customer engagement person are getting to spend time with customers. So you know more than, you know, you and your team know more than anybody what it's like out there in the real world. I still remember what it was like to not work for Microsoft. So I have so much empathy when I go into a customer and I'm like, oh, man, I know what this code looks like and I know how it happened. And I know all the office politics that got us here. Mike Rousos Yeah. Yeah. You've been there. You, you know how you end up with that sort of a solution. Scott Hanselman And yeah, it's gotta be very satisfying to get it, to get it in production. And a lot of those apps that you did in this engagement are in production now. Mike Rousos Yeah. Yeah. And that's one of the things we love to see is just sort of the, you know, crossing the finish line, getting something running in Azure, running on.NET 10, or, you know, if it's a perf question, You know, seeing that, you know, 2x perf gain or whatever it is to say like, wow, yeah, that's, you know, hey, there's real value there. ([Time 0:34:40](https://share.snipd.com/snip/991ed48c-8e04-481d-a97d-abb3bd58b840))