Availability & DRMedical group, anonymized × red9CS-0597
A medical group's servers went quiet after a rough SQL Server 2022 cutover, with SQL errors down about 95%
The problem. A physician-led medical group on a newly migrated SQL Server 2022 estate had gone live in December, and nothing would settle. Alerts fired around the clock, the SQL error log filled faster than anyone could read it, and nobody could say for certain the failover path would hold if the primary dropped.
What we did. We brought the estate onto managed services and drove it back to a quiet baseline. We reconciled the configuration the migration had left inconsistent across the instances, chased down the recurring errors feeding the alert storm, and confirmed the availability group was synchronizing and could fail over cleanly. Counts were logged month over month on both sides.
Red9 · Availability Impact
SQL errors
~95% fewer
Across the estate, month over month.
Environment-wide alerts
~92% fewer
Same window, once the estate settled.
Primary throughput
+26.8%
More work carried on the same failover design.
SQL errors
down ~95%
stable
Throughput
up 26.8%
primary
SQL errors
month over month
How to read these. There is no single before-and-after query time here. The work was about steadying a shaky estate, so the proof sits in the error, alert, and throughput counts. The ~95% and ~92% are the month-over-month drops in SQL errors and environment-wide alerts once the estate settled, and the 26.8% is how much more the primary moved against its post-migration baseline. Every figure traces to the group's own monitoring, and the failover path was tested end to end.
The result. The alert storm cleared, the error log dropped to a trickle, and the failover path was verified end to end. The primary now carries about 27% more work on the same HA design, so the on-call team gets a clean signal and the platform keeps pace with patient-facing load.
The technical detail
What the review found. The December cutover left configuration drift across the migrated instances and a cluster of recurring errors that tripped environment-wide alerts, which buried any genuine failover warning and left the primary running below the headroom it had.
What we changed (identifiers generalized for privacy):
-- Post-migration estate: config drift + recurring errors buried real failover health.
-- Checked AG replica sync + failover readiness, then re-baselined the alert rules.
SELECT ar.replica_server_name, ars.role_desc,
ars.synchronization_health_desc, ars.operational_state_desc
FROM sys.dm_hadr_availability_replica_states AS ars
JOIN sys.availability_replicas AS ar ON ars.replica_id = ar.replica_id;
-- alert thresholds reset to real conditions; prior config captured for rollback
With the replicas confirmed healthy and the alert rules reset to fire on real conditions, SQL errors fell about 95% and environment-wide alerts about 92% month over month, while the primary took on 26.8% more work.