How Flow Migrator chooses SQL Server, DB2, and IBM i routes
Many teams say 'AS400' when they really mean several different things: DB2 data hosted on IBM i, an IBM i program call, or an API layer in front of IBM i. Those are not the same target shape, and the conversion rule should reflect that.
The routing rule
The safest provider-aware rule is simple. SQL Server provider or connection means use a SQL Server family action. DB2 provider or connection means use a DB2 family action. An explicit OpenLegacy or IBM i API target means use the OpenLegacy IBM i family.
If the backend is IBM i hosted but the workflow is still doing plain SQL-style data access, default to DB2 rather than OpenLegacy.
- SQL Server provider → SQL Server family
- DB2 provider → DB2 family
- Explicit OpenLegacy / IBM i API target → OpenLegacy IBM i family
- IBM i backend with plain SQL access → DB2 by default
Why 'AS400' is not enough by itself
AS400 or IBM i is a platform label, not a connector contract. A workflow can talk to IBM i-hosted data through direct DB2 access or through an API layer such as OpenLegacy. The converter should not guess OpenLegacy just because someone says the source system is on AS400.
That distinction prevents the product from overpromising a connector family that the source workflow never actually used.
What this means for current coverage
Today, the strongest native database coverage is for simple DB2 table and row patterns. Other provider families can be routed conceptually, but they should only be marked fully supported when the exporter is actually emitting those native actions end to end.
Routing logic is not the same thing as claiming complete action coverage for every provider family.