基幹系のデータ移行で必ず出てくるのが、HULFT（ハルフト）をはじめとするファイル連携・データ転送です。単なるコピーではなく、配信確認・再送・世代管理という「業務の作法」が載っているため、雑にS3に置き換えると事故ります。相手が社内か社外かで解が分かれます。
01まず整理：連携相手は誰か
移行方針は連携の相手で分かれます。①社内システム同士、②取引先（対外）、③人手の受け渡し。③は閉域ファイル共有基盤の領域なので、この記事は①②を扱います。
02パターンA：HULFTをEC2で続投
取引先が仕様を変えられない対外連携や、移行期限が短い場合の現実解です。HULFTサーバをEC2に移し、集配信の定義はそのまま。取引先に影響を出さずに自社側だけ移行できるのが最大の利点です。回線（VPN/DX）の帯域と経路だけは再設計してください。
03パターンB：社内連携はS3ベースへ
社内システム同士の連携は、S3を「受け渡し場所」にする構成へ置き換えられます。送信側はS3にPUT、受信側はイベント通知（EventBridge）で起動——ポーリング不要のイベント駆動になり、スケーラビリティと費用で有利です。
現場のコツ：置き換えで落としがちなのがHULFTが担っていた再送・配信確認・突合です。「置いたら終わり」のS3に、①チェックサム検証、②処理済み／失敗の状態管理、③リトライとアラート（リラン設計）を明示的に足してください。ここを省いた置き換えは、月末に必ず「ファイルが来ていない」障害を起こします。
04パターンC：対外接続はTransfer Family
取引先とのSFTP/FTPS連携をAWSに寄せるならAWS Transfer Familyです。マネージドのSFTPエンドポイントの実体をS3にでき、取引先からは従来通りのSFTPに見えます。常時稼働の時間課金がそれなりにあるため、接続数が少ない場合はEC2にSFTPサーバを立てる方が安いこともあります——ここは台数と運用コストの天秤です。
05移行の進め方
- 連携一覧（相手・方向・頻度・データ量・後続処理）の棚卸しが最初。HULFTの定義エクスポートが一覧の種になります
- データ量×回線帯域で転送時間を確認（試算ツール）
- 切替は連携単位で段階的に。送信側・受信側の同時切替を避け、S3と既存の橋渡し期間を設ける
関連記事（HULFTクラスタ）
ファイル連携の棚卸しから、続投／置き換えの振り分け、Transfer Familyの設計までEMWで支援できます。連携定義の一覧があれば、初回相談で振り分けの叩き台を作れます。
相談する