What a Storage Migration Really Costs: Money, Time and the ROI Case
The array price is the easy number. The one that decides whether a migration is worth doing is the fully loaded cost of moving, against the honest cost of staying, over the same period. Here is how to build both, what the hidden line items really are, how long it takes, and how to make the ROI case stand up in front of a board or an investor.
Most storage migration business cases are wrong in the same direction. They compare the new array price against the incumbent renewal, show a saving, and stop there. The trouble is that the array price is the smallest part of the real cost of moving, and the incumbent renewal is rarely the real cost of staying either. Once you load in professional services, dual running, the internal effort and the risk, and once you model staying properly rather than accepting the first renewal quote, a lot of migrations that looked obvious get closer, and a few that looked marginal turn out to be clearly worth it. The point of this guide is to help you build the number that actually decides it.
C4C is an independent, vendor neutral technology consultancy that helps enterprises plan and cost storage migrations. We model the fully loaded cost, the realistic timeline and the genuine ROI before you commit, drawing on years spent on the vendor side building exactly these business cases, so we know which numbers are real and which are optimistic. We have delivered around a 45 percent saving on a UK enterprise storage estate by doing this properly. No array of our own to sell.
The cost of a migration is five numbers, not one
When someone asks what a storage migration costs, they usually mean the price of the new platform. That is one line of five, and often not the biggest. A fully loaded migration cost is the sum of these:
1. The target platform
Hardware or subscription, over its full term
The array, controllers and media, or the equivalent subscription, priced over the same number of years you are comparing against. Always model the whole term, not year one, because subscription pricing and maintenance escalators change the picture over three to five years.
2. Professional services and data movement
The single most underestimated line
The actual work of moving the data: planning, the migration tooling, host and application remediation, cutover windows and the specialist time to run them. On a large estate this can rival or exceed the platform cost, and it is the line that quotes tend to quietly leave thin.
3. Dual running
You pay for both platforms at once
For the length of the migration you are running the old and the new array in parallel, which means power, space, cooling, support and often a bridging extension on the incumbent. The longer the migration, the larger this becomes, which is why timeline and cost are the same conversation.
4. Internal effort
Real money, even when it is not invoiced
The months of your own storage, infrastructure and application teams' time. It rarely appears on a business case because no invoice arrives, but it is capacity taken away from other work, and a board that has been burned before will ask for it.
5. Risk and contingency
The cost of it going wrong
A sensible contingency for the things that slow a migration down: an application that turns out to be more coupled to the storage than anyone documented, a DR dependency, a performance surprise. Pricing this honestly is what separates a plan from a hope.
We deliberately give ranges and drivers here rather than a single formula, because the honest answer depends on your estate. But the shape holds on almost every migration we see: the platform is a minority of the total, and professional services plus dual running are where the real spend and the real risk live.
What actually drives the timeline
Timeline drives cost through dual running, so the question of how long it takes is not separate from how much it costs. And the thing that sets the timeline is almost never the raw capacity. Moving the bytes is the easy part. What stretches a migration is everything the data is entangled with.
- Data gravity. The larger and more active the dataset, the more careful the cutover, and the more it has to be moved in stages around live workloads rather than in one window.
- Disaster recovery coupling. Replication, snapshots and DR runbooks are usually built tightly around the incumbent. Rebuilding that on the new platform, and proving it, is often the longest single strand of work.
- Application dependencies. Databases, virtualisation, backup interlock and anything with hard coded paths or specific performance assumptions. Each one is a small project, and you rarely have a complete list at the start.
- Change control and windows. In regulated or always on environments, the constraint is not the technology, it is how many approved change windows you can get and how much you can safely move in each.
As a rough shape, a contained single application estate can move in weeks. A large, mixed, business critical estate with tight DR and hundreds of workloads is a programme measured in months, planned backwards from the incumbent support cliff. If a plan assumes the capacity dictates the timeline, it is optimistic. For the method behind doing this safely, see our companion guide on how to migrate enterprise storage without breaking production. This guide is about the money and the case; that one is about the how.
Costing a specific move, for example 500TB from one platform to another
A common question is what it costs to migrate a specific volume, say 500TB, from one enterprise platform to another including professional services. The honest answer is that the capacity figure alone does not set the price. Two 500TB estates can differ by a large multiple in cost and timeline depending on how many applications sit on that data, how tightly DR is coupled, how much can be moved per window, and how much of the incumbent you keep running in parallel while you move. A 500TB archive with few dependencies is a modest, quick job. 500TB under a busy transactional estate with strict change control is a different order of effort. The right way to price it is to work through the five cost lines above against your specific dependencies, not to multiply a per terabyte rate. Anyone quoting a firm figure from the capacity alone is guessing.
How to build the ROI case so it stands up
A storage migration ROI case has to survive a finance director who has seen optimistic IT business cases before, and sometimes an investor deck where the numbers get real scrutiny. The ones that stand up share a few habits.
Compare like for like, over the same term. Put the fully loaded cost of moving, all five lines, against the genuine cost of staying, over the same three to five years. Not the array price against the renewal.
Model staying properly. The cost of staying is not the first renewal quote. It is the number after the renewal has been negotiated down to what the estate actually consumes. If you skip that step, you overstate the saving and someone will find it. Our guide on storage refresh and end of life covers assessing the incumbent honestly.
Separate the hard saving from the soft benefit. Put the defensible, cash saving in the headline: lower total cost over the term, reclaimed power and rack space, reduced maintenance. Keep the softer benefits, performance, agility, sustainability, as supporting narrative, not as the number the case rests on. Boards trust a modest, hard number over a large, soft one.
Show the payback period. Because a migration front loads cost through professional services and dual running, and delivers the saving over the term, the case is really about payback. Show when the cumulative cost of moving crosses below the cost of staying. That single line is what makes an investor or a board comfortable.
Done this way, a genuine consolidation case can be striking. On one UK enterprise storage estate we took this approach and delivered around a 45 percent saving, with the business case built on the hard numbers rather than the hopeful ones. You can read how that engagement played out.
When the honest answer is to stay
Sometimes the fully loaded cost of moving, set against a properly negotiated cost of staying, does not clear. That is a real and valid outcome, not a failure of the analysis. A refresh in place, or a renegotiated renewal on the incumbent, can be the rational call when the estate is stable, the dependencies are deep, and the saving does not justify the disruption and risk. The value of building the numbers honestly is that you find this out before you spend a year of engineering effort discovering it. The goal is the right decision, not the migration.
How C4C helps
We build the fully loaded number for you, both sides of it. We model the true cost of moving across all five lines, size the realistic timeline against your actual dependencies rather than your capacity, and set that against the genuine cost of staying once the incumbent has been negotiated to what you really consume. Then we build the ROI case in the form a board or an investor will accept: like for like, over the same term, with a clear payback line and the hard savings separated from the soft. We spent years on the vendor side building exactly these business cases from the other direction, so we know which assumptions get challenged and which numbers hold. Independent, with no array of our own to sell, so the recommendation is the one your numbers support, including staying.
Costing a storage migration?
Tell us about your estate, the incumbent, the platform you are weighing, the rough scale and what is prompting the move. We will help you build the fully loaded cost of moving, a realistic timeline, and an ROI case that stands up, set honestly against the cost of staying. We delivered around a 45 percent saving on a UK enterprise estate by doing exactly this.
Prefer email? Reach us directly at hello@c4cgroup.co.uk.
Frequently asked questions
How much does a storage migration cost?
Far more than the price of the new array, which is usually the smallest of five cost lines. A fully loaded migration cost is the target platform over its full term, professional services and data movement, dual running while both platforms are live, your internal team effort, and a sensible risk contingency. On a large estate the professional services and dual running can rival or exceed the platform price. Because the total depends on your dependencies rather than your capacity, the right way to cost it is to work through those five lines against your specific estate, not to apply a per terabyte rate.
How long does a storage migration take?
The raw capacity is rarely what sets the timeline. What stretches a migration is data gravity, disaster recovery coupling, application dependencies and how many approved change windows you can get. A contained single application estate can move in weeks. A large, mixed, business critical estate with tight DR and hundreds of workloads is a programme measured in months, and should be planned backwards from the incumbent support cliff. Timeline matters to the budget because you pay for dual running throughout, so a longer migration is a more expensive one.
What are the hidden costs of a storage migration?
The ones that rarely make the first business case are dual running, where you pay for both the old and new platforms in parallel for the length of the migration, and internal effort, the months of your own teams' time that never arrives as an invoice but is real capacity taken from other work. Professional services are often underestimated too, and a proper risk contingency for the application or DR surprise that slows things down. These are the lines that turn an optimistic case into a realistic one.
How do I build the ROI case for a storage migration?
Compare the fully loaded cost of moving, all five lines, against the genuine cost of staying, over the same three to five year term, not the array price against the renewal. Model staying properly by negotiating the renewal down to what the estate actually consumes first, or you will overstate the saving. Put the hard, defensible cash savings in the headline and keep softer benefits like performance and agility as supporting narrative. Above all show the payback period, the point where the cumulative cost of moving drops below the cost of staying, because that is the line a board or an investor trusts.
Is it cheaper to stay than to migrate?
Sometimes, and finding out honestly is the whole point of the exercise. When the estate is stable, the dependencies are deep and the properly negotiated cost of staying is close to the fully loaded cost of moving, a refresh in place or a renegotiated renewal can be the rational call. The mistake is comparing the new array against the first renewal quote, which flatters the migration. Model both sides fairly and the answer is sometimes to stay, which is a valid outcome rather than a failure.
How do I estimate the cost of migrating 500TB?
Not from the capacity figure, because it does not set the price on its own. Two 500TB estates can differ by a large multiple depending on how many applications sit on the data, how tightly disaster recovery is coupled, how much can be moved per change window, and how long you run the incumbent in parallel. A 500TB archive with few dependencies is a modest, quick job, while 500TB under a busy transactional estate with strict change control is a far larger effort. Price it by working through the five cost lines against your specific dependencies, not by multiplying a per terabyte rate.