A migration of production SQL Server instances to Azure SQL Managed Instance — the compatibility gaps found and priced before you commit to the platform, instance-scoped objects converted rather than lost, and a cutover that is a failover measured in minutes rather than a restore proportional to your data. Quoted fixed in writing from the assessment, from $3,900; the listed three weeks run from kickoff to the end of hypercare and cover a single source instance whose remediation the assessment has sized to fit the window. Remediation that does not fit is quoted separately and completed before the window opens; multi-instance estates are quoted separately.
Managed Instance is the right target for most SQL Server workloads that do not need OS-level access. You keep cross-database queries, SQL Agent, Database Mail, Service Broker within the instance, and instance-scoped collation. Microsoft takes over patching, backups, and high availability — and since the SQL Server 2025 update policy for Managed Instance reached general availability in March 2026, you can choose whether the instance tracks the latest engine continuously or stays aligned with a specific SQL Server release. For a lot of estates it removes an entire category of operational work, and it removes the end-of-support calendar with it. What it does not give you is a byte-for-byte SQL Server. FILESTREAM and FileTable are gone. `xp_cmdshell` is gone. SQL Agent exists but not every job subsystem does. Linked servers reach other SQL platforms only. CLR assemblies must be SAFE. Instance collation and time zone are fixed at creation — get either wrong and the only remedy is rebuilding the instance and migrating again. Every one of those is discoverable in advance. That is what the assessment is for, and it is why this engagement will not start without one. The failure mode we are engineered against is a client who is halfway through a Managed Instance migration when someone finds the FileTable. Our default method is the Managed Instance link, which uses distributed availability group technology to keep the Managed Instance continuously synchronised with your source SQL Server, then fails over on your schedule. Cutover is a failover, not a restore, so the window is minutes rather than proportional to your data volume. Microsoft currently supports the link from SQL Server 2016 (Service Pack 3 with the Azure Connect pack) through SQL Server 2025, on Standard, Enterprise, and Developer editions, with a minimum cumulative update per version; the assessment checks your build against Microsoft's current matrix. Where the source version or configuration rules the link out, we use the Log Replay Service — Microsoft's log-shipping-based path fed from backups staged in Azure Blob Storage — or a native restore from URL, and the report states which and why.
Sign-off requires all eight, each with evidence attached to the closeout report.
Confirm the assessment findings still hold. Lock the target service tier, vCore count, update policy, collation, and time zone — the last two are irreversible after provisioning and are treated as a formal written sign-off item, not an assumption. Agree the cutover window, the fallback period, the ten queries forming the performance baseline, and written abort criteria. Confirm that any remediation the assessment placed ahead of the window is complete.
Provision the Managed Instance into a correctly configured, delegated subnet with the required route table and network security group rules, or validate the one you have built. Provisioning a Managed Instance takes hours and can take considerably longer for the first instance in a subnet — it is started on day one rather than discovered as a delay later. Connectivity from the source site is verified end to end.
Address the gaps the assessment identified, to the effort it quoted and sized to fit the window: convert or replace unsupported SQL Agent job subsystems, replace `xp_cmdshell` calls inside stored procedures, re-point linked servers, resolve CLR assembly permission sets, and adapt `BULK INSERT` and `OPENROWSET` calls to Blob Storage sources. Work the assessment found that does not fit the window — application code changes, replacing FILESTREAM or FileTable usage, or moving the authentication model to Microsoft Entra ID across your applications — is quoted as a separate remediation phase and completed before this window opens, so the three weeks are never silently stretched.
Establish the Managed Instance link from the source, seed the databases, and monitor the synchronised state while the source keeps running normally. Where the link is not the chosen method, establish the Log Replay Service chain or the backup-to-URL restore sequence instead.
The full cutover executed against a test target: failover, login and permission remapping, Agent job enablement, application smoke test, reconciliation queries — and then 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. Surprises happen here, in business hours, not at 2am.
Revoke application logins → confirm synchronised state with zero pending log → failover → enable Agent jobs and linked servers → connection-string or DNS switch → application smoke test → reconciliation evidence captured. Go/no-go gate before the irreversible step.
`DBCC CHECKDB` on the target. Query Store comparison against the baseline, including confirming the chosen service tier actually sustains the workload. 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.
Minutes — and we quote your specific number after the dry run, before the cutover is scheduled. Because the Managed Instance link cuts over by failover rather than restore, the window is largely independent of how much data you have: a 2 TB database and a 200 GB database cut over in roughly the same time. The window is spent on the write freeze, the failover itself, the connection-string change, and the smoke test.
The link must report a synchronised state with zero pending log before failover is permitted — that is a go/no-go gate, not a check afterwards. Then per-table row counts and `HASHBYTES` aggregates are reconciled between source-at-freeze and target, `sys.objects` counts are matched, and `DBCC CHECKDB` confirms the target is internally consistent. All of it lands in the evidence pack.
From $3,900, fixed in writing from the assessment findings. The floor covers a single source instance migrated over the Managed Instance link within the three-week window, with connectivity in place and remediation limited to what the assessment sized to fit. What moves the number above it: remediation effort — how many Agent job subsystems need converting, whether the authentication model changes, whether FILESTREAM or a non-SQL linked server has to be replaced — plus instance count, data volume, whether we provision the subnet and instance or validate yours, and hypercare beyond the window. The $950 assessment sizes all of that and produces the quote; you pay for the migration after you approve delivery.
Managed Instance if you want the operational burden gone and your workload fits the compatibility surface. Azure VM if you need OS-level access, a feature Managed Instance does not support, a specific SQL Server version or build, third-party agents on the host, or the lowest Azure bill. Expect Managed Instance to be more work than a VM move: an Azure VM migration moves a database between two copies of the same product, while this is a platform change — instance-scoped objects are converted rather than copied, the authentication model often changes, and the target takes hours to provision. That is why the floor is higher and why remediation the assessment finds is scheduled ahead of the three-week window rather than squeezed into it. The trade is that you stop patching, backing up, and configuring high availability afterwards — permanently. The assessment compares both against your actual environment and recommends one; we migrate to either, so the recommendation costs us nothing.
In rough order: SQL Agent jobs using unsupported step types; `xp_cmdshell` buried in a legacy stored procedure; linked servers to non-SQL sources; `BULK INSERT` reading from local file paths; applications assuming Windows Authentication against on-premises AD; and FILESTREAM. Most are solvable. The point of assessing first is that you find out which are solvable, and at what cost, before you have committed to the platform.
For those databases, yes — Managed Instance does not support FILESTREAM or FileTable. The usual outcomes are moving the binary content to Azure Blob Storage with the application updated to match, or migrating those specific databases to an Azure VM while the rest go to Managed Instance. A split estate is a legitimate and fairly common answer.
You rebuild the instance and migrate again, and you pay for it twice. Instance collation cannot be changed after provisioning, and neither can the time zone. This is why both are a formal written sign-off item at kickoff rather than something inferred from the source.
Microsoft's current matrix runs from SQL Server 2016 (Service Pack 3 plus the Azure Connect pack) through SQL Server 2017, 2019, 2022, and 2025, each with a minimum cumulative update, on Standard, Enterprise, and Developer editions running on Windows Server. A source below the floor either gets patched first or uses the Log Replay Service instead. The assessment checks your exact build on the day, because the floors move with Microsoft's cumulative updates — do not rely on this paragraph for a build decision.
Within the fallback period, yes — the source server stays intact and read-only, and reverting means restoring write access and reversing the connection change. What you cannot do is restore a Managed Instance backup onto an older SQL Server; the platform does not support downgrading. For SQL Server 2022 and 2025 sources migrated over the link, Microsoft currently supports keeping the link after failover so that data can flow back to the source, which gives you a real failback path; for older sources, anything written to Managed Instance after cutover has to be reconciled manually. That is precisely why we rehearse the cutover in a dry run, agree abort criteria before the night, and run the smoke test before you let users in.
That is a measured success criterion, not a hope. We capture a Query Store baseline of ten business-critical queries before the move and compare after. The most common cause of regression is choosing General Purpose for a workload that needs Business Critical's local-storage latency — which the assessment models from your observed wait statistics, before you commit to a tier.
Managed Instance has SQL Agent, so most jobs migrate as-is. Jobs using step types Managed Instance does not support need converting, usually to T-SQL or to Azure Automation. The assessment inventories every job and flags the ones needing work; the quote covers the conversion.
That runbook is out of date. Microsoft retired Azure Data Studio and its Azure SQL migration extension on 28 February 2026. The supported paths for Managed Instance are now the Managed Instance link (our default), the Log Replay Service, the SQL migration experience in Azure Arc, and the Azure Database Migration Service through PowerShell and the CLI. We verify the currently supported path against Microsoft's documentation on the day we start, not from memory.
Yes, without exception on this service. Managed Instance's compatibility surface is the entire risk of the project, and it is not visible from a conversation. Quoting a fixed price without checking it would be guessing with your production estate.
Roughly one week for scheduling and the three-business-day assessment, then three weeks from kickoff to the end of hypercare for a single instance: provisioning, remediation the assessment sized to fit, and link seeding in weeks one and two; the dry run at the end of week two; cutover, validation, and hypercare in week three. Where the assessment finds remediation that does not fit — application code changes, an authentication-model change, FILESTREAM replacement — that phase is quoted and completed first, and the three-week window starts when it is done. Your quote states the schedule.