SQL Server Migration to Azure SQL Managed Instance
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.
What this engagement is
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.
Success criteria
Sign-off requires all eight, each with evidence attached to the closeout report.
What you receive
How the work unfolds
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.
Prerequisites
Who does what
IT Partner
- Select and implement the migration method against the assessment findings.
- Provision the Managed Instance and configure the subnet, or validate them against specification where you built them.
- Perform the compatibility remediation the assessment quoted and sized to fit the window.
- Migrate and convert instance-scoped objects — Agent jobs, logins, Database Mail, linked servers.
- Establish and monitor the link, Log Replay Service chain, or restore sequence.
- Write and execute the dry run, including the rollback rehearsal.
- Run the cutover, hold the go/no-go gates, and call rollback if abort criteria are met.
- Capture and assemble all eight 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.
- Establish network connectivity, or engage us separately to do so.
- Sign off collation, time zone, update policy, and service tier before provisioning.
- Make application code changes where remediation requires them, or engage us separately.
- Execute the DNS or connection-string change at cutover.
- Make application owners available for both smoke tests.
- Approve the cutover 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 actually have?
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.
How do you prove there was no data loss?
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.
What does it cost?
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.
Should we choose Managed Instance or an Azure VM?
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.
What are the most common blockers you find?
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.
We have FILESTREAM. Is Managed Instance ruled out?
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.
What happens if we pick the wrong collation?
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.
Which source SQL Server versions can use the link?
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.
Can we roll back if it goes wrong?
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.
Will performance be the same?
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.
Do our SQL Agent jobs come across?
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.
Which tools do you use? Our vendor's runbook says Azure Data Studio.
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.
Do you need to do the assessment first?
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.
How long from first call to being live in Azure?
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.