The storage controller is the most underestimated bottleneck in a server. Moving from an eight-year-old MegaRAID with 512 MB of cache to a PERC H755 or Smart Array P816i-a with 4 GB of write-back cache can double sequential throughput and quadruple random IOPS. On virtualised workloads the difference is almost always tangible.
SQL Server, PostgreSQL, MySQL on a PERC H730 with 1 GB of cache and every mid-day workload queueing up: moving to an H755 with 4 GB of cache and write-back backed by a BBU often takes latency from tens of milliseconds down to single digits.
You need to keep hardware RAID but want NVMe performance for databases and logs. The answer: a tri-mode controller (PERC H755N, Smart Array MR416i-p) with a compatible backplane.
Migrating to software-defined storage requires HBA passthrough. The existing RAID controller has to be swapped for a pure HBA (PERC HBA350, Smart Array E208i-a) so the drives are exposed individually.
Integrated enterprise controllers (PERC on Dell, integrated Smart Array on HPE, RAID 940 on Lenovo) are often "vendor-locked": a PERC H755 physically fits many servers but is officially supported only on specific models. Supermicro allows more freedom (standard Broadcom MegaRAID). We check the HCL first.
A new controller may need different SAS cabling (SAS3 vs SAS4, mini-SAS HD vs SlimSAS) and a backplane with tri-mode capability (for NVMe). When upgrading across families you often have to change the cables too, and sometimes the backplane.
Write-back controllers rely on a BBU (rechargeable battery) or a supercap (capacitor). A BBU lasts 3-5 years on average, a supercap far longer. On the existing controller we check the age of the BBU: if it is close to end of life, we include the replacement in the job.
Controller, server BIOS, operating system and drivers all have to line up. On Dell the matrix is handled by the Lifecycle Controller; on HPE by the SPP (Service Pack for ProLiant). Updating before the physical swap is mandatory.
Swapping a controller within the same family (e.g. LSI to LSI): import the foreign config on the new controller and the array is recognised and brought online. Across different families (LSI to HPE Smart Array) the on-disk metadata differs, so the array has to be recreated — a backup is mandatory beforehand.
On PERC, some advanced features (RAID 6, write-back cache, FastPath) require a license unlock. Same story on HPE Smart Array (SPP license). We verify that the target controller has, or supports, the unlock for the features you need.
Snapshot of the controller state (RAID level, drive order, strip size, cache policy, write policy, any active licenses). Full data backup or consistent snapshot. No work starts without a verified backup.
Server BIOS update, firmware prep on the target controller, license unlock pre-configured where needed. We check which SAS cabling is required (sometimes it has to be replaced) and whether the backplane needs upgrading for tri-mode.
Server powered down, existing controller removed, new one installed, re-cabling where needed, BBU/supercap positioned, everything reconnected.
Boot into the controller setup, verify the drives are detected, import the foreign config (where the family is compatible). Cache settings restored to match the original configuration. Operating system boot, array verified online.
Pre/post I/O benchmark (fio or iometer), check for SMART errors on the drives, written performance baseline. Application-level validation with the customer before handover.
A mid-market SME customer in the province of Monza, PowerEdge R740 server running SQL Server Standard, a 1.2 TB production ERP database, steady transactional traffic. PERC H730 controller with 1 GB of write-back cache, eight 1.8 TB SAS 10K drives in RAID 10. Write latency spiked during batch windows (daily closes, month-end invoicing): from 5 ms at idle to 60-90 ms during batches.
Diagnosis: controller cache saturated on writes. The physical storage (SAS 10K) can do better if the controller stops choking it. The fix: upgrade to a PERC H755 with 8 GB of cache, keeping the same drives and the same RAID 10. Identical LSI-based family compatibility: direct foreign config import.
Execution: full SQL database backup (full + log) before the job. Three-hour overnight window. Server shutdown, controller replacement, PERC firmware update, boot, foreign config import (5 minutes), system startup, SQL integrity check (DBCC CHECKDB), synthetic batch test, back into production.
Result: batch latency under 15 ms, sequential write throughput +120%. No data loss. The customer carries on running the same drives.
Three scenarios: 1) A heavy virtualised random-I/O workload on an old controller with a small cache — the benefit of moving to 2-4 GB of write-back cache is tangible. 2) You need NVMe as a protected target (RAID): the old controller has no NVMe support via tri-mode, the new one does. 3) Migrating from HBA passthrough to a controller with a BBU for database workloads that need guaranteed write durability even on power loss.
Yes, in many cases. The standard procedure is: snapshot the current configuration (drive order, RAID level, strip size, write policy), physically replace the controller with a compatible model, then import the foreign config from the new controller. If the models are in a similar family (e.g. PERC H730 → H755) the procedure is close to seamless. Across different families (LSI MegaRAID to HPE Smart Array) the on-disk metadata is not compatible: it takes a backup plus recreating the array.
An HBA (Host Bus Adapter) exposes the drives individually to the operating system: ideal for software-defined solutions (Storage Spaces Direct, vSAN, Ceph, ZFS) that handle protection and caching on the OS side. A RAID controller handles protection and caching in hardware and presents virtual volumes to the OS: ideal for traditional servers whose OS should not have to manage that complexity. The choice depends on the customer's storage stack.
It lets the controller acknowledge a write as 'complete' as soon as it lands in cache, even if the drive is still slow — which gives write performance a huge boost. If power is lost, the BBU (battery) or supercap (capacitor) keeps the cache alive until it can be flushed to the drives once power returns. Without a BBU/supercap the controller falls back to write-through and loses a great deal. Replacing a dead BBU/supercap is recurring maintenance that we handle.
A high queue depth (256+ per port) lets the controller hold many I/O commands in the queue without saturating. On a modern virtualisation workload with dozens of VMs generating thousands of aggregate IOPS, a controller with a low queue depth (32-64) creates queues, latency and a throughput ceiling. Modern enterprise controllers (PERC H755, Smart Array P816i-a, Broadcom 9560) are designed for those densities.
Yes, on latest-generation tri-mode controllers (PERC H755N/H965i, Smart Array MR416i-p, Broadcom 9560). Tri-mode lets you mix SAS, SATA and NVMe on the same controller. NVMe performance via tri-mode does not match NVMe direct on PCIe, but it gives you RAID/cache protection while keeping IOPS very high — the sweet spot for many mid-market workloads.
Send me the brand, the model (Service Tag / Serial / motherboard part number) and the target workload. Within one business day I'll come back with the technical feasibility, the constraints I can see and an honest estimate.