The first surprise is how many familiar maintenance jobs disappear. Azure SQL Database for the on-premises DBA changes the job from running the engine to governing the database service. You still own what users experience and what the data means.
Stop Managing the Host
Azure handles the underlying operating system, engine patching, and routine service availability for Azure SQL Database. You do not choose a Windows power plan or size a transaction log file in the same way as a self-managed instance. Automated backups are built into the service, with retention depending on configuration.
I tell an experienced on-premises DBA to retire the server checklist before copying it into an Azure SQL Database job. Running a familiar maintenance command because it always ran on premises can waste resources. First learn what the service already does, then identify the work that still needs an owner.
Keep Ownership of the Data
The platform does not design your schema, classify sensitive columns, choose indexes for every workload, or decide who can read customer data. You still own backups’ recovery requirements, even when Azure produces the underlying backup files. Test point-in-time restore and define what a user does after an accidental delete.
I start with permissions and a representative application query. If those are wrong, a fully patched managed service still delivers a poor result. Which business operation would reveal a bad migration first? Make that the first acceptance test.
Tune the Workload, Not the Machine
Query Store, execution plans, wait information, and database-scoped settings remain useful. Service tiers control compute and storage behavior, so capacity changes look different from replacing a physical server. Measure CPU, data I/O, log I/O, and query response time together. A higher tier cannot fix a missing predicate or an unbounded report.
The query below lists active requests in the current database. Use it during a slow period and connect sessions to query text or Query Store history. A snapshot cannot explain a whole week by itself.
SELECT session_id, status, command,
wait_type, blocking_session_id,
cpu_time, logical_reads,
total_elapsed_time
FROM sys.dm_exec_requests
WHERE database_id = DB_ID()
ORDER BY total_elapsed_time DESC;Replace On-Premises DBA Instance-Level Assumptions in Azure SQL Database
A single Azure SQL Database does not expose every instance-level feature from a traditional SQL Server deployment. SQL Server Agent jobs, three-part cross-database queries, and server-scoped configuration need review. Managed Instance or a VM can be a better fit when those dependencies are central. Do not force a migration by quietly removing a business process.
I inspect stored procedures, application SQL, and job steps before cutover. Dynamic SQL can hide a cross-database name from catalog dependency views, so code search and actual execution tests are both needed. A migration checklist that counts databases but ignores their conversations is incomplete.
Learn the New Control Plane
The Azure portal, Azure CLI, PowerShell, and T-SQL divide administrative work. Some settings live on the logical server or Azure resource rather than inside the database. Identity, firewall or private endpoint access, service tier, and backup retention involve the control plane. Document who can change each resource and how changes are reviewed.
Do not store subscription secrets in a SQL script to imitate an old local job. I keep deployment identity separate from application identity. A small permission design at the start prevents later confusion about why a report connection can alter infrastructure.
Check Recovery as a User
Automated backups make point-in-time restore possible within configured retention, but the team must select the recovery point and validate the restored database. Geo-restore and failover features solve different outage scenarios. A regional incident needs application routing and access checks, not just a healthy secondary database.
I practice restoring a test database and running the first important transaction. The useful clock stops when the application works, not when the portal says the database exists. Keep connection strings, login mapping, and dependent services in the recovery plan.
Watch Cost Alongside Performance
Compute, storage, backup retention, and network movement contribute to the bill. Serverless and provisioned options fit different usage patterns. A tier upgrade can be quick, which makes it easy to leave expensive capacity running after a short test. Set a budget and record every scaling change with the workload reason.
This query shows database file allocation from inside the service. It is only one input to cost; use Azure billing and service metrics for the rest. Compare the same busy interval when changing tiers.
SELECT name, type_desc,
size * 8.0 / 1024 AS allocated_mb
FROM sys.database_files
ORDER BY file_id;
SELECT DATABASEPROPERTYEX(DB_NAME(), 'Edition')
AS database_edition;Update On-Premises DBA Monitoring and Alerts for Azure SQL Database
Infrastructure status is not an application service level. Monitor failed connections, query duration, CPU and I/O limits, deadlocks, and restore readiness. Add alerts for cost or unexpected tier changes. Keep retry telemetry visible so a wave of transient errors does not look like a quiet success merely because users eventually connect.
I ask for one dashboard that joins database symptoms to user operations. Several separate green charts can still describe a broken checkout. The DBA’s skill in relating a wait to a business request remains valuable in a managed service.
Build a New Azure SQL Database Runbook for the On-Premises DBA
Write down the actions the team can take: tune a query, adjust service capacity, restore a copy, rotate access, investigate a regional event, and contact platform support with evidence. Remove steps that require operating system access the service does not provide. Test each new step in a safe environment.
Azure SQL Database for the on-premises DBA removes host chores and changes the control surfaces. It does not remove accountability for data, performance, security, or cost. The best transition keeps the DBA’s diagnostic habits and retires the tasks the platform now performs.
Run one normal support day as a rehearsal. Find a blocking query, adjust an index, review an alert, restore to a new database, and explain a cost spike. Each task uses familiar SQL reasoning but a different control surface. That practice gives the DBA a map of what still belongs to the team.
I keep the old maintenance checklist beside the new one during migration. Cross out tasks the service owns, then assign the remaining work. Statistics, query plans, schema changes, data access, and application behavior still need attention. A managed service does not replace judgment. It changes which tools and buttons the judgment uses. The runbook should say exactly where to look when the first production alert arrives.
Related reading on this blog: SQL Azure: Add IP Address to Firewall and How to Measure Resource Status on Azure? Interview Question of the Week #264.
A managed database is not a managed application, it is an engine service with data decisions still in your hands.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
