Tutorial: Migrating From Scripts to Xferity

This tutorial is for teams with existing shell scripts, WinSCP automation, or cron-based SFTP jobs who want to replace them with Xferity flows without disrupting ongoing operations.

Before you start: inventory your scripts

Before migrating, document each existing script:

Script	Protocol	Direction	Schedule	Partner	Notes
`payroll_upload.sh`	SFTP	upload	daily 06:00	payroll-processor	PGP encrypt
`bank_pickup.sh`	SFTP	download	every 15min	bank	No PGP
`insurance_claims.bat`	FTPS	upload	weekdays 08:00	insurer	Passive mode

Identify which scripts are doing transfer logic versus packaging, preprocessing, or other business logic. Xferity replaces the transfer logic, not the surrounding business logic.

Migration approach: one flow at a time

Never migrate all scripts simultaneously. Migrate one flow at a time and run both the script and the Xferity flow in parallel until you confirm the Xferity flow is correct.

Step 1: Pick the simplest flow first

Start with the least critical, most straightforward script — usually a simple SFTP download without PGP.

Step 2: Create the Xferity equivalent

For a script that does:

sftp username@sftp.partner.example << EOF
  cd /outgoing
  get *.csv /opt/data/incoming/
  bye
EOF

Create a partner definition and flow:

id: partner
protocol: sftp
sftp:
  host: sftp.partner.example
  user: username
  remote_dir: /outgoing
  key_path: file:/etc/xferity/keys/partner_id_rsa
  known_hosts: file:/etc/xferity/known_hosts

flows:
  partner-inbound:
    direction: download
    enabled: true
    source:
      partner: partner
      path: /outgoing
    local:
      path: /opt/data/incoming
    files:
      - pattern: "*.csv"
    idempotency_mode: hash

Step 3: Run Xferity alongside the script

Don’t disable the script yet. Run the Xferity flow manually in parallel:

xferity run partner-inbound --dry-run

Dry-run shows what would happen without actually downloading files.

Then run it for real:

xferity run partner-inbound

Compare results: same files, same count?

Step 4: Run both for a few cycles

Enable the schedule on the Xferity flow but keep the script running. Verify both produce the same results. Use xferity trace <file> to confirm which files Xferity processed.

Step 5: Disable the script

Once you’re confident Xferity is working correctly, disable the script (don’t delete it yet). Monitor for a few more cycles.

Step 6: Handle the harder cases

PGP encryption in scripts

If your script calls gpg before upload:

gpg --recipient partner-key --encrypt --output file.csv.pgp file.csv
sftp username@sftp.partner.example <<< "put file.csv.pgp /incoming/"

Replace with PGP-enabled flow:

pgp:
  provider: gopenpgp
  encrypt: true
  public_key_path: file:/etc/xferity/keys/partner-public.asc
delete_encrypted_after_upload: true

WinSCP scripts

WinSCP scripts often have implicit trust workarounds (-hostkey=*). When migrating:

obtain the actual host key fingerprint and configure it in sftp.host_key_fingerprint
do not use allow_insecure_host_key=true as a direct replacement

Cron timing

Replace your cron expression timing with schedule_cron — but remember Xferity uses six-field cron with seconds first:

Old cron: */15 8-18 * * 1-5
Xferity: 0 */15 8-18 * * 1-5

Common migration mistakes

migrating all scripts at once without parallel validation
forgetting to set host key verification (scripts often bypass it)
not testing idempotency behavior on rerun
keeping delete-after logic in both the script and the Xferity flow (double-delete)

Tutorial: Migrating From Scripts to Xferity

Tutorial: Migrating From Scripts to Xferity

Before you start: inventory your scripts

Migration approach: one flow at a time

Step 1: Pick the simplest flow first

Step 2: Create the Xferity equivalent

Step 3: Run Xferity alongside the script

Step 4: Run both for a few cycles

Step 5: Disable the script

Step 6: Handle the harder cases

PGP encryption in scripts

WinSCP scripts

Cron timing

Common migration mistakes

Related pages