Why Nobody Wants to Fund File Transfer (Until It Breaks)

You run a transfer estate held together by batch files, a server older than everyone on the team, and a private list of things that will eventually go wrong. You asked for money to fix it. The answer was no. Not an angry no, a polite one: "not this cycle." Meanwhile the team two doors down was funded for a dashboard nobody has opened since the demo. You are not imagining the pattern, and the people holding the budget are not foolish.

File transfer is hard to fund for three specific reasons. It is invisible when it works. It lives inside a cost center (a part of the organization measured on how little it spends). And the people who understand the problem and the people who sign for the money do not share a vocabulary. On top of that, a transfer request nearly always competes with something that has a demo. The demo wins for a reason you can learn from rather than resent.

This article explains those four forces and gives you a translation table from admin language to budget language. It ends with a one-paragraph problem statement you can fill in this afternoon. It opens our Business Case series.

File Transfer Is Invisible Until It Isn't

When a transfer works, nobody sees the transfer. They see the payroll that ran, the order that shipped, the price list that updated. Credit goes to the thing being carried, not the thing carrying it. That is as it should be, and it is also why the transfer estate never appears on anyone's list of things worth money. A courier who is never late is, from the customer's chair, indistinguishable from no courier at all.

When a transfer fails, the failure is also attributed to whatever it was carrying. Nobody says "the overnight SFTP job failed"; they say "payroll was late." So even the outage does not buy the transfer estate any lasting visibility. The system that broke gets a few days of frightened attention, and then the attention goes back to the payroll, where it lives.

The diagram below shows the attention curve every transfer administrator learns to recognize. It is a long flat line of nothing, a spike at the outage, and a slide back to nothing. Requests made on the flat part are declined. Requests made at the spike are approved in minutes. Money approved at the spike is quietly reclaimed on the slide.

I have had a request approved within forty minutes of an outage after it had been declined twice in the previous year, unchanged apart from the date. That is not a story about a bad manager. It is a story about a request that only made sense while the pain was fresh. A good business case makes sense on the flat part of the curve, which is the only part you can schedule.

Here is how the curve played out at Meridian Parts, a spare-parts distributor with forty transfer flows and two administrators. Their largest supplier's overnight price file stopped arriving. The job that fetched it had no alerting, so it failed silently for nine days. For nine days the warehouse sold at the previous month's prices, which finance discovered when the supplier's invoice did not match. The administrators had asked for a monitored, retrying scheduler in the two previous budget rounds. The third request was approved that afternoon; it was the second request with a new date.

Cost Centers, and Why Yours Is One

A cost center is any part of an organization that spends money without directly bringing any in: IT, facilities, HR, legal. (Sales is the opposite, a profit center, measured on revenue.) Almost every IT department is a cost center, and the person who manages one is measured, first and last, on keeping its spend flat or falling.

That single fact explains most budget conversations. When you ask a cost-center manager for more money, you are asking them to look worse on the only number their own manager sees. They are not being obstructive; they are doing their job with a line item that shows no return. The way through is not to argue harder. It is to show that the spend reduces or prevents a larger cost somewhere else, in terms the same number-watcher will recognize.

Three more terms will save you from a confusing meeting. Capital spend is money for a thing that lasts, such as a server or a license bought outright. It usually comes from a separate pot with its own approval path. Operating spend is the ongoing kind: subscriptions, support contracts, and, crucially, staff time. The same fix can often be shaped as either, and finance teams have preferences that change from year to year. Ask which pot is easier this cycle before you write a word; it is the cheapest question in the whole process.

A budget line is a named row in the budget. If file transfer has no line of its own, it is paid for out of "general IT". That means it has no owner, no history, and no advocate. Part of what a business case does is create the line, so that next year there is a row to point at rather than a conversation to restart.

Finally, total cost of ownership. People treat this as a formula; it is more useful as a shape. Any option has an up-front bump (buying, building, or migrating) and a flat ongoing cost (licenses, support, the hours to keep it running). It also has occasional spikes (upgrades, failures, the week somebody leaves with the passwords). Doing nothing has a shape too: no bump, a flat line that rises as the scripts rot, and spikes whose timing you do not choose. The cheapest transfer system in any organization is the one nobody has costed yet.

The Language Gap

Administrators and budget holders describe the same problem in different words, and the words that feel precise to you sound like noise to them. "The FTP server is end-of-life and we need SFTP with key-based authentication and retry logic" is a true sentence. To a finance director it contains no information at all, because none of those nouns appear in their world.

The fix is to borrow their nouns: orders, invoices, payroll, price lists, cutoffs, audits, hours, headcount. Yours are protocols, ciphers, jobs, and retries. A business case uses their nouns for the problem and the consequence, and yours only where the reader needs to know what is being bought. The table below translates the sentences I hear most often in the corridor outside the budget meeting.

Notice what the right-hand column does. Every entry names the thing being carried, gives a number the organization already owns, and points at a consequence someone outside IT will recognize. None of them mentions a protocol; protocols go in the appendix.

A business case, since we are defining terms, is a short document. It says what a problem costs, what the options are, which one you recommend, and what you are asking someone to decide. It is not a specification, a slide deck, or a plea. The best ones fit on one page; a later article gives you the one-page template filled in end to end.

Why the Demo Always Wins

Your transfer request will nearly always sit on the same agenda as something with a demo: a dashboard, a portal, a tool with a colorful screen. The demo wins, and every reason it wins is one you can copy.

The demo shows the future; your request describes the present. The demo has a picture; your request has a list. The demo asks for a decision ("shall we do this?"); your request, if you are honest, asks for sympathy ("this is bad, please help"). Decisions are easy to give and sympathy is not, because sympathy has no line in the budget. I have sat through vendor decks in which the word "seamless" appeared more often than the word "file". They were funded anyway, because the last slide said what was being asked for.

My own first pitch had eleven slides on protocols, one on cost, and none on what happened if we did nothing. The only question I was asked was "so what happens if we don't do this?" and my answer was "it gets worse." It was not funded. It should not have been.

Giving a transfer case a demo of its own does not mean building a prototype. It means three things. A scenario: one concrete story of a failure with a timeline and a consequence, the subject of translating breach risk into numbers. A total: the hours a year of small failures already costs, from your own logs, built with the worksheet in costing failed jobs and manual work. And a decision requested: one sentence stating what you want the reader to approve, so the meeting can end with a yes rather than a nod.

What a Successful Case Does Differently

The transfer requests I have seen funded on the flat part of the curve, without an outage to help them, have five things in common.

It names the thing carried, not the mechanism. "The supplier price list that sets what we charge on forty thousand parts" is a thing the finance director cares about. "Flow 17, the inbound SFTP pull" is not, even though they are the same flow. If you do not know what each flow carries, start with the transfer inventory. A case built on an unknown estate is a guess with a title page.

It uses the organization's own numbers. Your incident log, your ticket queue, the auditor's letter, the insurer's renewal questionnaire. Not a statistic from a survey the reader has never heard of. Industry surveys consistently put the average cost of a serious breach in the millions. That sentence, in that vague form, is as far as you should ever go. Quote a precise figure from a source the reader cannot check and every other number in your case inherits the doubt. Your own numbers are smaller, and they are unarguable.

It presents the options fairly, including doing nothing. We make transfer software, so read this paragraph with that in mind; the method works whatever you buy or build. A credible case has at least three columns: do nothing, fix what you have, and replace it. Here, "replace" means build it yourself, adopt a free or open-source tool, or buy a commercial one. Each is a legitimate outcome. A scheduled-transfer tool such as Sysax FTP Automation belongs in the buy column because retry and notification are exactly what remove the manual work. A well-maintained script with a proper scheduler belongs in the fix column and may win. Where that line falls is argued in build versus buy, honestly and hidden costs of homegrown. This series shows you how to present whichever answer you reach.

It gives cost as a shape, in hours. Not a spreadsheet with forty rows: the bump, the flat, and the spikes, for each option, with the ongoing part in staff hours and fractions of a person. Finance can turn hours into money faster than you can, using a number they already have called the loaded hourly rate. That is what one hour of a person costs once salary, tax, benefits, and overheads are included. Ask for it; they will be pleased you know the term.

It asks for a decision, briefly. The last line of a successful case starts "Decision requested:" and ends with something a person can say yes or no to. "Approve a three-month pilot of option two, funded from the existing support line, with a report back at the end." Not "we hope you will consider this." Consideration is what happens to requests that never come back. And the whole thing is short: one page for the decision, an appendix for the implementer. A long case signals that the author has not decided what matters.

Template: The One-Paragraph Problem Statement

Before the one-pager, before the worksheet, before any of the numbers, you need a single paragraph that states the problem in budget language. You will paste it into the top of every later document and read it aloud at the start of the meeting. You will hand it to the colleague who asks "what is this about?" Write it now, badly, and improve it as the series goes on.

PROBLEM STATEMENT

What moves:      We exchange [count] files a [day/week] with [who], carrying
                 [orders / price lists / payroll / filings].
Who depends:     [Team] cannot [do their job] without it arriving by [cutoff].
What fails:      In the last [period], [count] transfers failed or arrived late,
                 [count] of them silently. There is no [retry / alerting / log].
What it costs:   Recovery took about [hours] of administrator time and [hours] of
                 [business team] time. One failure caused [concrete consequence].
Outsider's view: The [auditor / insurer / partner] has noted "[quoted sentence]"
                 and expects [a control] by [their deadline].
The ask:         A decision between [options]; we recommend [option], costing
                 [bump + flat, in hours or as a fraction of an existing line].

Filled in for Meridian Parts, it reads like this: no protocol names, one quoted sentence from an outsider, and numbers the organization can check against its own records.

PROBLEM STATEMENT: MERIDIAN PARTS

We exchange about sixty files a day with twelve suppliers and four dealer groups,
carrying supplier price lists, purchase orders, stock feeds, and dealer invoices.
Purchasing cannot price the catalog without the price files, and the warehouse
cannot ship without order confirmations; both are due before 06:00.

Last quarter, twenty-two transfers failed or arrived late; nine failed silently.
The scheduler has no retry, no alerting, and no central log. Recovery took roughly
ninety hours of administrator time and forty hours of purchasing-team time. One
silent failure left the catalog priced from the previous month for nine days.

The external auditor has written that "supplier files are exchanged over an
unencrypted service using a credential shared by multiple parties" and expects a
remediation plan before the next review.

We ask for a decision between three options: continue as we are, rebuild the
current scripts with retry and alerting, or replace the scheduler with a tool that
provides them. We recommend the third: about two weeks of administrator time to
migrate, and an ongoing cost small enough to sit inside the existing support line.

That paragraph is the whole case in miniature; everything else in this series exists to make one of its sentences stronger. Writing it depends on records you keep on the flat part of the curve. Those include an incident log for transfers, even a plain text file, with what failed, when it was noticed, and how long it took to fix. They also include every sentence an outsider has written about your transfers and an inventory of what each flow carries. If your jobs fail without telling anyone, start with why jobs fail silently, because you cannot count what you cannot see.

Where This Series Goes Next

The invisibility, the cost-center logic, and the language gap are the diagnosis. The rest of the series is the treatment, in the order you would use it. First come translating breach risk into numbers without inventing a statistic and costing failed jobs and manual work from your own logs. Then come mapping audit findings to spend and the one-page business case filled in for Meridian Parts. If the estate you are funding still includes plain FTP, the costs of FTP persistence describes what keeping the old protocol alive quietly costs. That cost is often the first line of the "do nothing" column.

Frequently Asked Questions