Questions Every Transfer Server Vendor Should Answer

"Did we ask what happens when we grow?" "We asked about encryption at rest." The security questionnaire went out weeks ago, all forty pages of it, and rightly so. The security questions for vendors and the guide to reading vendor security claims cover that ground. But the questions that decide what owning a product feels like are different, and asked far less often. What exactly are we paying for? What happens when we grow? Who answers when it breaks? How do we hear about a vulnerability? What leaves our network? And how do we leave if we must?

This article is that second question set, grouped by theme, with why each question matters and what a red-flag answer sounds like. It is part of our Choosing a File Transfer Server series. Its answers feed the licensing and support rows of the criteria matrix and, later, the decision memo.

Bought Once, Lived With for Years

The disclosure this series makes in every article: Sysax sells a file transfer server. So this is a list of questions we expect to be asked, and every one applies to us. Some of our honest answers are less flattering than a brochure. A couple of our features sit in higher editions, for one. That is exactly what this list exists to surface early, from any vendor, rather than after the purchase order.

A transfer server is not bought so much as adopted. Partners pin its address, jobs assume its folder layout, auditors learn its log format, and the administrators build habits around its console. Replacing it later is a project measured in months of partner coordination. So the commercial and operational terms are not paperwork attached to a technical decision. They are the conditions under which you will live with it for years. Consider a metric that penalizes growth, a support desk in the wrong time zone, or a license key that dies with the hardware. Any of these will cost more attention over those years than most of the features you compared in the trial.

Licensing Metrics and Edition Gates

Licensing metrics

A licensing metric is the unit the vendor counts to decide what you owe. That could be a server installation, a processor core, a named user, a concurrent connection, a protocol, or some combination. The metric decides the shape of your cost over time, which is why the requirements worksheet asked about budget shape and not amounts. Questions to put in writing:

• What is the unit, precisely? If it is a user, does a partner's service account count? A directory group? A browser visitor who uploads one file a year?
• What happens at the boundary? If you exceed the count, does the server refuse connections, log a warning, or keep working while you true-up at renewal?
• Do test, standby, and disaster-recovery installations need separate licenses? A cold standby that is never active is treated very differently by different vendors.
• Is the license tied to hardware or a machine identity? What happens when the virtual machine is rebuilt, moved to another host, or restored from backup?
• Can the license be moved between servers, and how many times?

The red flags are vagueness and asymmetry. "It depends on the deployment" is not an answer; it is an invitation to a call. If a metric grows with something you do not control, it is a cost you cannot budget. Examples are the partners a business unit signs or the files a customer sends. That metric should lower the licensing score even when the current amount looks small. If the unit is a user, stale accounts cost money as well as risk. In that case, run finding stale and orphaned accounts before every renewal.

Northgate Retail bought on a concurrent-connection metric when they had forty stores. Every store's nightly job connected at ten o'clock, because the script's author liked round numbers. The count sat comfortably under the limit. At sixty stores the server began refusing the last dozen connections each night. The license check logged a warning to a console nobody watched at ten o'clock. Staggering the jobs took a week. The true-up took a quarter. "What happens at the boundary?" would have taken one line of an email.

Edition gates

An edition gate is a feature that exists in the product but only in a higher-priced tier. Edition gates are legitimate; vendors have to draw lines somewhere. But they are where trials mislead most often, because a trial often unlocks everything and the edition you can afford does not. The question is simple and must be answered feature by feature: for every row on my must list and every weighted row I care about, which edition contains it?

We are a fair example of why to ask. In Sysax Multi Server, event triggers and web-based administration are features of the higher editions. If either is on your must list, the edition you evaluate and the edition you buy have to be the same one. A trial that unlocks everything only helps if you check which edition each tested feature belongs to. Ask every vendor for the same feature-to-edition map, in writing, before the trial starts. Then the results sheet can note which edition each observation would require.

Upgrade Paths and Release Support

Every product you buy will be upgraded many times while you own it, and each upgrade is a small cutover with partner-visible risk. These questions decide whether upgrades are routine maintenance or recurring projects.

• How long is each release supported with security fixes after the next one ships, and how is that period announced?
• How are security fixes delivered: as small patches, or only inside the next full release with its feature changes?
• Does an upgrade preserve the configuration (accounts, keys, folder rules, listeners) automatically, or is there a migration step? Has a customer ever lost configuration on upgrade, and what changed as a result?
• Is there a documented rollback, and does it restore the previous release with its configuration intact?
• Are major upgrades included in maintenance, or purchased separately?
• What does an upgrade change that partners can see? A regenerated host key or a rebound certificate is a partner-facing event, not an internal one.

A reassuring answer names the support period, describes patches as separate from feature releases, and can point to release notes that list breaking changes. A red flag is a vendor who cannot say how long the current release will be supported. Another is one who describes rollback as "restore from your backup." (That is not a rollback procedure. That is a description of your evening.) Our update and patch strategy guide covers what you do with the answers once the server is in production.

Support Terms and Advisory Practice

Support terms

Support is the product's behavior at the worst moment, and the brochure describes the best one. Read the actual terms and ask:

• What are the support hours, in which time zone, and on which channels? Is there a phone number, or only a ticket form?
• Who answers first: an engineer who can reproduce the problem, or a router who collects information and schedules a callback?
• What is promised: a response time, or a resolution time? A two-hour response that leads to a two-week resolution is a two-week problem.
• What is the escalation path when the first answer does not solve it, and can the customer trigger escalation?
• What is excluded: third-party clients, operating system issues, configurations the vendor did not recommend?
• Is support tied to a maintenance contract, and what happens to a ticket if maintenance lapses mid-problem?
• How much notice is given before support for a release ends?

The trial's real support ticket is the evidence for this section. The written terms are the promise; the ticket is the practice. I have had tickets answered in nine minutes by the person who wrote the code, and in nine days by a form. Small vendors are often faster and more knowledgeable at first contact and unable to promise round-the-clock coverage. Large ones offer the coverage and route you through more layers. Neither is wrong, but your operational rows say which you need. A vendor, this one included, should say plainly which it is.

Advisory practice

Every product has vulnerabilities eventually; what distinguishes vendors is how you find out. A security advisory is the vendor's formal notice that a vulnerability exists, which releases are affected, and what to do. Ask:

• Is there a published channel for advisories (a mailing list, a page, a feed) that does not depend on you noticing a release note?
• Does an advisory name the affected releases and the fixed release, so you can tell in one minute whether you are exposed?
• How do researchers report vulnerabilities to you, and how long is the typical time from report to fix?
• Have you issued an advisory before? A vendor who has never issued one has either a perfect record or a silent policy. The second is far more common.

The ongoing vendor monitoring article explains how to subscribe to and act on these channels after purchase. The question now is whether they exist.

Data Handling

A self-hosted server sits inside your network, which tempts teams to skip the data-handling questions. Software still talks to its maker, and support engineers still see your configuration. Ask:

• What does the software send to the vendor (license checks, telemetry, crash reports, usage statistics), and can each be disabled? What exactly is in a crash report?
• Does the server need outbound internet access to keep running? What happens to a licensed server that cannot reach the vendor for a month?
• During a support case, what do you ask customers to send (logs, configuration exports, packet captures)? Where are those stored, for how long, and who can see them?
• If any component is hosted by the vendor (a portal, a management console, an update service), where does its data live? Which jurisdiction's law applies to that data?

These answers matter most when the files you move contain personal or regulated data. A log bundle sent to support can itself contain account names, addresses, and file names. The self-hosted versus hosted risk comparison shows how the answers shift when the vendor runs the service.

Exit

The exit questions are the ones nobody wants to ask on a first call and everybody wishes they had asked when the time comes. Lock-in is patient; it does nothing for three years and then answers the phone. A product you cannot leave has stopped being a purchase and become a dependency, so ask while you are still the one choosing.

• Can accounts, public keys, folder rules, and configuration be exported in a documented, readable format that another product could import? Which of those cannot be exported, and why?
• Does the software keep running when the maintenance contract lapses, or does it degrade or stop? Can it still be reinstalled on new hardware in that state?
• If the vendor is acquired or the product is discontinued, what notice is promised? In that case, is there any commitment about continued licensing of the last release?
• Does documentation remain available after the contract ends?
• What has the vendor done for customers who left? A vendor who has helped a customer migrate away and can describe it is a vendor who does not need lock-in to keep customers.

The mechanics of leaving, which layers of a server move cleanly and which never do, are covered in our platform migration mechanics series. A vendor's exit answers decide how hard that series will be to apply later. Our open source versus commercial series looks at the same question from the other side. There, exit is easy and support is the thing to ask about.

The Question Set

Here is the whole set in copyable form, ready to send to every vendor on the shortlist with a deadline. Ask for numbered answers so they can be cited in the results sheet.

COMMERCIAL AND OPERATIONAL QUESTIONS — answer in writing, by [date]

LICENSING
 L1  What is the licensing unit, precisely defined?
 L2  What happens when the count is exceeded?
 L3  Do test, standby, and DR installations need licenses?
 L4  Is the license tied to hardware or machine identity? How is it moved?
 L5  For each feature on the attached list, which edition contains it?
 L6  Which edition does the trial unlock?
UPGRADES
 U1  How long is a release supported after its successor ships?
 U2  Are security fixes delivered separately from feature releases?
 U3  Does an upgrade preserve all configuration? Documented rollback?
 U4  Are major upgrades included in maintenance?
 U5  What partner-visible changes can an upgrade cause?
SUPPORT
 S1  Hours, time zone, channels, and who answers first?
 S2  Response time or resolution time — which is promised?
 S3  Escalation path, and can the customer trigger it?
 S4  What is excluded from support?
 S5  What happens to open tickets if maintenance lapses?
 S6  Notice period before a release leaves support?
ADVISORIES
 A1  Where are security advisories published?
 A2  Do advisories name affected and fixed releases?
 A3  How do researchers report to you; typical time to fix?
 A4  Have you issued an advisory? Provide an example.
DATA HANDLING
 D1  What does the software send to you, and can each item be disabled?
 D2  Does the server keep running without internet access to you?
 D3  What do you collect during support cases, where is it stored, for how long?
 D4  For any hosted component: where does its data live, under which law?
EXIT
 X1  What can be exported, in what format, and what cannot?
 X2  Does the software run after maintenance lapses? Reinstallable?
 X3  Acquisition or discontinuation: notice and licensing commitments?
 X4  Does documentation stay available after the contract ends?
 X5  Describe a customer you helped migrate away.

Answers fall into recognizable patterns. The table shows, for each theme, the kind that should reassure you and the kind that should lower the score, however it is phrased.

How to Ask So You Get Real Answers

The questions only work if they are asked in a way that produces citable answers. Four habits:

• In writing, with a deadline. A sales call produces reassurance; an email produces a document. Send the same numbered set to every vendor and ask for answers by question number.
• Attach the answers to the contract. Written answers about licensing, support, and exit are commitments. The cleanest way to make them binding is to reference them in the purchase agreement. A vendor who resists has told you what the answers were worth.
• Treat evasion as an answer. A question answered with a call request, a brochure link, or "our customers have never asked that" is scored as unanswered. Silence on exit, in particular, is not neutral.
• Cross-check against the trial. Check the support answer against the real ticket and the edition answer against what the trial unlocked. Check the data-handling answer against what the trial server actually tried to connect to. A firewall log will show you that.

The answers become evidence in the licensing and support rows of the matrix and the "conditions" section of the decision memo. Where an answer is unacceptable but the product is otherwise strong, the memo records the condition. That might be "purchase only if exit terms X1 and X2 are contractually confirmed". The memo does not pretend the problem is small. Presenting the case and following through shows how to report back on those conditions later.

What the Answers Buy You

With the security questionnaire and this set both answered in writing, you know the shape of ownership before you own anything. You know how cost grows, which edition you need, and how upgrades and vulnerabilities reach you. You know what leaves your network and how you would leave. None of it depends on a demo. All of it can be cited by question number in the scoring and decision memo. And when somebody asks "did we ask what happens when we grow?", the answer is L2, in writing, with a date.

Two of the answers deserve a second look after the purchase. The support and advisory answers become the baseline for the ninety-day review, which checks whether practice matched promise. The exit answers go into the runbook folder, where nobody will read them until the day they matter. That is exactly when they must already be there.

Frequently Asked Questions