Replacing a scheduled SFTP script: an IT handover checklist

1. Write down the transfer contract

For one representative job, record the source directory, filename pattern, destination folder, expected arrival window, service identity and business owner. Include whether an empty input folder is normal or an incident. Describe what the receiving application expects: encoding, delimiter, naming convention and whether it requires an additional import step. A successful file transfer does not prove a successful downstream import.

Example: an operations system creates a daily inventory CSV in an SMB share. A partner expects it in an SFTP inbox before the start of its working day. This is an illustrative workflow, not a FileAgent customer case study. Keep the original export process unchanged while evaluating the transport.

2. Test as the actual service identity

An interactive administrator session can hide the cause of a scheduled failure. Check the account that actually runs the service, its access to the network share, its outbound network path and the remote folder permissions. Use an explicit network path rather than assuming a drive letter exists in the background session. Test with non-sensitive sample files before using production data.

For SFTP, verify the server identity using the host-key information supplied by the remote administrator. Document credential ownership and rotation. Do not copy passwords into a task description or a troubleshooting screenshot. Check your selected connector's current documentation for its authentication and trust configuration.

3. Define copy, move and overwrite behavior

Start a migration with a copy into a separate destination folder. Decide what a repeated filename should do before the second run: reject it, replace it, or create a new version. Determine how the receiving system recognizes duplicates. Do not assume any transfer tool provides exactly-once processing across an arbitrary external application.

Move and mirror operations need a separate review because they can remove files. Keep the original source during the pilot. A source-side rename or export-complete marker can help distinguish a finished export from a file still being written; verify whether your source system supports that pattern before adopting it.

4. Exercise failure and recovery deliberately

Use a test endpoint or agreed maintenance window to check an unavailable server, an incorrect path, denied write access and an empty source. Observe the result and the notification path. Confirm that retries cannot collide with the next scheduled run, and establish who can safely replay a failed delivery. Keep a short runbook with the last successful run, the expected filename and the rollback procedure.

Where the existing script already meets these requirements and is maintainable by the team, keeping it may be the right decision. WinSCP documents scripting combined with Windows Task Scheduler, and rclone offers file copy and synchronization commands. A graphical scheduler is most useful when ownership, visibility and repeatable administration are the actual pain points.

5. Evaluate the FileAgent plan against the workflow

FileAgent runs on your own Windows or Linux host and provides scheduled jobs, stored credentials and execution history through a web interface. The Free plan covers local and SMB copy/move with two jobs. An SFTP workflow requires Pro or a higher plan; Pro is currently listed at $59 per month or $590 per year, including shared administration and Sync/Mirror. S3 and Azure Blob connectors require Business or above. Check the live pricing page before purchasing because entitlements and prices can change.

For this pilot, install FileAgent, complete first-run setup, add the required credentials, and create a job using the documented source and destination settings. Configure the schedule only after a manual sample run succeeds. Review job history and the applicable notification settings. Do not infer a compliance certification from a connector or an encryption feature; your organization still owns its deployment, access controls and data-handling obligations.

6. Run a controlled cutover

Agree on a pilot window that includes normal and failure cases. Keep an evidence sheet with run time, source filename, destination filename, result, retry outcome and downstream acceptance. Measure time spent administering the workflow and the frequency of missing or duplicate deliveries. These are your own acceptance criteria, not promised FileAgent benchmarks.

At cutover, disable the old schedule before enabling the new production schedule. Keep the prior configuration and a documented rollback owner. Review the first working week with the downstream owner. If the transport is reliable but the recipient still rejects the file, investigate the data contract rather than repeatedly resending it.

The decision to make

Choose the approach your team can operate and troubleshoot. A small, well-owned script may be sufficient. FileAgent is worth evaluating when recurring file jobs need a shared interface, visible run history and clearer operational ownership. Start with one workflow, establish evidence, and expand only after it meets your acceptance criteria.