Suva's storage went through three generations. The management layer did not.

Suva runs two petabytes of mission-critical Hitachi storage with a team of seven. The hardware underneath has been replaced around them since 2015. SAM4H, the layer they run it with, has not.

Suva, the Swiss National Accident Insurance Fund, is the country's largest accident insurer. It covers around 130,000 companies and more than two million employees, and as a public-sector institution every record it holds falls into Switzerland's most strictly protected data category. None of it runs in a public cloud. The entire business-critical estate sits on-premise in two data centres near Lucerne, ten kilometres apart, replicated synchronously between them.

Seven people, two petabytes

Of Suva's 350 IT staff, around sixty work in infrastructure. Seven of them run the server and storage platform: two Hitachi VSP 5600 arrays, two petabytes of usable capacity in total, carrying a mostly VMware-based environment with Red Hat Enterprise Linux, Windows server and VDI workloads, and an OpenShift container platform. Almost everything the insurer does touches that storage.

In 2015, Suva separated two decisions

Which arrays to buy is one question. How to run them every day is another, and in 2015 the team stopped treating them as the same question. It went looking for a management layer that matched how it actually worked: high-frequency block operations daily, several people working at once, an interface a new colleague could pick up quickly, and support for GAD and ALUA without hand-building every configuration.

Suva was already a peaq customer, using IOportal for performance monitoring. Jürgen Voss of the Server & Storage Platform team, who has been at Suva for 24 years, remembers how it started: "Our contacts introduced us to SAM4H, and we became one of the first customers in Switzerland."

What changed on a normal working day

Several administrators now work at the same time without queueing behind one another. Provisioning and replication follow rules that engineering defines once, so the standards live in the platform instead of in individual heads, and the same job produces the same result whoever runs it. ALUA configuration across two sites and GAD replication pairs are built from predefined rules rather than by hand. The terminology follows the concepts the team already thinks in, which matters most when someone new joins. "Storage management that took hours is reduced to minutes," the team reports.

Getting there took an afternoon. "SAM4H installs in 20 minutes and is ready for production within a few hours," Voss says. "You don't need special training. If you understand storage concepts, you're productive fast."

The switching cost nobody had to pay

Storage hardware lasts five to seven years. Management competence ought to last longer, and usually does not get the chance: when the arrays are replaced, the tooling around them tends to be replaced too, and the team pays for the refresh a second time in retraining, rewritten procedures and weeks of reduced output. That second bill is the switching cost of a refresh, and it rarely appears in the business case.

Suva has been running SAM4H for eleven years, across three hardware generations. "We started in 2015 on older VSP systems, moved to the VSP 5600 in 2019/2020, and if the next generation arrives in 2027 or later, SAM4H stays," says Brian Mathis, who leads the server & storage team.

No retraining. No changed processes. No interruption. And expertise that accumulates instead of resetting every few years.

“We used to buy new storage every five years and often had to get used to new tools as well. With SAM4H we broke that dependency. The hardware can move on; our management workflow stays stable.”

Server & Storage team, Suva

Alongside Hitachi's tools, not instead of them

Suva has been a Hitachi customer since 2009, through a G600 and the VSP 1000 and 1500 before the current arrays, so Hitachi's own tooling has always been in the house. SAM4H does not ask to be the only way in. Configuration is written into the array itself, whichever tool made the change, and a nightly sync keeps the views consistent. Suva uses that deliberately. "If we have a special requirement SAM4H doesn't cover yet, we pragmatically use other Hitachi tools," Voss says. "The tools don't get in each other's way. SAM4H is a complementary management layer, not a proprietary lock-in."

In practice the estate is split by what each job needs. Hitachi Ops Center manages the backup systems, where a set-and-forget model is the right fit. The high-frequency block work on the VSP 5600s stays in SAM4H. The Hitachi engineers Suva works with know SAM4H well, which keeps joint work on the estate straightforward.

That closeness shows in development too. When the team recently wanted to pin OpenShift workloads to dedicated MPUs, something SAM4H could not yet do, the capability went into the plan for the next release.

What happens at the next refresh

The VSP 5600s are five years in, with maintenance cover for two more, so a refresh conversation will probably start in 2027. Suva has stopped treating that as a fixed cycle: as long as the vendor supports the product and it meets requirements, it keeps running, and enterprise arrays allow components to be replaced to stay current.

Whatever the next generation turns out to be, the team already knows how it will run it.

“One thing is settled. SAM4H has proven itself. We do not question the tool any more.”

Brian Mathis, Team Lead Server & Storage, Suva