Answer
Customization debt is worth quantifying rather than estimating. Buyers should get a real count of modified programs, custom objects, and workarounds built around the base ERP, since a system with a handful of well-documented customizations is a very different modernization case than one with thousands of undocumented changes accumulated over twenty years. Integration pressure works similarly: counting the actual number of interfaces, files, and downstream systems that depend on the ERP shows whether replacement risk is contained or sprawling before anyone commits to a timeline.
Staffing is often the deciding factor that gets underweighted. If the team supporting RPG or COBOL customizations is shrinking, nearing retirement, or already stretched thin, that shifts the calculus toward a path that reduces dependency on scarce in-house programming skill, even if the current system still technically works. Disruption tolerance should be evaluated against the business calendar too, a retailer cannot absorb an ERP cutover during peak season, and timing constraints can rule out certain modernization or replacement paths regardless of their technical merit.
None of these factors should be assessed in isolation. A structured risk review that scores customization debt, integration count, staffing risk, and disruption tolerance together gives leadership a defensible basis for the decision instead of a choice driven by the loudest complaint in the building.