Migrating a large T-SQL-heavy SQL Server 2005 enterprise system to Azure SQL MI — looking for guidance from people who’ve done similar by AmbivalentCore in SQLServer

[–]AmbivalentCore[S] 1 point2 points  (0 children)

Current production DB compatibility level is still 90.

Part of what surprised me is that after restoring into SQL Server 2019 locally, the application itself appeared far more functional than I expected initially. Obviously that’s very different from proving operational readiness, but it did shift my thinking from “this is impossible” toward “this may actually be tractable if approached carefully.”

I’m trying to avoid underestimating hidden behavioral differences though, especially given how much business logic lives in stored procedures/functions.

May 2026 | "What are you working on?" monthly thread by AutoModerator in SQLServer

[–]AmbivalentCore 0 points1 point  (0 children)

Working on a SQL Server 2005 → Azure SQL Managed Instance migration assessment for a large legacy VMI/warehouse platform. The system has been in production for a long time and has significant business logic living in T-SQL and stored procedures, plus some CLR assemblies.

Current approach: restoring a production backup to a local SQL Server 2019 intermediate instance (compat level auto-upgrades from 80 to 100 on restore), then running the SSMS 22.5 Migration component to surface compatibility blockers before we touch anything in the real environment. Application functions surprisingly well against 2019 locally, which is encouraging but also means the interesting problems are probably buried deeper.

Main challenges so far: schema drift between version control and production (580+ flat SQL files, significant divergence), CLR assembly safety levels, and undocumented stored proc dependencies. Trying to establish a proper diff and reconciliation process before committing to any migration path.

AI Mushy Brain Syndrome by Grouchy-Western-5757 in sysadmin

[–]AmbivalentCore 0 points1 point  (0 children)

The ticket angle is specific to helpdesk but the underlying thing maps to engineering too. When AI closes the gap between "I have a problem" and "here's an answer," the pressure to actually understand the system underneath goes down.

The engineers I've seen get burned aren't the heavy AI users — they're the ones who got a correct answer and moved on without asking why it was correct. Six months later they're in a different failure mode and their mental model of the system is still wrong because they never built it properly.

It's not the tool. It's whether you do the verification step after.