Skip to main content
VSI Technologies

Technology Services

The estate that is not going to the cloud, run properly.

Compute, storage and facility operations for workloads that stay put.

The problem

Why this comes up

Every cloud programme leaves a residue: the workloads that cannot move for licensing, latency, residency or simple economics. They tend to get less attention every year, which is exactly backwards, they are usually the ones that cannot fail.

The residue is not a rounding error. In most organisations that have run a cloud programme, what remains on premises is the set of systems with the least tolerance for downtime: the manufacturing line controller, the clinical system, the trading application, the thing with a licence tied to a physical socket. They stayed because moving them was hard, and hard usually means important.

What happens next is a slow withdrawal of attention. The talented people follow the interesting work, the refresh budget follows the strategy, and the estate gets one more year of support every year. Nothing fails immediately. What degrades is the margin for error: support contracts lapse to next-business-day on systems that need four hours, spare capacity gets consumed, and the person who knew the storage layout retires.

Backup is where this concentrates. Backup jobs report success, and reporting success is not the same as being able to restore. The gap between the two is only ever discovered at the worst moment, and it is usually not the backup that failed, it is that nobody had tested the restore path, the recovery documentation referenced a system that has changed, or the recovery point turned out to be twelve hours older than anyone believed.

Capacity planning stops being connected to the application roadmap. Storage gets bought when it runs out rather than when the roadmap said it would, which means it gets bought at list price under time pressure. Hardware lead times then turn a capacity problem into a project delay, and the lead time is discovered rather than planned for.

The economics deserve honesty in both directions. Some of this estate genuinely should move and has not, because nobody has done the arithmetic since the first migration. And some of it will be cheaper on premises for its entire remaining life, which is a legitimate answer that a supplier whose margin is in cloud services has no incentive to give.

Recognise any of these

What it looks like from inside

If three or more of these are true, this page is about your estate.

  • The last successful restore test is not a date anyone can name
  • Support contracts have quietly dropped to a lower tier at renewal
  • Storage gets purchased when it runs out rather than when it was forecast
  • One person understands the storage layout and they are close to retirement
  • A hardware lead time has delayed a project in the last year
  • The comparison between staying and moving has not been recalculated since the first migration

What we build

Specifically

  • Compute and storage refresh sized against actual utilisation
  • Backup and recovery tested by restoring, not by reporting a green tick
  • Capacity planning tied to the application roadmap
  • Facility, power and cooling review where the estate is owned
  • Hybrid connectivity to whatever did move

What it integrates with

Named platforms, not categories. If you run one of these, this is the conversation.

  • HPE
  • Dell Technologies
  • NetApp
  • VMware
  • Veeam
  • Pure Storage

Refresh sized from measurement

Sizing comes from measured utilisation over a representative period, not from the specification of what is being replaced. The like-for-like refresh is the most expensive habit in infrastructure: it carries forward a decision made against a workload that has since changed, usually in the direction of needing less compute and more storage throughput.

Recovery proven by recovering

The test is a restore into an isolated environment, with the recovery time and recovery point measured rather than asserted. This is the first thing the assessment does, because it is the finding most likely to change what the client wants to spend money on. A green tick in a backup console is evidence that a job ran, and nothing more.

Capacity against the roadmap

Capacity gets planned from the application roadmap for the next two years, so purchases happen on a forecast rather than at exhaustion. The saving is not just the price difference between planned and urgent procurement, it is the projects that do not slip because the capacity was already there.

Facility, where it is yours

Where the room is owned rather than leased, power, cooling and physical access get reviewed alongside the equipment. This is where the surprises live: a refresh that draws more per rack than the distribution supports, or a cooling design that was adequate at half the current density.

Connectivity to what did move

The link between what stayed and what moved gets designed rather than inherited, with the latency and bandwidth requirements of the specific integrations that cross it. Most hybrid performance complaints trace back to this boundary being an accident of migration sequencing.

How the engagement runs

The facility loop, and what runs against it

Your estate todayWhat VSI runs against it
01

Baseline

Every workload, dependency, contract and kilowatt, in one inventory.

VSI delivers

Discovery from flow data and facilities records, the inventory later savings are measured against.

02

Plan

Move groups sequenced by dependency, with rollback per group.

VSI delivers

The migration runbook, rehearsed, including the failback nobody hopes to use.

03

Move

Cutovers land in agreed windows with the business watching.

VSI delivers

Execution with per-group verification before the source is touched.

04

Decommission

Hardware retired, contracts closed, space handed back.

VSI delivers

Sanitisation documented, support contracts terminated on schedule, the stage where the saving becomes real.

Baseline, plan, move, decommission, the consolidation loop. The navy rail is what VSI runs at each stage; the return is only booked when the last stage completes, which is why it has a date and an owner.

How it deploys

The shape of the engagement

And what we need from you at each step. A timeline with no client obligations in it is a timeline that slips.

  1. 01Weeks 1-2

    Utilisation and capacity assessment against the roadmap

    Utilisation and capacity assessment against the roadmap.

  2. 02Weeks 3-4

    Refresh design, procurement and lead-time plan

    Refresh design, procurement and lead-time plan.

  3. 03On delivery

    Install, migrate, test a restore, decommission

    Install, migrate, test a restore, decommission.

What you provide

  • Current inventory, support contracts and renewal dates
  • Application roadmap for the next two years
  • Site access and change windows

How this goes wrong

The four ways it fails

Published because it is only writable by somebody who has had the failure. Each of these has happened on this kind of work, and each has a specific thing that prevents it.

The refresh arrives and the room cannot power or cool it

Why it happens
Equipment specified on compute and storage requirements without a facility review. Modern density draws more per rack than the design assumed.
What prevents it
Power and cooling reviewed as part of the design, not as an installation surprise. Where the facility is the constraint, that changes the design rather than the delivery date.

A project slips because hardware did not arrive

Why it happens
Lead times treated as a procurement detail rather than a planning input.
What prevents it
Lead times stated in the plan and in the quote. VSI supplies the hardware directly, so the lead time is a fact we own rather than one we relay from a distributor.

A restore is needed and takes far longer than anyone expected

Why it happens
Recovery time was never measured, only estimated, and the documented procedure referenced a configuration that has changed.
What prevents it
Measured restore, into an isolated environment, with the documentation corrected from what actually happened rather than from what was supposed to.

The estate is refreshed and the same neglect resumes

Why it happens
No ongoing ownership, because the engagement was a project rather than a practice.
What prevents it
Decide at the start who operates this afterwards. If the answer is a team without capacity, the refresh buys three years and then the same conversation happens again.

Return on investment

Where the return comes from

Every lever names the mechanism and how it is measured against your own baseline, captured before the work starts. That is how the return stays a number your finance team can audit rather than a promise on a slide.

  1. 01

    Consolidation footprint

    Racks, power and support contracts for equipment that virtualises onto a fraction of the hardware. The business case is written in your own colocation and maintenance invoices, and measured the same way after the consolidation wave completes.

  2. 02

    Power and cooling efficiency

    Ageing hardware burns power twice, at the plug and in the cooling. Refresh economics are modelled from your metered draw where available and manufacturer plate data where not, and the measurement is the utility bill and the PUE trend.

  3. 03

    Zero-disruption migration

    The largest cost in a data-centre move is the outage nobody planned. Dependency-mapped move groups, rollback per group and rehearsed cutovers make the measurement simple: business interruption during the programme, target zero.

  4. 04

    Maintenance-contract rationalisation

    Post-consolidation estates keep paying support on hardware that left the building. Contract cleanup is a line-item recovery, measured on the renewals themselves.

Run your own numbers in the ROI calculator

Blade servers with active status lights in a darkened data-centre rack.

Timing

Now, soon, or not yet

Most of the value in this decision is in when, not whether. Find the row that matches your situation.

When to start data center work
CriterionVerdictWhy
Support or maintenance contracts on this estate expire within two quartersNowThe decision is forced at that date. Making it with measured utilisation beats making it from a renewal quote.
Nobody can name the last tested restoreNowThis is the cheapest high-value thing on the page and the one most likely to change your spending priorities.
A capacity constraint has delayed a project in the last yearNowIt will happen again, and planned procurement is materially cheaper than urgent procurement.
A major application on this estate is being replaced within two yearsSoonDo not refresh capacity for a workload that is leaving. Assess now so the refresh is scoped around the replacement.
Recent refresh, tested recovery, capacity headroom against the roadmapIt can waitYou are in good shape. Revisit at the next renewal, and keep testing the restore.

Buying for a public-sector body

For government estates the on-premises workloads are frequently the ones with the strongest reason to stay: a defined boundary, a physical control requirement, or a system whose accreditation would have to be redone. That makes the assessment more valuable rather than less, because the question stops being whether to move and becomes how to run a boundary properly for another five years. Media sanitisation and equipment disposal need documented chain of custody, which is a deliverable rather than an assumption. Where an existing accreditation covers the current configuration, we say plainly what a refresh would require re-examining, that is often the deciding factor and it is better known at the start.

The federal profile

Objections

What you are probably thinking

Should we not just move all of this to cloud?
Some of it, probably. The assessment models both, and where cloud is cheaper we will say so, including when that means a smaller engagement for us.
Hardware lead times make planning impossible.
Lead times are why procurement sits in the plan rather than after it, and why we quote with them stated. VSI supplies the hardware directly, so the lead time is a fact we own rather than one we relay.
Our backups are fine.
Possibly. The test is a restore, not a report, and it is the first thing the assessment does.

Questions

Asked often enough to answer here

How do you decide what stays and what moves?
Four inputs, in this order: licensing economics, latency requirements, residency or accreditation constraints, and the total cost over the remaining life of the workload. Most workloads are decided by the first three before cost gets a vote. Where cost is the deciding factor we model both options with the assumptions written down, including the period where you are running and paying for both.
What does a restore test actually involve?
Recovering a representative set of systems into an isolated environment and measuring two things: how long it took, and how much data was lost between the last recovery point and the failure. Both get compared against what the business believes those numbers are, and the gap between belief and measurement is the finding. The recovery documentation then gets corrected from what actually happened.
Can you support hardware you did not supply?
Yes. Most estates are mixed and pretending otherwise would rule out most of the work. What we ask for is the current inventory and support position, because a system on a lower support tier than its role requires is a risk that should be a decision rather than an accident.
What happens to the old equipment?
Certified recycling with documented data destruction, or return to lease, or redeployment somewhere the specification still fits. Which one is a decision, not a default. Where the data was sensitive, sanitisation is documented with chain of custody rather than asserted.
Is this cheaper than cloud?
For some workloads, for a while, and the honest answer requires arithmetic rather than a position. Steady-state workloads with predictable demand and capital already sunk are frequently cheaper to keep. Bursty workloads, anything needing rapid scaling, and anything whose hardware is due for replacement usually are not. We model both and tell you which, including when the answer costs us the larger engagement.
How long do refreshes take end to end?
The assessment and design run to a few weeks. After that the schedule is set by procurement lead time far more than by installation work, which is why lead times are stated in the plan rather than discovered in it. Installation and migration then happen in change windows you set, with a restore test before the source is decommissioned.

Stay current on our services

Occasional updates across every VSI service, new capabilities, new offerings, and what changed. No sales sequence; leaving is one reply.

Used only for these updates, see the privacy statement.

What it costs

Pricing

Assessment is fixed-price. Hardware is quoted at line-item level through VSI TechSource so you can see what you are paying for.

Book a 20-minute assessment