Case study

Moving 25 TB off mechanical drives, in out-of-hours windows

Twenty-five terabytes of production data sat on mechanical drives, on a Hyper-V estate that had outgrown the hardware beneath it, with no copy of any of it outside the building. Fire-IT stood up a temporary host, moved the data across weekends and evenings, rebuilt their own hardware on flash, and gave them backups that leave the site.

All case studies

Client

Industrial services company

Industrial Services

Data migrated: 25 TB
Largest single server: 18 TB
SSDs, RAID 10: 7.68 TB
Backups added: Offsite

What we found

25 TB of production data on mechanical drives, with no headroom left to grow into.
A Hyper-V estate that had outlasted the hardware underneath it.
Nowhere to put any of it while that hardware was rebuilt, which is usually the point where a client is told to buy a second set of servers they will only need once.
No offsite copy of any of it, so a bad day at one address was a bad day for everything.

What we did

Stood up a temporary host out of our own spare capacity and moved their data onto it, so their hardware could be rebuilt underneath them rather than replaced around them. Holding 25 TB of somewhere-to-put-it is the part that makes this approach possible at all.
Scheduled every cutover for a weekend or an evening. Moving this much data means downtime, and the only real question is whose hours it lands in.
Rebuilt their host on 7.68 TB SSDs in RAID 10, with a memory upgrade done in the same window rather than as a second outage.
Rebalanced the mechanical pool across servers so capacity and load sat where they should.
Moved them off Hyper-V onto a new hypervisor.
Set up backups, then remote offsite backups, so there is a copy that is not in the same building as the original.

What changed

25 TB migrated across out-of-hours windows, the largest single server being 18 TB and taking an evening on its own.
Production storage on SSD in RAID 10 instead of mechanical drives.
Backups running locally and offsite, which is the part that only matters on the worst day.
No interim hardware bought to get through the move, because the temporary home for the data was ours.
Now colocated with Fire-IT, on infrastructure we run.

Services delivered

Next case study

75 TB in a month, on a gigabit they could finally use

Read it

Engage

Let's scope your environment.

Tell us what you're running today. We'll map the gaps and quote a path forward, no obligation.

Build a solution Talk to us or call 012 004 0615

Moving 25 TB off mechanical drives, in out-of-hours windows

What we found

25 TB of production data on mechanical drives, with no headroom left to grow into.

A Hyper-V estate that had outlasted the hardware underneath it.

Nowhere to put any of it while that hardware was rebuilt, which is usually the point where a client is told to buy a second set of servers they will only need once.

No offsite copy of any of it, so a bad day at one address was a bad day for everything.

What we did

Stood up a temporary host out of our own spare capacity and moved their data onto it, so their hardware could be rebuilt underneath them rather than replaced around them. Holding 25 TB of somewhere-to-put-it is the part that makes this approach possible at all.

Scheduled every cutover for a weekend or an evening. Moving this much data means downtime, and the only real question is whose hours it lands in.

Rebuilt their host on 7.68 TB SSDs in RAID 10, with a memory upgrade done in the same window rather than as a second outage.

Rebalanced the mechanical pool across servers so capacity and load sat where they should.

Moved them off Hyper-V onto a new hypervisor.

Set up backups, then remote offsite backups, so there is a copy that is not in the same building as the original.

What changed

25 TB migrated across out-of-hours windows, the largest single server being 18 TB and taking an evening on its own.

Production storage on SSD in RAID 10 instead of mechanical drives.

Backups running locally and offsite, which is the part that only matters on the worst day.

No interim hardware bought to get through the move, because the temporary home for the data was ours.

Now colocated with Fire-IT, on infrastructure we run.