I'm supporting a very old, very large .NET Framework 4.8 project. There is significant interest within the engineering teams to upgrade it to modern .NET.
I'm just digging into the meat of a project like this. (Written over a dozen POCs and spent dozens of meetings convincing senior management to green light the project over the last 3-4 years. It is finally green lit and I'm finally starting on the ACTUAL codebase!
)
Here are some thoughts:
1) Begin with future maintenance in mind. Don't violate
YAGNI, but keep things modular with lots of automated testing so that you won't end up in Regression Test Hell.
2) Anticipate that the core logic might still be used for 10-20 years. But anticipate that the UI will need to be updated/reskinned every 3-4 years.
3) Start with clearly identifying the deep, core issues with the original that you want to get fixed.
If there are none, stop here, do not pass go. Keep the list reasonable. (Example: On my project we identified 4 things: an atrocious database schema that needed reworked, a horrible lack of logging, business logic that was randomly spread throughout different places in the app, and outdated security mechanisms)
4) Swallow hard and accept that unless you do things better than the previous team, you will simply be exchanging the poor choices of the previous app with a new set of poor choices in your new app. You should have regular discussions of "Is this is least stupid way we can do this" and encourage everybody to be able to point out flaws in your plan so that they don't turn into flaws in the final product. Push yourselves that nobody will show up in 5 years, see your app and go: What idiot designed this?"
5) Keep your app as simple and (modern) standards based as you can. You're first thought should be "Can this be done in the manner that the .NET Core framework suggests?" Always try to do things "the Microsoft Way" instead of reinventing the wheel. DON'T copy/paste code from the old that has far better, more modern ways to be done.
6) Under no circumstances allow the project to fail to deliver SOMETHING TANGIBLE TO MANAGEMENT in a reasonable time frame. No matter what anyone tells you, important people with have an invisible timer counting down in their head. If it goes off before your team has been able to show significant deliverables, your projects will get really ugly, really fast.
And, just to reiterate point 3: DO NOT just change an important app to modern .NET just because it is newer and cooler. If you aren't also improving the app, you are taking on major risk with little to no rewards.
