MOVEit Migration Guide — Replace MOVEit with Xferity

MOVEit Migration Guide

This guide explains how to migrate from Progress MOVEit to Xferity.

Architecture comparison

Dimension	MOVEit	Xferity
Deployment model	Windows Server required (DMZ + Transfer + Automation tiers)	Single Go binary; runs on Linux, Docker, or Windows
Database	SQL Server required	PostgreSQL optional (required for full UI); file-backed mode needs no DB
Configuration	GUI-driven, stored in DB	YAML files under version control
Protocol support	SFTP, FTPS, AS2, SCP, HTTP(S)	SFTP, FTPS, AS2, S3-compatible
Crypto	Certificates + PGP via UI	Certificate inventory + PGP key inventory with CLI and Web UI
Secrets management	Stored in DB or Windows credential store	7 providers: env, file, local vault, HashiCorp Vault, AWS SM, Azure KV
Audit	SQL-backed transfer log	JSONL audit log with SHA-256 hash chain; verifiable with standard tooling
Security posture	Manual review	6-domain continuous posture engine with regression alerts
Air-gap	Possible but complex	Supported; no mandatory outbound connections
License model	Per-seat or site license; feature tiers	Flat license; no phone-home

What changes in Xferity

Workflows → Flows

MOVEit Tasks become Xferity Flows.

A flow is a YAML file that defines:

source and destination partner
direction (upload or download)
file matching rules
schedule
retry and idempotency behavior
PGP payload handling
cleanup behavior

All under version control — no GUI-stored configuration that diffs invisibly.

Hosts → Partners

MOVEit Hosts become Xferity Partners.

Each partner is a YAML file defining:

protocol (SFTP, FTPS, AS2, S3)
endpoint settings
trust material (SSH key fingerprint or TLS certificate)
auth credentials via secret references

Users → Secret providers

MOVEit stores transfer credentials in its database. Xferity uses secret references:

auth:
  password: env:PARTNER_SFTP_PASSWORD
  # or
  password: local-vault:partner-sftp-pw
  # or
  password: vault:secret/data/mft/partner#password

No plaintext credentials in configuration files. Hardened mode rejects plaintext at startup.

Protocol migration

MOVEit	Xferity equivalent
SFTP transfers	SFTP transport with host_key_fingerprint
FTPS transfers	FTPS transport with explicit TLS, optional fingerprint
AS2 messaging	AS2 transport with certificate role model
HTTP(S) file transfer	Use SFTP or S3 for equivalent workflows

Security hardening that MOVEit cannot provide

Feature	MOVEit	Xferity
Config drift detection	None	Strict YAML parsing; unknown fields fail startup
Tamper-evident audit	No hash chain	SHA-256 hash chain per event, verifiable offline
Isolated PGP execution	Global keyring	Per-operation isolated GnuPG home
Startup security enforcement	Runtime warnings	Hardened mode: refuse to start on insecure config
Continuous posture monitoring	Manual review	6-domain posture engine with hourly snapshots and regression alerts

Migration steps

Step 1: inventory your MOVEit tasks and hosts

Document:

all active tasks (source, destination, schedule, file filter)
all configured hosts (protocol, hostname, auth method, trust material)
any PGP keys or certificates in use

Step 2: create Xferity partner files

For each MOVEit host, create a Xferity partner YAML file. Use secret references for credentials.

Step 3: create Xferity flow files

For each MOVEit task, create a Xferity flow YAML file. Match the direction, file filter, and schedule.

Step 4: validate

xferity validate
xferity diag <flow-name>

Step 5: run in parallel

Run Xferity in parallel with MOVEit for a validation period. Compare transfer outcomes.

Step 6: cut over

After validation, disable MOVEit tasks and enable Xferity scheduling.

What Xferity does not implement

No built-in file encryption at rest (use OS-level or storage encryption)
No native HTTP(S) file transfer endpoint (use SFTP or S3 patterns)
No clustering or HA coordination (single binary per node)
No Kubernetes operator

Xferity supports

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