Answer
Keeping EDI processing on IBM i tends to work best when the transactions feed directly into ERP logic written in RPG or COBOL and the team wants tight, low-latency integration without an extra network hop or file transfer step between systems. It also keeps EDI inside the same backup, security, and high-availability posture as the rest of the IBM i environment, so a disaster recovery plan built around journaling and replication for the ERP naturally covers EDI too, instead of requiring a separate DR plan for a third-party platform.
External or cloud-hosted platforms tend to win when the business needs a managed team to own partner onboarding and day-to-day mapping changes, or when trading partner volume and turnover are high enough that dedicated EDI staff and expertise become the real requirement rather than where the translator technically runs. Buyers should price both paths honestly: in-house IBM i processing has real ongoing labor cost for mapping and monitoring, while managed platforms have real subscription and per-transaction cost, and the cheaper-looking option on paper is not always cheaper once staffing time is counted.
The decision should also account for who owns the relationship when something breaks after hours. On IBM i, that is the internal team. On a managed platform, it is a support contract, and buyers should know exactly what response time that contract guarantees before relying on it.