Migration under loadSpecialty manufacturer, anonymized × red9CS-0578
A storage-latency spike and two disk emergencies contained mid-migration
The problem. A specialty manufacturer needed off SQL Server 2019, which had already passed mainstream support, and April was the wrong month for it. Transaction volume rose 6.63% to 730.6 million, storage latency spiked to roughly 500 ms against a 50 ms threshold, two P1 low-disk-space incidents hit the same drive, blocking incidents jumped from 1 in March to 48, differential and log backups failed, and SSRS jobs started falling over.
What we did. Two jobs at once. On the legacy platform we worked all 180 alerts for the month, 2 P1, 77 P2 and 99 P3, repaired the failed agent jobs and backup and integrity alerts, cleared the error-log spikes and account lockouts, and traced the IO-integrity and backup-chain problems behind the latency until it settled back under 100 ms. In parallel we built and configured new SQL Server 2022 production and QA environments on a new hypervisor platform, set up SSRS there, and advanced the migration plan off the old box.
Red9 · Managed Services and Migration
Storage latency
500 → <100 ms
Against a 50 ms threshold, after the IO work.
Alerts handled
180
2 P1, 77 P2, and 99 P3 inside a single month.
Transactions in the month
730.6M
Up 6.63%, carried while the SQL Server 2022 platform was being built.
Storage latency
~500 ms → <100 ms
recovered
P1 incidents
2 low-disk
contained
Blocking incidents
1 → 48
found, worked
Storage latency
on the affected volume
5x lower
back under 100 ms
Where the numbers come from. Latency, transaction volume, alert counts and the blocking figures all come from the client's monthly managed-services reports for March and April. The blocking rise from 1 to 48 and the two P1 disk incidents are reported as found, because this month is a containment story with a migration running underneath it.
The result. The manufacturer came out of a difficult month with latency back under 100 ms, still above the 50 ms threshold, both disk emergencies closed, backups working again, and a SQL Server 2022 production and QA pair standing ready on new hardware. The migration then had somewhere to go rather than being attempted on top of a failing platform.
The technical detail
What the month showed. Here the IO-integrity findings pointed at the storage path, and the failed differential and log backups were repaired and verified alongside it. Blocking rose from 1 to 48 through the slowdown, and the reports do not settle whether the storage path caused it.
How the month was worked (findings summarized, identifiers withheld):
-- Managed services month, legacy SQL Server 2019 instance
-- P1 x2 : low disk space on one drive -> contained, capacity addressed
-- storage : latency spike ~500ms vs 50ms threshold -> back under 100ms
-- backups : differential and log failures -> chain repaired and verified
-- jobs : SQL Agent and SSRS failures -> remediated
-- build : new SQL Server 2022 PROD + QA on new hypervisor, SSRS configured
Every item carried an owner and a next step, so the client could see which faults the migration would retire and which needed fixing regardless.