Secure IBM i ↔ Windows file transfer is usually a scheduling problem first

The familiar failure mode

Many shops have a CL program that prepares a file, an FTP script that pushes it to a Windows server, and a scheduled task that picks it up for reporting, EDI, billing, or warehouse work. That can run quietly for years, but it tends to break in ways that are hard to diagnose: expired passwords, mapped-drive assumptions, partial files, silent retries, or two schedulers that each claim the other side failed.

The fix is rarely another one-off script. Treat the transfer as a production job stream with explicit identity, transport, scheduling, observability, and rerun behavior.

A practical checklist

• Use service accounts with scoped library, IFS, and NTFS permissions instead of shared operator profiles.
• Replace plain FTP with encrypted transport and certificate rotation that operations can document.
• Make scheduling visible on both sides: IBM i job scheduler entries and Windows Task Scheduler history should agree.
• Write failure records somewhere admins already look, such as *OUTQ, Windows Event Log, or the existing ticket queue.
• Design for reruns: idempotent transfers, clear file naming, and duplicate protection beat heroic 3 AM cleanup.

What good looks like

A healthy IBM i to Windows pipeline should be boring. Operators should know which job produced the file, which identity moved it, whether the destination accepted it, and exactly what to rerun after a failure. Security should not depend on a hidden password in a script member, and audit evidence should not require grepping three different logs after the fact.

NexUtil built IBridgeSync for this specific pattern: secure IFS ↔ NTFS transfer, scheduler integration on IBM i and Windows, TLS certificate auth, and logs that admins can hand to auditors without reconstructing the night by memory. It is a small utility, not a replacement for your whole operations stack.