SQL Server Migration to Azure VM

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.