Legacy .NET modernisation
.NET Framework to .NET 10, on-premise to Azure, and the parts of the system only one person understands.
The system runs the business and everyone is nervous about touching it. Usually there is an unsupported runtime, a server nobody wants to reboot, or one engineer who is the reason it still works.
- Starts with
- A 30-minute call
- Timezone
- UTC+05:30 · overlaps EU mornings and US evenings
What you get
- A test suite capturing what the system does today, including the behaviour people have quietly built workarounds around.
- A migration sequence ordered by risk, with a rollback path at every step and no date that depends on a long weekend.
- The first capability migrated and running in production alongside the old path, with traffic moved deliberately.
How it runs
Pin down what it does
Tests for the current behaviour before anything changes, which gives you the specification the system never had.
Replace one capability
Behind a routing switch with traffic shifted gradually, so a slice that misbehaves goes back to the old path in seconds.
Migrate the data last
Dual-write and reconcile until the new store is provably correct, then switch the old system off because it is redundant rather than because a date arrived.
Questions
Can we keep shipping features during the migration?
Yes, and you should. A feature freeze turns a technical project into a business cost, and that is the usual reason these efforts get cancelled halfway through.
Do we have to move to the cloud as part of this?
No. Getting off an unsupported runtime and moving to Azure are separate decisions with separate justifications. Doing both in one change doubles what can go wrong and halves your ability to tell which thing broke.
If this sounds like your situation, the next step is a call.