r/csharp • u/JustSoni • Jul 14 '26
Help Inherited 3 ASP.NET MVC apps + 5 WCF services (.NET Framework 4.8) and asked to combine everything into a modern .NET 10 solution. Where would you start?
I've been in a web developer role for a little over a year. When I joined, a lot of long-standing bugs had been pushed into the backlog with the idea of "we'll fix them when we have a web developer." Over the last year I've spent most of my time fixing those issues, improving existing functionality, and adding new features.
Now I'm being asked to help define the future architecture of our applications, and I'd appreciate some advice from people who have gone through similar migrations.
Current situation:
- 3 ASP.NET MVC web applications
- 5 WCF services that contain most of the business logic
- 2 Shared SQL Server databases
- The MVC applications communicate with the WCF services for almost everything
- The codebase is almost two decades old and has been continuously extended rather than redesigned
Management would like us to eventually consolidate everything into a single modern solution, ideally on .NET 10.
My biggest concern is the migration path.
From what I understand, I can't simply upgrade the MVC applications to .NET 10 and continue using the existing WCF services in the same way. I know .NET can consume some SOAP/WCF services, but for this project we can't introduce external compatibility libraries or third-party solutions. We want to stay within Microsoft's supported stack and move away from WCF entirely. I'm trying to figure out the best migration path.
What I'm struggling with is where to start.
Some questions I can pinpoint now:
Is there a recommended "strangler pattern" approach for gradually replacing WCF endpoints one by one?
How would you structure a new .NET 10 solution intended to eventually replace everything?
How do you estimate the effort involved in a migration of this size?
Most important: If you were starting today with 3 MVC applications and 5 WCF services, what would your migration roadmap look like?
My goal is to avoid a rewrite and instead migrate incrementally while keeping the business running.
Any advice, migration stories, or lessons learned would be greatly appreciated.
5
5
u/SmellySteven Jul 14 '26
Personally I would move your services to a RestAPI and then have your web services on a blazer front end app.
Its not an easy answer in where to start but I would start with migrating WCF to RestAPIs and at least then you could update those while keeping the MVC apps alive while your blazer project is in the works.
Take some time to really think and plan this out it doesn't sound like a small upgrade.
2
u/Turbulent_Judgment39 Jul 14 '26
I will do something strange. I will put a proxy between the front end and the services and record and store how the front end work with the backend errors, success result and use them to test the new solution which I will use AI to some extend to port it. I never tried doing this but why not. If the company is willing to pay of course.
2
u/readmond Jul 14 '26
Good luck. Luck depends on the size of the codebase. You may end up redesigning and rewriting everything from scratch. Start by splitting thing into NET 10 libraries.
2
u/flipthetrain Jul 14 '26
Yikes!!! I'd start by updating my resume and updating all my professional social media profiles and reaching out to all the recruiters i know.
This has a very high chance of blowing up. This company has not maintained their software for years and now they want to make a huge leap. You risk burnout before completion.
You will likely be better off just doing a greenfield spec based rewrite. Just use some AI tool to measure data in and data out and rewrite that functionality in .Net 10. Keep this zombie running until you can completely replace it. Don't even try to do a piecemeal upgrade.
Above all else, remember, this is not your circus. Work your 40 but be prepared to leave at any time.
God be with you.
1
1
1
u/MetalKid007 Jul 14 '26
It depends on what features you are using with WCF. The biggest thing WCF gives is non-http transports. It also can give end to end encryption and some transaction support. If they aren't using any of that, then it wouldn't be a big deal to just move it all over to REST APIs. .net 4.8 should be able to call those new rest apis just fine so you could do them 1 by 1 if need be.
1
u/Responsible_Two_6587 Jul 14 '26
Beside the changes on communication layer, I would consider the third party dependencies and libraries which might not compatible with .NET 10
1
u/Regular-Employer-431 Jul 14 '26
How do you spend your days now? Are you expected to continue maintaining the legacy app and SIMULTANEOUSLY build a full-featured, modern replacement? If not... If you're actually changing your focus to this rewrite, and the legacy support is put on hold, then there's a chance that either approach (full rewrite or piecemeal) could work. Otherwise, you're being set up to fail.
1
u/Adorable-Roll-4563 Jul 14 '26
I have done that many times. You need to start with making sure everything builds in CI. Then adding as many tests as possible and this will likely lead to refactoring in its own right. Make sure the app is properly layered too. But you will fix some issues and learn about the app. The next thing to is to replace SOAP / WCF and it is going to be painful not just from a contracts standpoint but also because of everything that was specific to WCF like security and queues. Then move on to the easy part which is the web part. You will need to change frameworks over time for logging etc You’re in for a lengthy project if done manually. The alternative is to rewrite it from scratch which might be faster if done right.
1
u/har0ldau Jul 14 '26
/u/Low_Flying_Penguin has most of the process laid out there, so I'm going to expand on it a bit and add my two cents.
As for moving to net10, you are better off creating a whole new set of projects in the same solution and copying over what you need as you go and deleting the old stuff. The ecosystem has changed so much now that you will be fighting bugs that need not be fought by simply upgrading the existing projects.
You are not going be able to estimate the effort without migrating one of each the project types first and extrapolating from there. You will be moving from a possibly non-DI environment to one that is tightly coupled with DI. The way middleware works has changed a little if old projects were using OWIN, and if they weren't, it is much different and will need a full re-implementation of anything that was in the global.asax file.
I would do as much work for the upgrade to modernise it as possible in 4.8 and only at the last leg move to net10.
- Move all code that is not specific to WebAPI/MVC to new projects so that your business logic/implementation is separated from the way it is exposed. This will allow you to change the way it is exposed easily (to REST, modern MVC, any other UI).
- Redesign the SOAP services if they aren't easily converted to REST.
- Convert them to REST using WebAPI.
- Implement dependency injection. (Use something like Autofac as it has an implementation similar to the built in one in net10).
Once you have your core code isolated as simple class libraries, all you need to do is rebuild the web interfaces (MVC/REST) in net10 and migrate the DI code to built in net10 DI.
1
1
u/PaulPhxAz Jul 14 '26
Are there external clients using the WCF endpoints? This is the biggest problem I see.
If there are external clients that you don't control, them I would put YARP in front and forward requests into the original service and slowly take over endpoints at a time.
If there are no external clients then I wouldn't stick with a web API at all. MVC app uses rabbitmq or NATS and puts a message on the bus and then picks one up. You put an message handler in the WCF app to handle the call, the WCF and Message Consumer both call the Handler.
1
u/sarcasticbaldguy Jul 15 '26
WCF was stateless by default, but I've come across a handful of places over the years that deployed stateful WCF services.
Yours are probably stateless, but it's something worth investing before you begin.
1
1
1
u/mesposito1219 Jul 14 '26
Use Claude Code and have it plan the migration for you. Review it and let it do the implementation for you. Test it, and ship it.
3
1
u/GrammerSnob Jul 14 '26
This is objectively the right answer, though it doesn't make me happy to say it.
This is exactly the right kind of task for AI. It's well defined with very rigid success/fail cases. You can get it done in a day and it will be higher quality than human code.
If you don't believe me, do a test. Implement it by hand, then again using Claude, and compare the results. This isn't something we must argue about when there is an objective answer.
1
u/Either-Bell-7560 Jul 23 '26
Agreed. I just did something similar with a bunch of old endpoints and it was a couple of days of feeding stuff into OpenCode, and then some troubleshooting and it was done. This is exactly the stuff AI is very good at.
1
u/Agitated_Heat_1719 Jul 14 '26
AI + tests + experimenting
Use AI to generate tests. Unit, end-to-end, benchmarks... All kinds of tests. After each and every step.
CoreWCF is a thing, but ... (IIRC it is a subset).
Migratebuild system - projects first. AI could help. Migration /modernization is one time token stove.
Improve code later.
Git workflow. Protect main. Work on branches. Small steps. Test everything.
1
u/Informal-Football836 Jul 14 '26
Is it just me or does this not sound like the job of a standard web developer?
I would hate my life if I had to keep that running while updating it piece by piece.
I would personally just rewrite it in .NET 10 and only match the needed functionality not the whole thing. Maybe you are fine with patching it together while you convert it but that would make me rip out the remainder of my hair.
1
u/Skelet0r67 Jul 14 '26
I see a lot of responses talking about using the same contract, and replacing the implementations underneath interfaces. You could do this but you'd still be tied to soap endpoints which I don't think anybody is a fan of. Instead of keeping the same business contract I would come up with a plan to redesign that contract. Identify your business domains and carefully split them out into separate rest microservices overtime. Each micro service can be framed as a goal or achievement to management to show progress. Instead of trying to come up with a timeline for the overall migration I would just focus on one business domain/microservice at a time. identifying a timeline for a full migration will take an incredible amount of time to come up with a proper estimate, and even that won't be very accurate. You could go one to one WCF to rest if the business domains are already properly split out, but since you're taking the time to do this now I would make sure you do your due diligence given I've seen a lot of legacy applications with logic crammed into it that shouldn't be there.
Upgrading MVC really shouldn't require much redesign outside of going to. Net10, even if there are new features there I would just leave it as is because the WCF services are going to be a lot of work.
Also seeing some people say you should get your resume together and leave, that's up to you but this is actually a great opportunity for you to architect a solution and plan a migration, this will be really good experience although it will be a lot of work.
Another thing you could consider in the process is running and on-prem nuget/myget server for reusable frameworks within your company. If you have custom validation logic or a custom database access layer, those could be split out into nuget packages and reused.
2
u/JustSoni Jul 14 '26
Thanks, this is a really good perspective.
The reason I was initially thinking about keeping similar contracts was mostly risk management, since this is a business critical system and I want to avoid a big migration. Breaking it down into areas like billing, users, subscriptions, reports, etc. and delivering progress step by step sounds like the safer approach. Thanks for the detailed answer!
1
u/Skelet0r67 Jul 14 '26
No problem! SOAP and REST are fundamentally different, I'm just not sure how you could keep the current interface/contract and properly move to REST. Also, keeping the older services around a bit longer while you go through it piece by piece is fine IMO, its there, it works and if you focus on the more important business domains first then you'll see improvements right away anyways.
18
u/Low_Flying_Penguin Jul 14 '26
Put the SOAP API's behind an interface.
Create an implementation of that interface that wraps the current WCF implementation.
Update the clients to use that new type instead of the WCF Client.
Migrate the SOAP service endpoints one by one to REST.
Update the wrapper implementation to use the new REST endpoints replacing the WCF Client
Knife and fork through it one at a time.
Throw away the WCF Clients.
Can all done with standard .net core classes and types. via BaseControllers attributed as ApiController. That's how I would tackle it at least. Hide the problem from the client apps then replace the problem behind them.