Quick answer: Migrating .NET apps to Microsoft Azure works best as a staged project: inventory what you run, choose the right Azure compute for each workload, move data with a tested plan, wire identity and networking, then cut over with a rollback path. Lift-and-shift to virtual machines can be a first step. Refitting to App Service or containers often pays off after you learn the app’s cloud needs.
What “Azure migration” means in mid-2020
Teams usually move from on-premises Windows Server / IIS, from another cloud, or from aging colocation into Azure subscriptions. The .NET estate might include ASP.NET on .NET Framework, ASP.NET Core on .NET Core 3.1, background Windows Services, SQL Server databases and file shares.
As of August 2020 you are planning around .NET Core 3.1 LTS and supported .NET Framework versions on Windows. Newer major .NET releases after 3.1 are not part of this guide. If you still run Framework-only libraries, decide whether to move from .NET Framework to .NET Core before or after the cloud move. Sometimes rehosting Framework apps on Azure VMs or Windows App Service is enough for phase one.
Step 1: Assess without wishful thinking
Inventory for each app:
- Runtime (.NET Framework version vs .NET Core)
- Windows-only dependencies (COM, GAC, local disk assumptions)
- Authentication (Windows auth, forms, IdentityServer, Azure AD already?)
- Databases and storage (SQL Server, files, Redis, queues)
- Scheduled jobs and integrations
- Traffic shape and session state
- Compliance constraints (data residency, logging retention)
Mark each workload as: rehost (VM), refactor (App Service / containers with limited code change), or rearchitect (break into services). Honest labels prevent a “cloud project” that is really a multi-year rewrite in disguise.
Compare cloud options only when useful. An older AWS vs Azure overview can frame differences, but once you choose Azure, depth beats endless comparison.
Step 2: Choose compute per workload
Azure App Service (Windows or Linux). Strong fit for HTTP apps with less OS babysitting. Supports custom domains, TLS, slots for staging swaps, scaling rules and deployment from CI. ASP.NET Core apps fit well; many Framework apps run on Windows App Service with validation.
Azure Virtual Machines. Closest to “same as the old server.” Useful for stubborn dependencies, third-party installers or lift-and-shift timelines. You still patch OS and IIS. Budget for backups, NSGs and monitoring.
Containers (Azure Kubernetes Service or Azure Container Instances). Good when you already containerize or want portable deployments. AKS adds operational weight; do not choose Kubernetes only because it is popular.
Azure Functions. Event-driven pieces, webhooks and scheduled jobs after you isolate them. Not a dump for a whole monolithic IIS site on day one.
Pick per app, not one hammer for the whole company.
Step 3: Data migration plans
Databases dominate risk.
- Prefer Azure SQL Database or SQL Managed Instance when features match; validate compatibility (linked servers, cross-db queries, agent jobs)
- Use Data Migration Assistant and proven migration tools for assessment
- Plan downtime or continuous sync based on how fresh cutover data must be
- Move file shares to Azure Files or blob storage and update paths in config
- Redis and cache layers: confirm session and cache keys survive the move
Never discover connection string and firewall rules during the go-live weekend. Stage them in a pre-production environment that mirrors production networking as closely as you can afford.
Step 4: Identity, secrets and configuration
- Move secrets out of web.config on disk into Azure Key Vault or at least App Service settings
- Prefer Azure AD for employee-facing apps when licenses and UX fit
- For customer identity, keep your existing IdP patterns unless the migration includes an auth rewrite
- Replace hard-coded machine names with configuration
- Use slots or separate apps for staging with distinct settings
If APIs are part of the estate, keep versioning and contract tests in the pipeline. ASP.NET Core Web API guidance helps when you modernize the API edge during the move.
Step 5: Networking and security
Decide early:
- Public internet apps vs private access (VPN / ExpressRoute / Private Link patterns as your subscription supports)
- TLS certificates and custom domains
- IP restrictions for admin surfaces
- NSG rules for VMs
- Outbound calls to payment, email and partner APIs (allow lists may need updates)
Map every integration endpoint. Migrations break when a forgotten SFTP job still points at a decommissioned IP.
Step 6: Observability before cutover
In cloud, you cannot walk to a rack and look at a console.
- Application Insights or equivalent telemetry on web apps
- Centralized logs
- Alerts on error rates, CPU, queue depth and dependency failures
- Health endpoints for load balancers
Add unit testing in .NET and smoke tests in CI so deploys to Azure slots are not blind. Migration weekends go better when “green build” means something.
Step 7: Cutover patterns
Common approaches:
- DNS flip after data final sync (simple, downtime window)
- Slot swap on App Service after warmup
- Load balancer shift between old and new pools
- Read-only window for complex databases
Write a rollback: keep the old environment bootable until metrics look healthy. Define who watches which dashboard for the first hours.
Communicate with business owners: which features freeze, who answers user tickets, what “done” means.
Cost control that belongs in the migration
Azure bills surprise teams that copy oversized VMs.
- Right-size after a week of metrics, not before you have data
- Use staging SKUs that are smaller than production when safe
- Turn off unused disks and public IPs
- Tag resources by app and environment for chargeback
- Watch egress costs for chatty architectures
Migration success includes a predictable monthly range, not only a working URL.
Team skills and delivery
Cloud migrations fail when only one hero knows the subscription. Document:
- Resource groups and naming
- Deploy pipelines
- Who can approve production changes
- How to restore from backup
If you compare stacks for new greenfield work after migration, dotnet vs nodejs style decisions can stay separate from the rehost project so scope does not explode.
Hybrid and phased roadmaps
Few organizations move everything in one weekend. A phased roadmap might look like:
- Noncritical internal apps to App Service or VMs
- Reporting databases and read replicas
- Customer-facing web with careful DNS and SSL cutover
- Batch jobs and file exchange partners last, after networking is proven
Keep a living architecture diagram. Cloud resource sprawl happens when each team creates resources without shared naming and tagging. A short governance note (who creates what, where production lives) prevents orphan disks and surprise invoices six months later.
Compliance and logging during the move
If you handle regulated data, map controls before cutover: encryption at rest settings, admin access reviews, log retention and backup regions. Migration is a bad time to discover that an auditor needs evidence you did not collect. Align logging destinations early so you do not rebuild observability twice.
FAQ
Should we rewrite to .NET Core before moving to Azure?
Only if Framework blockers force it or you already planned modernization. Many apps rehost first, then modernize modules.
Is App Service always cheaper than VMs?
Not always. It often reduces ops time. Compare after realistic sizing. Ops hours count as cost.
How do we handle Windows Authentication apps?
Plan identity explicitly. Hybrid scenarios may need Azure AD, domain join patterns for VMs, or application changes. Do not assume App Service behaves like a domain-joined IIS box without design work.
What is a sane first pilot?
A lower-risk internal app or a read-mostly site with a clear owner, not your highest revenue system on the first weekend.
Move with a plan, not only a portal wizard
Azure migration for .NET apps is assessment, compute choice, data movement, identity, networking, telemetry and a cutover you can reverse. Wizard buttons help; architecture honesty decides outcomes. If you want help planning or building the target on Azure, see our custom development services.
