A minimal-downtime migration of production SQL Server instances to SQL Server on an Azure VM — the method chosen from your assessment findings, the cutover rehearsed end to end in a dry run, and 'no data loss' demonstrated with reconciliation evidence rather than asserted. Quoted fixed in writing from the assessment, from $2,300; the listed three weeks run from kickoff to the end of hypercare and cover a single source instance — multi-instance estates are quoted and scheduled separately. This is the production-grade path. For a single small database where the cutover window does not matter, the [fixed-price database copy to an Azure VM](/services/sql-server-database-migration-to-azure-vm) is the simpler product.
Moving SQL Server to an Azure VM is not technically difficult. What makes it go wrong is that the mechanism gets chosen before the environment is understood, the cutover is rehearsed for the first time on the night it matters, and 'no data loss' is asserted rather than demonstrated. This engagement inverts all three. The method is decided by the findings of the SQL Server to Azure Migration Assessment, which is a prerequisite. The cutover is rehearsed end to end in a dry run before the real one. And completion requires seven measurable criteria to be met with evidence attached — not a status report saying the databases appear to be there. Our default method is a full backup, differential, and transaction-log restore chain, with the tail-log backup taken at the write freeze. It is the highest-fidelity approach available: the target is a page-level copy of the source, so users, permissions, indexes, constraints, triggers, CDC configuration, and every data type come across intact. It runs on Standard Edition, needs no primary keys, needs no Availability Group, and leaves the source untouched and instantly recoverable if you decide to abort. Where the findings point elsewhere — Azure Site Recovery for a whole-VM lift, the Azure Database Migration Service, or transactional replication for the specific cases where it genuinely is the right tool — we use that instead, and the report states why. Where this sits in our catalog: we also publish a fixed-price single-database copy to an Azure VM on the current SQL Server version, a replication-based move, and an upgrade-in-flight variant. Those are the right products for one or two small databases where a planned evening window is fine. This page is for production estates where the cutover window is measured in minutes, the evidence pack matters to an auditor or an application owner, the whole instance has to come across — logins, jobs, linked servers, permissions — and the target VM has to be built and tuned rather than simply provisioned. The assessment tells you which product you need before you buy either. Target version: unless the assessment says otherwise, we build on the current SQL Server release — SQL Server 2025 became generally available in November 2025 — with the database compatibility level held at the source level until the Query Store comparison says it is safe to raise. That is also the clean way off the Extended Security Update treadmill: SQL Server 2016 left extended support in July 2026, and 2017 follows in October 2027.
Sign-off requires all seven, each with evidence attached to the closeout report. Not one of them is a matter of opinion.
Confirm the assessment findings still hold. Agree the cutover window, the fallback period for the source server, the ten queries that form the performance baseline, written abort criteria, and who has authority to call a rollback on the night. Build the target VM to specification — size, disk layout and caching policy, instance configuration, tempdb, instant file initialization, lock pages in memory, max memory, MAXDOP — with SQL Server licensing applied (Azure Hybrid Benefit or pay-as-you-go image); or, where you have built it yourself, validate it against the specification before anything is seeded. Connectivity is a prerequisite, not a week-one task: the window assumes it is in place and throughput-tested at kickoff.
Take the full backup, copy it to Azure, restore `WITH NORECOVERY`. Establish the differential and log-restore chain and keep it warm and monitored until cutover — the source keeps running normally throughout.
This is the step most migrations skip, and it is why they fail. We execute the entire cutover against a copy: restore with recovery, remap orphaned users, deploy logins, jobs, and linked servers, run the reconciliation queries, execute the application smoke test, and then execute the rollback. Timings from the dry run become the quoted cutover window, and the go/no-go for the week-three cutover is taken on its results. Anything that surprises us happens here, on a Tuesday afternoon, not at 2am on cutover night.
Revoke application logins → set source databases `READ_ONLY` → tail-log backup → copy → restore `WITH RECOVERY` → remap users → enable jobs and linked servers → DNS or connection-string switch → application smoke test → reconciliation evidence captured. Go/no-go gate before the irreversible step; abort criteria in force throughout.
`DBCC CHECKDB` on the target. Backup job configured and proven with a restore test. Query Store comparison against the baseline; plan regressions addressed. Evidence pack assembled. Source server retained read-only for the agreed fallback period. Hypercare runs from cutover to the end of the three-week window with a named engineer, then the closeout report is issued.
Minutes, not hours — and we quote the specific number for your environment after the dry run, before the cutover is scheduled. The window is dominated by the tail-log backup, its copy and restore, the DNS or connection-string change, and the smoke test; the bulk of the data was restored `WITH NORECOVERY` days earlier. For a typical single instance it is well under an hour and usually a fraction of that.
Four ways, all recorded in the evidence pack: the tail-log backup restores with unbroken LSN continuity from the source, meaning every committed transaction is accounted for; per-table row counts match; `HASHBYTES` aggregates over each table match between source-at-freeze and target; and `sys.objects` counts confirm no missing objects. Then `DBCC CHECKDB` confirms the target is internally consistent. That is a demonstration, not an assurance.
From $2,300, fixed in writing from the assessment findings. The floor covers a single source instance migrated by the restore-chain method within the three-week window, with connectivity already in place. What moves the number above it: a second or third instance, database count and size, whether we build the target VM or validate one you built, the replication method where the assessment selects it, a network build, and hypercare beyond the window — each stated as a line in the quote, never discovered afterwards. The $950 assessment produces the quote, and you pay for the migration after you approve delivery.
Three weeks from kickoff to the end of hypercare for a single instance: target build or validation and seeding in week one, a warm restore chain and the dry run in week two, and the cutover itself — one evening — followed by validation and hypercare in week three. The window assumes connectivity is already in place and that the cutover slot falls in week three; if your business can only offer a later slot, the quote schedules around it. Multi-instance estates are quoted and scheduled separately.
Scope and rigour. The fixed-price database copy backs up your databases, restores them onto a new Azure VM running the current SQL Server version, and verifies they are available — a planned window, a small estate, a one-week job. This engagement is for production instances where the cutover has to be minutes, the instance has to come across whole — logins, jobs, linked servers, permissions — the target has to be built and tuned to a specification, and you need a reconciliation evidence pack and a rehearsed rollback. If you are not sure which you need, the assessment tells you; and if the smaller product fits, we will say so.
Because for a one-time move between two SQL Servers it is usually the wrong tool. Replication only carries the articles you publish — it does not bring logins, Agent jobs, linked servers, server-level objects, or several data types, and it cannot publish a table without a primary key at all. A log-restore chain brings the database across as an exact copy with none of those restrictions, needs no Enterprise features, and leaves the source untouched. It is faster to set up, lower risk, and higher fidelity. Replication is the right method when the source genuinely cannot tolerate a write freeze of any length, when you are migrating a filtered subset rather than a whole database, when changes must flow back to the source during a transition, or when the version span rules out a restore-based method. The assessment identifies those cases; where it does, we use it, and the replication-based service exists for exactly that.
No. Neither the default method nor the replication method requires an Availability Group, and both run on Standard Edition. If a vendor has told you that minimal-downtime migration requires Always On, that is not correct.
Not for the default method — a log-restore chain copies the database at page level and does not care about keys. It is an absolute blocker for transactional replication, which is one of the main reasons we do not default to it.
Yes, where the quote includes it — size, disk layout and caching policy, instance configuration, tempdb, and the rest, to the assessment's specification. If you would rather build it yourself to that specification, the quote drops accordingly and we validate what you built before seeding. Building it wrong is the single most common cause of 'the migration worked but everything is slower', so if you are not confident, let us build it.
The current release unless the assessment says otherwise — SQL Server 2025 became generally available in November 2025. Your database compatibility level is held at the source level until the Query Store comparison shows it is safe to raise. If an application vendor only certifies an older version, the assessment records it and we build that version instead. A version move is also how you leave the Extended Security Update question behind: SQL Server 2016 left extended support in July 2026, and Microsoft's current guidance is that its ESUs are paid even on an Azure VM — check Microsoft's lifecycle pages for the terms that apply to you.
Not within this engagement. Working, throughput-tested connectivity is a prerequisite. We build site-to-site VPN and ExpressRoute as a separate service, or your network team can do it. It is called out separately because it is the most common reason a migration slips.
We stop and roll back, using a runbook that was rehearsed during the dry run against written abort criteria you approved at kickoff. Because the source is left intact and read-only rather than decommissioned, rollback is a matter of restoring write access and reverting the connection change — minutes, not hours. Nobody has to improvise at 2am. The source stays available for an agreed fallback period afterwards; decommissioning it is your decision and outside this engagement.
That is one of the seven success criteria, not a hope. We capture a Query Store baseline of ten business-critical queries before the move and compare after. Regressions are addressed — usually cardinality-estimator changes from the version upgrade, handled by holding the compatibility level or applying Query Store hints.
Yes. We configure backups on the target and prove them with a restore test before handover — leaving a newly migrated production database with no backup is not an acceptable end state. Ongoing monitoring and maintenance after hypercare are available under the Azure Resource Monitoring and Maintenance service.
Possibly. Managed Instance removes the patching, backup, and HA burden and is the better answer for a substantial share of migrations. It also imposes surface-area constraints that some applications cannot meet. The assessment compares the two against your actual environment and recommends one. We migrate to either.
Yes, or provide an equivalent findings document we can validate. Fixed pricing on an unassessed environment is guesswork that ends in a change order or a rushed cutover, and we would rather do neither.