Azure consultant for .NET apps, Azure SQL and a bill you can explain

What does an Azure consultant do for a growing business?

An Azure consultant plans, builds and maintains your setup on Microsoft Azure: which compute service runs your app, where the data lives, who can access what, how deployments happen and how much it all costs each month. For a small or mid-sized business, the job is mostly about making good, boring choices and writing them down.

Azure is attractive to businesses already using Microsoft tools. If staff sign in with Microsoft 365, your software is written in .NET, or your data sits in SQL Server, Azure fits naturally. The risk is that Azure offers several ways to do almost everything, and the portal makes it easy to create resources that keep charging long after anyone remembers why they exist.

We usually meet clients at one of three moments. A server in the office is ageing, and the app on it needs a new home. A new product needs hosting and someone has already decided on Azure. Or the monthly invoice has crept up and nobody can explain the increase. Each starts with a review of what exists before any change is proposed.

• Choosing between App Service, Container Apps, AKS, VMs and Functions.
• Setting up Azure SQL or SQL Server and testing backups.
• Structuring subscriptions, resource groups, tags and access.
• Moving apps from on-premises servers, shared hosting or another cloud.
• Setting budgets, reviewing costs and removing waste.

App Service vs virtual machines vs containers: which Azure option fits?

For a typical web app or API, choose Azure App Service. Pick Container Apps when your app is already containerised or split into a few services, AKS when you truly need Kubernetes, and a virtual machine only when the software needs a full server you control. An Azure consultant should be able to justify the choice in two sentences.

Microsoft’s App Service overview describes it as a platform for web apps, mobile back ends and REST APIs that supports .NET, Java, Node.js, Python and PHP on Windows and Linux, or any custom container. It handles operating system patching, gives you managed certificates for custom domains, autoscaling, and staging environments for safer deployments.

Azure Container Apps, per Microsoft’s documentation, is a serverless platform for containers that scales on HTTP traffic, events, CPU or memory, and most apps can scale to zero, except those that scale only on CPU or memory load. It suits APIs, background jobs and small microservice setups without the overhead of running a cluster.

AKS gives you managed Kubernetes. It is powerful and appropriate for teams running many services with Kubernetes skills in-house. For one or two apps it adds cost and operational work with little benefit. Virtual machines remain right for software that needs registry changes, installed Windows services, specific drivers or full control of the operating system.

When is Azure the right cloud, and when is it not?

Azure is usually the right cloud when your business already runs on Microsoft: staff identities in Entra ID through Microsoft 365, applications in .NET, data in SQL Server, or Windows-only software. It is not automatically the best choice for everyone, and a good Azure consultant will say so.

The strongest Azure cases we see are line-of-business apps written in ASP.NET, internal tools where staff should sign in with their existing Microsoft work accounts, and reporting that feeds Power BI. Moving those to Azure keeps identity, data and tools in one ecosystem, which simplifies access control and audit trails.

How do you host .NET apps on Azure, old and new?

Modern .NET apps (the cross-platform versions after .NET Framework) run well on App Service for Linux or Windows, or in containers. Older ASP.NET apps on .NET Framework 4.x need App Service on Windows or a Windows VM. An Azure consultant checks which you have before planning anything, because it decides the hosting options and the cost.

For a modern .NET web app or API, we deploy to App Service with managed identity for database access, application settings and connection strings stored securely rather than in web.config files, and Application Insights for errors and performance. Container Apps is the alternative when the app is already Dockerised or has background workers.

Legacy ASP.NET Web Forms or MVC apps on .NET Framework can often move to App Service on Windows with small changes, such as replacing writes to local disk with Azure Storage and moving scheduled tasks to WebJobs or Functions. Microsoft’s App Service overview also describes a Managed Instance option for Windows apps that depend on COM components, registry access or MSI installers, which previously forced a move to a full VM.

• Check the target framework in each project file first.
• List dependencies: COM objects, Windows services, local file writes, GAC assemblies.
• Move secrets out of config files into App Service settings or Key Vault.
• Plan an upgrade to modern .NET separately, if it is worth doing at all.

If an upgrade is on the cards, our .NET Framework to modern .NET migration page explains scope and risks.

Azure SQL Database, SQL Managed Instance or SQL Server on a VM?

Choose Azure SQL Database for most apps: it is a fully managed database with automated backups and patching. Choose SQL Managed Instance when you need near-complete SQL Server compatibility, such as cross-database queries or SQL Agent jobs. Choose SQL Server on a VM only when you need full control of the instance or features the managed options lack.

Azure SQL Database suits new apps and many migrated ones. There are compute models for steady and bursty loads, and Microsoft’s free account page lists an always-free Azure SQL Database allowance of 100,000 vCore seconds a month with 32 GB of storage, which is handy for development and small tools.

Before moving an existing SQL Server database, we run compatibility checks, list features that behave differently in Azure SQL, estimate size and throughput, and test the migration on a copy. Backups are configured with a retention period that suits your business, and one restore is performed during the project so everyone knows it works.

How does an Azure consultant cut your monthly bill?

By finding what you pay for but do not use, resizing what is too big, switching steady workloads to commitment discounts and setting budgets so drift is caught early. Most small-business Azure bills we review contain at least one forgotten resource: a VM left running after a test, an unattached disk, or a premium plan chosen once and never revisited.

Start with the facts. Microsoft’s Cost Management documentation explains that budgets send alerts when thresholds are exceeded but that resources are not affected and consumption is not stopped. It also notes cost data is typically available within 8 to 24 hours. So a budget is an early warning, not a brake, and alerts arrive a day or so after the spend.

Budgets can trigger action groups, which can call Azure Functions or webhooks, so we can automate responses such as shutting down non-production VMs. For production, we prefer a human decision over automatic shutdown.

• Delete orphaned disks, public IPs, snapshots and old resource groups after confirming with you.
• Right-size App Service plans and VMs from actual CPU and memory metrics.
• Auto-shutdown for development and test VMs outside working hours.
• Consider reserved instances or savings plans only for workloads that run steadily all year.
• Ask your licensing adviser whether Azure Hybrid Benefit applies to Windows Server or SQL Server licences you already own.
• Tag resources by app and environment so Cost Management shows who spends what.
• Review Azure Advisor cost recommendations monthly.

What do the Azure free account and Microsoft for Startups offer?

New customers can open an Azure free account, which Microsoft’s page says includes a credit to use within the first 30 days, free monthly amounts of more than 20 popular services for 12 months, and more than 65 services with always-free monthly amounts. It is useful for trying things out, not for running a business indefinitely.

Among the always-free allowances, Microsoft lists Azure Functions with 1 million requests a month and the Azure SQL Database allowance mentioned above. For small internal tools and scheduled jobs, those can go a long way. For production apps with real traffic, plan for paid tiers from the start.

Startups can apply to Microsoft for Startups, which offers Azure credits alongside access to Microsoft tools and technical resources. Eligibility rules and credit levels change, so read Microsoft’s current page before counting on them. As with any credit programme, we design the setup so it is still affordable when credits run out, and we show the expected monthly cost after credits in our plan.

A warning we give every startup: generous credits make premium services feel free. Build as though you are paying from month one, and the credits become runway instead of a trap.

How much does an Azure consultant cost in India?

If we build your application for Azure, a custom web app or portal starts at ₹60,000 (about US$900), with deployment and handover included. For existing systems, migration, setup and cost-review work is quoted after we see the subscription and code, because two “simple migrations” can differ by weeks of effort.

Azure consulting quotes in the market vary widely. Partner firms often bundle licences, support plans and larger teams; individual freelancers range from bargain to premium. The spread usually reflects scope: whether identity and access, CI/CD, monitoring, a tested database restore, documentation and post-migration support are included. Ask each consultant to list those items separately.

Keep your two Azure costs apart: the consultant’s fee and Microsoft’s monthly usage bill. Good consulting pays for itself through the second, which is why our plan includes an estimated monthly Azure cost before and after the proposed changes.

• Number of apps, databases and environments.
• Legacy dependencies such as COM components or Windows services.
• Database size and acceptable downtime during migration.
• Identity work: Entra ID sign-in, roles, guest access.
• CI/CD, monitoring and backup requirements.

How do you migrate an on-premises server to Azure?

Migrate an office server to Azure in stages: inventory everything on the server, decide a target for each part, rebuild and test in Azure while the old server keeps running, cut over at a quiet time and keep the old server as a fallback for a short period. Lifting the whole server as a VM is sometimes right, but it is rarely the cheapest long-term option.

The inventory is where problems surface. Office servers tend to run more than anyone remembers: the main app, a SQL Server instance, file shares, scheduled tasks, a reporting service, maybe an old website. We list each item, who uses it and how, before choosing targets.

Typical targets are App Service for the web app, Azure SQL Database or Managed Instance for data, Azure Files or SharePoint for shared documents, and Functions or WebJobs for scheduled tasks. Where the app cannot move to a platform service without major changes, a right-sized VM is a sensible first step, with modernisation planned later.

• Inventory apps, databases, shares, scheduled jobs and integrations.
• Choose a target per item and estimate its monthly cost.
• Build in Azure and test with real users on a temporary address.
• Migrate data with a rehearsal first, then the final run.
• Cut over, monitor closely, keep the old server switched on briefly.

For desktop software being moved to the browser at the same time, see desktop application to web application.

Moving from shared hosting or another cloud to Azure

Moving from shared hosting to Azure makes sense when the application has grown beyond a simple website, especially if it is a .NET app on Windows hosting. Moving from AWS or Google Cloud to Azure makes sense when a Microsoft dependency, such as Entra ID sign-in or SQL Server, pulls you there, or when costs clearly favour it.

From shared Windows hosting, an ASP.NET site and its SQL Server database usually map straight to App Service and Azure SQL Database. Email should move to Microsoft 365 or another mail provider, not to Azure. DNS is switched after testing, with the time-to-live lowered in advance so the change spreads quickly.

From another cloud, we map service by service: virtual machines to Azure VMs, container services to Container Apps, managed databases to Azure SQL or Azure Database for PostgreSQL or MySQL, object storage to Blob Storage. Data transfer out of the old cloud may carry charges, which we estimate before you commit.

If search traffic matters, keep URLs identical or redirect them properly; our website migration page lists the checks.

Azure identity and access: Entra ID, RBAC and managed identities

Set Azure access up with three habits: people sign in through Entra ID with multi-factor authentication, permissions are granted to groups through role-based access control at the narrowest sensible scope, and applications use managed identities rather than stored passwords. Those habits prevent most access problems we find on small-business subscriptions.

Owner rights stay with the business. Consultants, including us, receive Contributor or narrower roles on specific resource groups, and access can be removed in a minute when the work ends. Production and non-production resources live in separate resource groups or subscriptions, so a test cannot break a live system.

Applications connect to Azure SQL, Storage and Key Vault using managed identities, which removes connection strings with passwords from config files. Secrets that must exist, such as third-party API keys, go into Key Vault. Staff-facing apps can use Entra ID sign-in, so people use their existing Microsoft work accounts and leavers lose access automatically when their account is disabled.

• MFA enforced for everyone with portal access.
• Roles assigned to groups, not individuals, at resource-group scope where possible.
• Managed identities for app-to-database and app-to-storage connections.
• Key Vault for remaining secrets; nothing sensitive in source code.
• Activity logs retained to show who changed what.

Which Azure region in India should you choose?

Microsoft’s list of Azure regions shows four in India: Central India in Pune, South India in Chennai, West India in Mumbai and India South Central in Hyderabad. For most Indian audiences, Central India is a sensible default because Microsoft lists it with three availability zones; the list also shows three zones for India South Central.

Keep your app and database in the same region to avoid latency and data transfer charges between regions. Microsoft’s list pairs Central India with South India, which matters for some backup and disaster recovery options. Service availability differs between regions, so we confirm every service and size in your plan exists in the chosen region before building.

If you serve customers abroad as well, a CDN or Front Door in front of the app can cache static content close to them while the app and data stay in India. Where your contracts or regulations say where data must reside, keeping resources in Indian regions is simple to configure; whether that satisfies your obligations is for your own lawyer to confirm.

Deployments on Azure: GitHub Actions, Azure Pipelines and staging slots

Every Azure app we set up deploys through a pipeline, never by copying files from someone’s laptop. We use GitHub Actions when your code is on GitHub and Azure Pipelines when you already use Azure DevOps; both deploy to App Service, Container Apps or VMs.

App Service supports staging environments, which Microsoft calls deployment slots. The pipeline deploys a new version to the staging slot, runs checks against it, and then swaps it into production. If something goes wrong, swapping back is quick. For Container Apps, revisions and traffic splitting play a similar role, letting a new version take a small share of traffic before it takes all of it.

Pipelines authenticate to Azure using workload identity federation or managed identities, rather than long-lived secrets pasted into settings. Database changes are scripted and applied as part of the release, with a backup taken first. The result is a release process your team can run on a Friday without fear, although we still recommend not doing that.

For a broader look at build and release automation, see our CI/CD pipeline setup page.

How to vet an Azure consultant before you hire

Judge an Azure consultant by whether they ask about your app, your data and your bill before recommending services. The right consultant proposes a simple architecture, explains the monthly cost of each piece and plans how you will operate it without them.

In the first conversation, ask which compute option they would pick for your app and why the others lose. Ask what your monthly Azure cost will be. Ask how they will migrate the database and how long users will be affected. Ask what access they need and how you revoke it. Ask what they will leave behind in writing. Specific, costed answers are the sign of experience.

• Good sign: asks for your Cost Management export before proposing changes.
• Good sign: suggests App Service or Container Apps before AKS for a single app.
• Good sign: plans a rehearsal migration and a tested restore.
• Red flag: wants the subscription created under their own tenant.
• Red flag: recommends buying reservations before measuring usage.
• Red flag: cannot explain how legacy .NET Framework dependencies will be handled.

For a general list of questions to put to any technical partner, see questions to ask an app developer.

Worked example: moving a manufacturer’s inventory app to Azure

This is a hypothetical scenario to show our planning, not a client story. Imagine an auto-parts manufacturer in Faridabad running an ASP.NET MVC inventory app on .NET Framework, with SQL Server, on a single Windows server in the office. Power cuts and a failing disk have made the owner nervous, and branch staff struggle to reach the app over a VPN.

The plan would move the app to App Service on Windows in Central India, since the framework version rules out Linux, with the database on Azure SQL Database after a compatibility check. Nightly stock reports, currently a Windows scheduled task, would become a WebJob. Invoices saved to a local folder would go to Blob Storage. Staff would sign in with their existing Microsoft 365 accounts through Entra ID, removing the VPN.

Cost controls would include a right-sized App Service plan chosen from the old server’s real usage, a monthly budget with alerts, tags by environment, and a staging slot that is scaled down when not in use. The database migration would be rehearsed on a copy, then run on a Sunday, with the office server left running read-only for two weeks as a fallback.

The quote would itemise inventory and assessment, App Service setup, code changes for storage and scheduled jobs, database migration, identity, CI/CD, monitoring and handover. An upgrade to modern .NET would be offered as a separate, optional phase rather than bundled in.

Azure consultant checklist before go-live

Use this list to check any Azure setup before it carries real traffic. If each point holds, your subscription is in better shape than most we are asked to review.

• Subscription and billing are in your tenant; the business holds Owner.
• Production and non-production are separated by resource group or subscription.
• Every resource carries tags for app, environment and owner.
• Compute choice is written down with the reason (App Service, Container Apps, AKS or VM).
• Azure SQL backups are configured and one restore has been tested.
• Apps use managed identities; secrets are in Key Vault.
• MFA is enforced and roles are granted to groups.
• Budgets with alerts exist, and someone is named to act on them.
• Deployments go through a pipeline with a staging slot or revision.
• Application Insights or equivalent monitoring alerts on errors and downtime.
• An architecture note, cost breakdown and runbook are handed over.

Some boxes unticked? Message us and we will tell you which ones to fix first.