What struck me is "company-specific and mission-specific" vs "NOT mission specific such as the domain of library or platform functionality." The current method

What struck me is "company-specific and mission-specific" vs "NOT mission specific such as the domain of library or platform functionality." The current method is hurting mission-specific achievements. That doesn't mean you now need to implement a generic (say) EDIFACT library or platform. Hell no to that! But the current platform does not allow the current people to implement these mission-specific functions quickly enough. The problem sounds like it may be at that boundary: people and quickly enough. One direction would be to add people (freelancers easiest for a start) who can ADD better platforms and libraries' functionalities to the overall system - while the current overall system keeps doing what it's doing. That was a common issue in my world and solved readily enough. Replacing the current system is unlikely to be practical quickly or cheaply, while adding side functions and side architecture might be pretty easy, beyond what the current people can manage. And that would achieve "business requirements" without falling in love with each such solution. After that, 80% is fine if it's the RIGHT 80%: Perhaps there are 2 EDIFACT platforms in use to achieve the specific function your business needs. In the sense of suboptimal but getting the job done. (Added to that, to me it's normal if parts of solutions get duplicated or redone for a different platform or library. That goes with "not falling in love" with any such solution. Just parts. Not the whole thing at once.)