Some of our earliest design decisions were: - Everything one could do with point and click must be possible with an API call. A developer should build a clone

Some of our earliest design decisions were: - Everything one could do with point and click must be possible with an API call. A developer should build a clone using the API. Developers should be able to build products on top of this or use it as a subsystem in their systems. - Build on top of common abstractions and units of 'thought'. Docker, S3, HTTP, JSON, etc. - The platform must be able to die without users left scrambling to exfiltrate their work (based on my personal motto of being able to die without the team being impacted beyond nostalgia). I can't say whether integrating your two products would give a pizza+ketchup, but if you are going that way, having APIs on both products could result in at least one prototype of a new product leveraging both without being entangled in anyone's implementation or limitation. Then slowly removing the scaffolding and replacing each API call with functionality from the new product and shutting down the functionality in the original product until none of the calls go to any of the two originals. That is one way to do it with pros and cons. The pros are that you're not bastardizing anything or trying to fit a square peg into a round hole. One other advantage is that you get a first proof of concept that has the valuable functionality of both. Cons would be that the new code isn't battle tested and lacks the scar tissue. Like any rewrite, pros and cons. Both of your teams are one team now. This is your new product. Both must be willing to kill/retire their own product or each team will try to make theirs survive.