Migrations rarely stall because a team lacks the technical skill to move a server. They stall because something in the estate was never fully understood — a SQL Server edition that cannot be carried across quite as planned, a service account nobody can trace back to an owner, an application that authenticates in a way the target environment does not replicate cleanly. By the time those unknowns surface, the schedule has been signed off, the cost estimate has been quoted, and someone has to explain why both are moving.
For IT leaders planning a move of workloads to Microsoft Azure, two categories of risk deserve attention far earlier than they usually get: SQL licensing and identity configuration. Neither is glamorous. Neither shows up prominently in migration tooling dashboards. Both have an outsized ability to reshape a business case after the fact. Surfacing them during discovery — rather than during cutover — is the difference between a plan that holds and a plan that gets renegotiated.
SQL Licensing: The Line Item That Rewrites the Business Case
SQL Server licensing is one of the few areas of a cloud migration where a single misunderstanding can move a budget by a meaningful margin without any change to the technical scope. The difficulty is that licensing depends on details that are often undocumented: which edition is installed, how many cores are assigned to the host, whether the workload sits on physical hardware or a virtualized cluster, whether Software Assurance is active, and whether the application vendor certifies the target platform.
Consider how differently SQL Server workloads land in Azure. Lifting a database to SQL Server on Azure Virtual Machines keeps the existing licensing model and the existing application behaviour, but it also carries forward the patching, high availability design, and administrative overhead. Moving to Azure SQL Managed Instance or Azure SQL Database changes the licensing basis entirely — you are no longer licensing cores, you are buying provisioned capacity — and that shift is where Azure Hybrid Benefit either becomes a genuine cost advantage or quietly stops applying, depending on whether the underlying Software Assurance entitlement is valid and correctly scoped.
There are subtler traps too. Passive secondary replicas licensed under failover rights, virtualization hosts that were over-provisioned years ago and never right-sized, development and test instances running under production agreements, third-party applications that only support a specific SQL Server version and cannot move to a platform-as-a-service tier without vendor sign-off. Each of these is discoverable in a week of structured inventory work. Each is expensive to discover three weeks into a migration wave, when the architecture has already been drawn and the cutover dates have been published.
For organizations weighing Azure for the first time, this is why licensing review belongs in the assessment phase rather than the procurement phase. The question is not simply “what will Azure cost” but “what is legally and contractually portable, and what has to be re-purchased, re-tiered, or renegotiated.” An inventory that answers only the first question produces a confident-looking estimate built on an assumption nobody verified. Getting the edition, the core count, the virtualization model, and the entitlement status into one document early gives finance and architecture a shared version of reality — and gives the migration team a defensible number to plan waves around.
Identity Configuration: The Dependency Map’s Blind Spot
Identity problems behave differently from licensing problems. Licensing surprises arrive as a line item; identity surprises arrive as an outage. An application that authenticated against on-premises Active Directory using Kerberos, through a service account with an SPN registered in a forest nobody documented, does not fail during discovery. It fails on the morning of cutover, when the application cannot reach a domain controller and the support team discovers that the connection string was hardcoded in three places.
The dependency mapping stage is where these patterns should be exposed. In practice, this means answering some uncomfortable questions. Which SQL Server logins are SQL-authenticated accounts with static passwords, and where are those credentials stored? Which applications rely on Windows authentication and therefore need line-of-sight to a domain controller in Azure — and does that mean extending AD DS, deploying domain controllers in the target virtual network, or plumbing connectivity through ExpressRoute or a site-to-site VPN? Which service accounts are shared across multiple workloads, and which of them have rights far beyond what the applications actually use?
There is also a security dimension that is easy to defer and costly to defer too long. Migration is the natural moment to retire stale accounts, contractors who left two years ago, and service accounts with domain administrator rights that were granted as a shortcut. If identity configuration is only copied across rather than reviewed, the migration becomes a vehicle for carrying legacy privilege problems into a modern environment — and the hardening work that should have happened during the move becomes a separate project afterwards.
Modern Azure capabilities change the target design, but only if they are identified early. Managed identities can eliminate stored credentials for applications that support them. Azure Key Vault can hold the secrets that genuinely need to persist. Contained database users can reduce dependency on server-level logins. But none of that can be planned retroactively into a cutover that is already underway. Whether an application can adopt a managed identity, or must keep a service account, is an architectural decision that belongs at the strategy stage, made with the application team in the room.
This is precisely the category of risk that experienced migration consultants flag as routine. Undocumented dependencies and identity configuration gaps are not exotic findings — they are the standard contents of a discovery exercise, and they are the reason discovery deserves dedicated time rather than being folded into the first wave of execution.
What Early Discovery Looks Like, and What It Changes
An effective discovery phase has a defined shape. The first fifteen days of a structured migration engagement typically go to inventory and dependency mapping: cataloguing servers, applications, databases, and the relationships between them, including the SQL editions and licensing entitlements and the authentication paths each workload depends on. The following fifteen days cover architecture and readiness — preparing Azure landing zones, validating the migration strategy, and running pilot migrations before the approach is locked in.
That discovery can also run as a standalone engagement, which is what most first-time migrations and projects that stalled partway through actually need. A structured azure migration assessment analyses the current environment, builds the inventory, defines dependencies, and lands on a strategy that fits — sorting out effort, risk, and cost exposure before any workload moves. Standard timelines for that stage run one to three weeks, though real projects vary with the size and messiness of the estate.
What changes when this work happens early is the quality of the conversation. A consultant validating the migration strategy can say with evidence whether a SQL Server estate should lift-and-shift to Azure VMs or be re-platformed, whether the licensing position justifies hybrid benefit, and whether an application’s identity model needs rework before it is safe to move. Landing zones get prepared and hardened against a known requirement set rather than a guessed one, and workloads then move in planned waves with cutover runbooks and rollback readiness maintained throughout.
It also changes what happens after go-live, which is where cost and performance surprises usually land. Hypercare running thirty to ninety days, with performance tuning, rightsizing reviews, and FinOps governance, only works if the baseline was captured during assessment and the workload was sized against real data. Handover items — runbooks, architecture diagrams, knowledge transition sessions, access cleanup — determine whether the internal team can operate the environment independently. None of that is rescue work; it is the normal continuation of a process that treated cutover as one stage rather than the finish line. The point of uncovering licensing and identity issues early is not to avoid the migration. It is to make sure the migration you approved is the migration you get.
From Amman to Montreal, Omar is an aerospace engineer turned culinary storyteller. Expect lucid explainers on hypersonic jets alongside deep dives into Levantine street food. He restores vintage fountain pens, cycles year-round in sub-zero weather, and maintains a spreadsheet of every spice blend he’s ever tasted.