Make more of the SQL Server and delivery tools you already own. Start with reliability, reporting, data quality, security, and the work your teams need to complete. Modernize where the business case supports it.
The scenario below is fictional. It illustrates decisions and controls, not a deployed client solution, benchmark, or savings claim.
A practical starting scenario
A company uses an on-premises SQL Server database for everyday operations. People export spreadsheets for reports, releases depend on manual scripts, and leaders want better analysis. The first decision is what to improve, not where to move everything.
A named business data owner agrees the reporting need. The application and database owners map jobs, integrations, reports, dependencies, access, backup and recovery needs, support status, and licensing. Finance helps compare ongoing costs and expected benefits.
Compare the options by workload
- Retain and improve on-premises: check capacity, support, query performance, configuration, recovery, and whether existing reporting or integration features meet the need.
- Use hybrid services: consider approved cloud management, identity, analytics, or recovery while keeping selected operational workloads local.
- Use an Azure VM: assess compatibility and the need for server-level control, including the administration that remains.
- Use Azure SQL Database or Managed Instance: assess the application's dependencies, compatibility, service needs, migration work, and total cost.
- Add Fabric analytics: evaluate whether an approved analytical dataset justifies the additional service. This decision does not require replacing every operational database.
Assess connected databases and jobs together. Check the actual license rights before applying Azure Hybrid Benefit. Existing licenses do not automatically cover every cloud service or AI tool.
Compare full cost and risk ownership
Compare the same workload, service level, recovery target, data rules, and planning period, including staying put. Show future cash spending separately from full cost including staff effort. Existing investment can reduce new spending, but it does not make support, security, capacity, or refresh free.
| Option or component | Include in the same-period estimate |
|---|---|
| Retain and improve on-premises | Future support and license obligations, available capacity, power, DBA effort, security, backup and recovery, hardware upkeep, and refresh. Separate sunk purchases from future spending. |
| Add hybrid or Arc services | The retained local platform plus selected management or security services, connectivity, agents, administration, and operating evidence. Price the actual enabled features. |
| Azure VM | Compute, applicable SQL and OS rights, storage and I/O, backup and recovery, networking, monitoring, security, and administration that remains. |
| Azure SQL Database or Managed Instance | The chosen service tier and capacity, storage, recovery needs, connectivity, migration and compatibility work, security configuration, and application support. |
| Fabric analytics added to SQL | The operational database remains a cost. Add the selected capacity, retained cloud data, gateways, query and reporting workloads, destination controls, and support. Check current allowances and service terms. |
| GitHub or Azure DevOps, with Copilot where approved | Required user or feature entitlements, runners or build usage, artifacts, test environments, prepared data, pipeline engineering, code review, security checks, and maintenance. Check existing rights before buying again. |
Use dated quotes and actual contract rights, region, currency, capacity, growth, and review-effort assumptions. Include assessment, migration, parallel operation, recovery tests, updates, and exit. Set low, expected, and high demand cases. Do not count shared capacity twice when pricing a portfolio, or assume unused capacity has no competing use.
The business data or service owner sponsors the outcome; finance checks the spending and benefits; database, platform, delivery, and security owners operate agreed controls. A named authorized risk owner accepts any remaining risk within leadership's appetite and records conditions and a review date. A provider's responsibilities must be explicit. IT approval alone is not automatic business-risk acceptance.
Evaluate cash savings, released staff capacity, deferred hardware purchases, and reduced incident or outage exposure separately. Confirm that a deferred purchase was a credible baseline need; do not present possible avoided losses as guaranteed savings. Measure cost per accepted report, successful release, or useful task as appropriate.
Use the common total-cost comparison and fictional calculation, and risk-ownership checklist, before choosing a deployment.
Approve the data route and every copy
Define sensitivity, ownership, approved regions and recipients, permitted AI use, retention, disposal, and evidence. Include schemas, query results, logs, exports, test databases, and backups as well as operational records.
Azure Arc can connect management of an on-premises server to Azure, but inventory and usage information are transmitted. Do not describe it as a design in which no information leaves the premises.
Fabric mirroring creates a cloud replica for analytics. SQL Server source permissions, dynamic masking, and sensitivity labels do not automatically propagate to OneLake. Establish destination controls before sharing the copy. If raw sensitive fields cannot enter the cloud, use an approved prepared dataset or another ingestion design.
Check current version and topology support. Microsoft documents different replication methods for SQL Server 2016-2022 and 2025, with restrictions on the 2025 path. Monitor initialization load, replication health, and source logs. Free replication compute does not remove capacity, storage, gateway, query, and support costs.
Make releases repeatable and reviewable
Choose GitHub Actions or Azure DevOps around the organization's existing investment. Store agreed schema and application changes in source control. Use pull-request review, repeatable builds, tests, protected deployment identities, production authorization, and post-release verification.
SQL Database Projects and DACPACs can support schema delivery. Review generated deployment steps and possible data loss. A previous schema package is not a recovery plan for deleted data. Test the appropriate recovery or forward-correction approach.
Protect the build runner as an endpoint. Limit internal access, isolate untrusted code, and use short-lived deployment credentials where supported. Keep secrets and live sensitive records out of repositories and artifacts.
Use Copilot and agents within approved boundaries
Start with synthetic or approved statically prepared test data in a separate environment. Review what the active connection, open editors, result grids, instructions, selected model, and connected tools can expose.
SQL permissions enforce what AI-generated queries may do. Use the effective least-privilege identity appropriate to the task. Read-only access can still disclose information or consume resources. Prompts and approval dialogs do not reduce a powerful database login's permissions.
Content exclusions have client and mode limitations; they are not a universal filter for database results or tools. A production AI use case needs its own explicit authorization and evidence. The test pilot does not authorize broader access.
For agent-connected SQL tools, expose only approved views, queries, or procedures over the required information. Test that underlying data, write operations, administration, and unapproved destinations remain inaccessible.
Check who connects, from where, and for how long
Record the person or workload identity, owner, device or host, network, tenant and region, allowed data and actions, access duration, destinations, and activity evidence. Include developer workstations, database hosts, gateways, and runners.
Use supported identity controls, validated encrypted connections, segmentation, endpoint protection, patching, and credential handling. Check alternative login paths. Human MFA and device rules cannot simply be applied unchanged to every workload identity.
Prepare useful test data
Dynamic Data Masking changes displayed results without changing stored values and is not designed to defeat exhaustive queries. Start demonstrations and development with synthetic data or a properly transformed static dataset. Validate relationships, usefulness, and residual disclosure risk.
Encryption, access restrictions, masking, and tamper evidence serve different purposes. Select compatible controls for the workload, protect keys and endpoints, and test recovery.
Agree measures before the pilot
Useful measures can include reporting delay, accepted data quality, release lead time, failed changes, recovery results, access exceptions, review effort, and cost per accepted report or task. These are measures to establish, not claimed results.
Compare the evidence with retaining the current approach, improving it locally, and alternative cloud designs. Continue, change direction, or stop when the agreed criteria support that decision.
Explore SQL and data modernization services. A review provides agreed assessment and design outputs; implementation of a migration or production pipeline is separately defined unless explicitly included.
Technical references
Product behavior changes. Check the versions and configuration used for the actual engagement. References checked October 22, 2026: