Answer
Buyers should inventory the custom code, reports, interfaces, and downstream dependencies leadership actually relies on before comparing options. Without that map, teams underestimate both modernization upside and replacement risk.
The inventory should go beyond a list of customizations and rank each one by business criticality and by how well it is documented. A custom pricing calculation embedded in RPG that reflects years of negotiated contract logic is a very different risk than a custom report nobody has run in two years, and the ERP decision should weigh them differently. Buyers should also map every interface touching the ERP, EDI, a warehouse management system, e-commerce, banking files, and note whether each one reads and writes through supported APIs or reaches directly into Db2 for i tables, since direct table access is often invisible until a migration or upgrade breaks it.
This inventory tends to reveal two different problems that require different responses. Heavy, well-documented customization usually argues for extending or modernizing around the current system rather than losing years of encoded business logic in a rebuild. A sprawling, undocumented web of point-to-point interfaces usually argues for a broader integration cleanup regardless of which ERP path gets chosen, because that fragility will undermine any new system just as much as the current one if it is not addressed directly.