SQL Server Migration to Azure SQL Database
A migration of SQL Server databases to Azure SQL Database — Microsoft's most managed and usually cheapest SQL target, and the one that most often needs application changes to reach. We scope that work from the assessment before you commit to the platform, rebuild what the platform does not have (SQL Agent jobs, cross-database queries, linked servers), and migrate by the path your downtime tolerance dictates. Quoted fixed in writing from the assessment, from $3,200; the listed three weeks run from kickoff to the end of hypercare and cover a single database whose remediation the assessment has sized to fit the window. Remediation that does not fit is quoted separately and completed before the window opens; larger estates are quoted separately. If the honest answer is that Managed Instance costs you less overall, the assessment says so.
What this engagement is
Azure SQL Database is a single database as a service. There is no instance, no `master` you can put objects in, no SQL Agent, no cross-database queries, no linked servers, no CLR, no Service Broker, no `xp_cmdshell`, no Database Mail, and no restoring a `.bak` file. What you get in exchange is the lowest operational burden and usually the lowest price of the three targets, plus Hyperscale (currently up to 128 TB per database), serverless, and elastic pools if they suit your workload shape — and no end-of-support date, ever. For a modern, self-contained application database, it is an excellent target and the migration is straightforward. For a database that participates in three-part-name queries across four other databases, is driven by thirty SQL Agent jobs, and pulls data through a linked server to Oracle, it is a re-architecture wearing a migration's clothes. The dominant cost on this platform is almost never moving the data. It is changing the things around the data. SQL Agent jobs become Elastic Jobs, Azure Automation, or Logic Apps. Cross-database queries become an application-tier join, an elastic query, or a consolidation into one database. Linked servers become an integration service. Applications need retry logic, because transient connection faults are a normal operating condition on this platform rather than an incident. This engagement exists to do that work with the scope known in advance. Which is why the assessment is mandatory, and why it sometimes concludes that Managed Instance is cheaper once the remediation is priced. Where this sits in our catalog: we also publish an hourly SQL Server to Azure SQL Database migration for a single, self-contained database with no instance-level dependencies and a tolerable planned window. This page is for databases where the remediation is the project — Agent jobs, cross-database dependencies, an authentication model to change — and where the price has to be fixed and the cutover rehearsed; estates of several databases are quoted from the same assessment. The assessment tells you which product you need.
Which one applies to you
Unlike the Azure VM and Managed Instance services, the two delivery paths here split by downtime tolerance, not by estate size. On this platform the migration method is dictated by how much downtime you can accept, and the two methods differ substantially in constraint and effort. The assessment assigns the path; the quote states it.
| Planned-downtime path | Minimal-downtime path | |
|---|---|---|
| Method | BACPAC export/import, or Azure Database Migration Service offline | Transactional replication with Azure SQL Database as a push subscriber, or a CDC-based sync |
| Downtime | Proportional to data volume and shape — hours, quoted from the trial run | Minutes — the replication queue drains, then you switch |
| Primary key on every migrated table | Not required | Required — hard blocker |
| Source SQL Server Agent needed during migration | No | Yes — the source acts as publisher |
| Compatibility remediation and SQL Agent replacement | Included, to the effort stated in the assessment | Included, to the effort stated in the assessment |
| Best for | Databases that can take an evening or weekend window — the simpler, lower-effort path | Databases that cannot be frozen for hours |
The planned-downtime path is the right answer more often than people expect. If you can take a Saturday-night window, you avoid the primary-key constraint entirely and the quote is lower — the from $3,200 floor is this path, for a single database; the minimal-downtime path is quoted above it.
Larger estates, elastic pool consolidation, and Hyperscale migrations are scoped individually from the assessment findings.
Success criteria
Sign-off requires all seven, each with evidence attached to the closeout report.
What you receive
How the work unfolds
Confirm the assessment findings still hold. Lock the service tier and purchasing model — provisioned vCore, serverless, elastic pool, or Hyperscale — and the collation. Agree the downtime window, the fallback period, the ten queries forming the performance baseline, and written abort criteria. Confirm the delivery path the assessment assigned. Confirm that any application-side changes the assessment placed ahead of the window are complete.
The database-side work the assessment sized to fit the window: replace cross-database references, remove or re-implement CLR, Service Broker, and `xp_cmdshell` dependencies, convert `USE` statements and three-part naming, replace `BULK INSERT` from local paths with Blob-based alternatives, and migrate the authentication model to contained users or Microsoft Entra ID. Where the application itself must change — including adding connection retry logic — we specify precisely what, and it is done by your team or vendor, or quoted separately, before the window opens; we validate it once it is in.
Build the replacements for what Azure SQL Database does not have: SQL Agent jobs re-implemented as Elastic Jobs, Azure Automation runbooks, or Logic Apps; linked-server dependencies re-pointed to an integration approach; Database Mail replaced. These are built and tested before the trial run, not after cutover.
The full migration executed end to end against a non-production target — schema deployment, data load, remediated code deployed, replacement jobs enabled, application smoke test, reconciliation queries, and then the rollback. On the planned-downtime path this is what establishes your actual window, because export and import time is proportional to data volume and shape and cannot be estimated reliably from size alone. The go/no-go for the week-three cutover is taken on its results.
Planned-downtime path: revoke application logins → source database `READ_ONLY` → export → import → deploy remediated objects → enable replacement jobs → connection-string switch → smoke test → reconciliation evidence captured. Minimal-downtime path: revoke application logins → confirm distribution queue drained with a tracer token → disable replication → deploy → enable → switch → smoke test → reconcile. Go/no-go gate before the irreversible step in both cases.
Query Store comparison against the baseline, including confirming the chosen service tier sustains the workload — under-provisioning is the most common cause of a technically successful migration that everybody hates. Evidence pack assembled. Source retained read-only for the fallback period. Hypercare runs from cutover to the end of the three-week window with a named engineer, then the closeout report is issued.
Prerequisites
Who does what
IT Partner
- Select and implement the migration method against the assessment findings.
- Perform the database-side compatibility remediation the assessment quoted and sized to fit the window.
- Build and test replacements for SQL Agent jobs, linked-server dependencies, and other instance-scoped functionality.
- Configure the target database, firewall or private endpoint, and authentication model.
- Execute the trial run, including the rollback rehearsal, and establish the real downtime window from it.
- Run the cutover, hold the go/no-go gates, and call rollback if abort criteria are met.
- Capture and assemble all seven evidence criteria.
- Provide hypercare for the agreed period and remove our access at closeout.
Your team
- Provide a dedicated technical point of contact for the duration.
- Provide the access listed in prerequisites.
- Make application code changes we specify, or engage us separately to make them.
- Confirm and, if necessary, implement connection retry logic in the application.
- Sign off collation, service tier, and purchasing model.
- Execute the DNS or connection-string change at cutover.
- Make application owners available for both smoke tests.
- Approve the downtime window and abort criteria in writing.
- Coordinate any third-party vendor whose application or schema is in scope.
What's not included
Limitations & technical notes
Frequently asked questions
How much downtime will we have?
The planned-downtime path is a window proportional to your data — typically hours, and we give you the real number after the trial run rather than before. The minimal-downtime path is minutes, using transactional replication to keep the target current until cutover. Which one you want is usually a straightforward commercial question: the minimal-downtime path costs more and carries the primary-key constraint, so if a Saturday-night window is acceptable, take the planned-downtime path.
What does it cost?
From $3,200, fixed in writing from the assessment findings. The floor is the planned-downtime path for a single database within the three-week window, with database-side remediation and SQL Agent replacement limited to what the assessment sized to fit. What moves the number above it: the minimal-downtime path, additional databases and their size, remediation effort — how many Agent jobs need rebuilding, how many cross-database dependencies exist, whether the authentication model changes — and hypercare beyond the window. Application code changes are separate and are often the larger cost on this platform. The $950 assessment produces the quote; you pay for the migration after you approve delivery.
How long does it take?
Three weeks from kickoff to the end of hypercare for a single database: design, database-side remediation, and the Agent-job replacements in weeks one and two; the trial run at the end of week two; cutover, validation, and hypercare in week three. The window holds only because the assessment has already sized the remediation to fit and any application-side changes are complete before kickoff — where the assessment finds more, that phase is quoted and completed first, and the three-week window starts when it is done. Your quote states the schedule.
Why does migrating to Azure SQL Database take more effort than migrating to an Azure VM, when the platform itself is cheaper?
Because the work is different. An Azure VM migration moves a database between two copies of the same product. This is a platform change where SQL Agent, cross-database queries, linked servers, CLR, and Service Broker all have to be replaced with something else that does the same job. The Azure bill afterwards is usually lower — often substantially — but getting there costs more. The assessment models the total, including the Azure run-rate, so you can see whether the payback period justifies it.
How do you prove there was no data loss?
Planned-downtime path: the source is frozen read-only before export begins, so there is no window in which writes can be missed. Minimal-downtime path: a tracer token confirms the replication distribution queue has fully drained before replication is disabled — that is a go/no-go gate, not a check afterwards. Both then reconcile per-table row counts and `HASHBYTES` aggregates between source-at-freeze and target, and match `sys.objects` counts. All of it lands in the evidence pack.
Why does the minimal-downtime path use transactional replication when your Azure VM page argues against it?
Because the reasoning is about fitness for purpose, not dislike of the tool. Migrating to an Azure VM, you can restore a backup chain, which is higher fidelity and has no schema constraints — so replication is the wrong choice there. Azure SQL Database cannot restore a `.bak` file at all, so for minimal downtime, transactional replication with the database as a push subscriber is genuinely the right mechanism. It also brings its constraints with it, which is why that path requires a primary key on every table and takes the effort it does.
We have tables without primary keys. What now?
The minimal-downtime path is unavailable for those databases — transactional replication cannot publish a table without one, and there is no workaround. Your options are the planned-downtime path, adding primary keys where the schema is yours to change, or a different target platform. The assessment finds this on day two rather than week three.
What happens to our SQL Agent jobs?
They are rebuilt. Azure SQL Database has no SQL Agent. Depending on what each job does, the replacement is Elastic Jobs, an Azure Automation runbook, a Logic App, or a Function. We inventory every job in the assessment, build and test the replacements before cutover, and demonstrate them running on schedule as a sign-off criterion. This is often the single largest workstream in the project.
Our application queries across four databases. Is that a problem?
Yes, and it is the most common blocker on this platform. Azure SQL Database does not support cross-database queries and no setting changes that. The realistic answers are consolidating those databases into one, moving the join into the application tier, using elastic query for read-only cross-database reads, or choosing Managed Instance instead — which does support cross-database queries and is frequently the cheaper total answer once the rewrite is priced. The assessment prices the options.
Should we choose Azure SQL Database, Managed Instance, or an Azure VM?
Azure SQL Database for a self-contained, modern application database where you want the lowest run cost and the least operations work. Managed Instance where you need the SQL Server surface — cross-database queries, SQL Agent, Service Broker — without managing servers. Azure VM where you need OS-level access, an unsupported feature, or a specific SQL Server build. The assessment compares all three against your actual environment. We migrate to any of them, so the recommendation costs us nothing either way.
How is this different from your hourly Azure SQL Database migration?
The hourly service is the right product for one self-contained database with no Agent jobs, no cross-database dependencies, and a planned window you can live with — a short, time-and-materials job. This engagement is for databases where the remediation is the project and you want a fixed price, a rehearsed cutover, replaced functionality demonstrated on schedule, and an evidence pack. If the hourly product fits, the assessment says so.
Will performance be the same?
That is a measured success criterion. We capture a Query Store baseline of ten business-critical queries before the move and compare after. The usual cause of regression here is choosing a service tier below what the workload needs, which the assessment models from your observed resource consumption before you commit.
What is connection retry logic and why do you keep mentioning it?
Azure SQL Database occasionally drops connections as part of normal platform operation — failovers, maintenance, resource governance. Applications are expected to catch those errors and reconnect. Applications that do not will throw intermittent errors after migration, users will call them outages, and the migration will get the blame. Confirming your application handles this is a prerequisite, and adding it where it is missing is remediation work we will identify and quote.
Can we roll back?
Within the fallback period, yes — the source stays intact and read-only, and reverting means restoring write access and reversing the connection change. What you cannot do is restore an Azure SQL Database backup onto SQL Server, so anything written to Azure after cutover has to be reconciled manually. That is why the trial run rehearses the rollback and why the smoke test happens before users are let back in.
Do you need to do the assessment first?
Yes, without exception. On this platform the assessment routinely changes the answer — most often by showing that the remediation cost makes Managed Instance cheaper overall. Finding that out for $950 before you commit is the entire point.