Replace SFTP Scripts with Xferity — Structured MFT Instead of Bash and Cron

Replace SFTP Scripts with Xferity

This use case describes how Xferity replaces fragile SFTP scripts, cron-driven jobs, and WinSCP-style automation with a structured, auditable managed file transfer model.

What you are replacing

Teams that migrate to Xferity are usually running one of these patterns:

Shell scripts with sftp or scp scheduled via cron on a Linux server
WinSCP scripting running on a Windows task scheduler
PowerShell scripts using WinSCP COM objects or SSH libraries
Python scripts wrapping paramiko or fabric
Perl or Ruby scripts from legacy integration projects

These scripts can move files, but they typically leave key operational problems unsolved.

What breaks in scripts over time

Problem	In scripts	With Xferity
SSH host key verification	`StrictHostKeyChecking=no` or trusted manually	SHA-256 fingerprint required; hardened mode rejects insecure settings
Duplicate transfers after crash	No protection	SHA-256 content-hash idempotency
Retry on transient failure	Manual or fragile loops	Exponential backoff with jitter; permanent vs. transient distinction
Concurrent execution	Race conditions, no locking	Distributed flow locking with stale-lock takeover
Transfer evidence	Text log files or nothing	Structured JSONL audit log with SHA-256 hash chain
Dead files after failure	Lost or silently dropped	Dead-letter directory with inventory
Recovery after crash	Re-run from scratch, risk duplicates	`xferity resume` from last committed state
Secret management	Hardcoded in script or env file	7 secret providers; hardened mode rejects plaintext
Monitoring	Cron output to email or no alerting	Prometheus metrics, Slack/Email notifications
Config review	Read the script	Reviewable YAML flows under version control

What a Xferity flow replaces

A typical SFTP upload script does:

connect to remote host
upload matching files
maybe delete local files after upload
write something to a log

A Xferity flow does the same — and adds:

SSH host key verification (required)
Remote file stability check (wait for files still being written)
SHA-256 content-hash idempotency check (skip already-processed files)
Exponential backoff retry on transient failures
Distributed flow lock (prevents concurrent runs)
Structured JSONL audit event per file (with hash-chain tamper evidence)
Dead-letter directory for files that exhaust retries
xferity resume for safe rerun after crash
Prometheus counter increments per run outcome
Slack/Email notification on failure

All of this is defined in a YAML flow — not embedded in a script.

Migration path

Step 1: model your current scripts as flows

For each existing SFTP script, create:

a partner file capturing the endpoint, hostname, auth, and trust material
a flow file defining direction, file matching, schedule, cleanup

Step 2: validate before going live

xferity validate
xferity diag my-sftp-flow

Step 3: run once manually

xferity run my-sftp-flow --dry-run
xferity run my-sftp-flow

Step 4: review audit and history

xferity flow history my-sftp-flow
xferity trace <filename>

Step 5: replace the cron job

Replace the cron entry with:

xferity run-service my-sftp-flow --interval-seconds 300

Or use schedule_cron in the flow file for cron-style scheduling.

What migration does not require

No new infrastructure for basic SFTP flows (file-backed mode works)
No database for simple deployments
No container runtime — single binary
No vendor lock-in — YAML flows under version control

For production multi-flow deployments, SFTP + PGP workflows, or AS2 exchange, use Postgres-backed mode for the full feature set.

Xferity supports

SFTP / FTPS
AS2 (with MDN)
OpenPGP + CMS
Durable job execution
Retry and resume
Air-gapped deployment