Year One on Azure: What We Got Right, What We Got Wrong

By late 2011, I'd been running production workloads on Azure for the better part of a year. Multiple clients, different workload sizes, SQL Azure and SQL Server IaaS both. Enough reps to have opinions that weren't guesses. Here's what I'd tell someone starting that journey in mid-2011 based on what I'd seen.

What We Got Right

Starting small and expanding. Every client migration I did in 2011 started with one non-critical database. Not the crown jewels, not the invoicing system that runs the business — a reporting database, a reference data store, something where downtime during the migration would be inconvenient rather than catastrophic. This gave the team time to learn the operational differences before those differences mattered.

The economics analysis first. The clients who got the most out of Azure were the ones where we did the cost math before committing. Broadband bills, hardware refresh timelines, licensing costs on renewal — all on the table. For small businesses in the 5–50 person range, the numbers were consistently in Azure's favor for workloads that fit within SQL Azure's constraints. For larger workloads, it was more nuanced, but running the analysis explicitly meant we made intentional decisions instead of just following enthusiasm.

Azure AD from day one. The clients who started with Azure AD as their identity foundation had a much cleaner access management story at the end of the year than the ones who deferred it. Retrofitting identity is painful. Building on it from the start is not.

Written standards before first deployment. The standards doc I put together in mid-2011 saved me hours across subsequent deployments and prevented at least three categories of support calls that would have happened without it.

What We Got Wrong

Underestimating the connection resiliency problem. SQL Azure's connection handling was different from on-prem SQL Server in ways that weren't obvious until they bit you. Idle connection timeouts, throttling under load, transient errors that didn't exist in a LAN environment — all real, all required code changes or retry logic in the application layer. I wrote about this separately, but the short version: every application connecting to SQL Azure in 2011 needed explicit connection retry policies, and most weren't written with those. Audit this before you go to production, not after the first 3 AM alert.

The cross-database query constraint caught people off guard. SQL Azure didn't support cross-database queries in 2011. Each database was completely isolated. Applications that had grown up in an environment where USE OtherDatabase; SELECT * FROM SomeTable was normal had to be rearchitected. This was discoverable in the documentation but easy to overlook until you ran the first migration and half your stored procedures stopped working.

Monitoring was an afterthought. The first several deployments I did, I trusted Azure's portal metrics as sufficient. They weren't. By mid-2011 I was building external monitoring that sampled DMVs and logged to Azure Table Storage on a schedule, which was the right answer, but I should have built that infrastructure on deployment day rather than after the first performance incident.

Treating SQL Azure and SQL Server IaaS as equivalent. They're not. SQL Azure is a service. SQL Server on a VM is an application you operate. The operational discipline required is different, the failure modes are different, and the tuning surface area is different. Clients who came from IaaS experience sometimes brought on-prem SQL Server assumptions into a SQL Azure environment and got confused when those assumptions didn't apply. Set the expectation explicitly.

What I'd Do Differently

If I were starting over in 2011, I'd build a pre-migration checklist that covered: application vendor SQL Azure support confirmation, cross-database dependency audit, connection retry policy review, monitoring infrastructure design. Run the checklist before the first conversation about migration timelines, not after you've already committed to a date.

I'd also be more direct about the workloads where Azure wasn't the right answer yet. Some SQL Server feature dependencies — CLR, full-text search, certain Agent job patterns — weren't supported in 2011 and weren't going to be supported anytime soon. Telling a client "not yet, here's what needs to change first" was a better answer than finding out after the migration started.

Year one was a learning year. The platform improved significantly through 2012, and the clients who got through the early rough edges were positioned well for those improvements. If you're a year or two behind on this journey and wondering whether the early problems are still present — most of them aren't. But some of the lessons still apply. As always, I'm here to help.