Lessons From Moving a Legacy .NET Platform to Azure

One of the bigger projects I led was moving an enterprise .NET platform from on-premise infrastructure to Azure. A system that had grown for years, with integrations, scheduled jobs and a lot of knowledge that lived only in people's heads.

The cloud part turned out to be the easy part. Here is what I would tell any team starting the same journey.

Inventory everything, especially the boring parts

The application is the thing everyone knows about. The trouble is everything around it:

• Scheduled tasks on a server that nobody remembers setting up.
• Files dropped into a network share by a partner every night.
• A hardcoded IP address that a third party whitelisted years ago.
• Certificates that expire in eight months and are installed by hand.

Every one of these tends to break quietly after a migration. Before moving anything, spend real time just listing what the system touches and what touches it. It feels slow. In my experience it saves more time than any other step.

Do not refactor and migrate at the same time

The temptation is huge: if we are moving it anyway, let us also clean it up, split the monolith, upgrade the framework. Resist it.

When something breaks after a migration, you want exactly one possible cause. If you changed the infrastructure, the architecture and the framework in the same release, every bug becomes an investigation. Move first, prove it works, then improve it in the new home.

Make environments boring

On-premise environments tend to drift. Test is a bit different from staging, staging is a bit different from production, and nobody is sure why. The migration is the best chance you will get to fix that.

Define infrastructure as code, keep configuration and secrets out of the codebase, and make it possible to create an environment from scratch. The first time someone rebuilds staging in an hour instead of a week, the whole team starts trusting the setup.

Plan the cutover like a launch

The actual switch is where most of the risk sits. What I would insist on:

• A written runbook, step by step, rehearsed in a lower environment.
• A clear rollback plan with a point of no return everyone understands.
• Data sync tested with real volumes, not a sample.
• The people who own every external integration on standby, because something always needs whitelisting.

Watch the bill from day one

On-premise costs are hidden in someone else's budget. In the cloud, every service has a price per hour, and it adds up fast. Oversized databases, environments left running over the weekend, logs nobody reads kept forever. Put cost alerts and tagging in place before the first resource, not after the first surprising invoice.

What I would do the same way again

Treat the migration as a project of its own, with its own owner and its own definition of done. Not a side task next to feature work. Platforms that get migrated "in between" tend to end up half in the cloud and half on a server nobody wants to touch, which is the worst of both.

Have you been through a migration like this? What was the thing nobody saw coming?