There is a company let's say "X" which mainly deals in Real Estate / properties and has a website (online portal) to display those properties.
Just like any other big company when they saw a competitor they acquired it and let the legacy of competition intact between the sister companies so that the business grows and the ultimate benefit will go to the parent/head company.
Now consider "X" acquired "Y". X's management then took the decision to use X's source code by revamping UI and quickly relaunch Y in market, oh and yes with same database and introduce a new value/column to differentiate between sources/apps to record activity of both portals. ( This is because Y's management didn't sell code or database but just the name / SEO).
X's product management team decided to use Y to target those area where X is weak so that Y will get stronger on those area and compete with the rest. This change will require App level logical changes / tweaks in codes. Ps. X will feed Y with new leads / property records as an aid to get an edge over other competitors.
The problem which engineering team is facing is:
Source code is a legacy code and is not up to the mark
X's data is already too large ( let's say 10M+ records )
Database schema/structure is a complete mess!
Engineering team never got a chance to clear the technical debt and they don't see it either in near future.
Ps. some business level decisions / logics like: X will have it's own users and Y will have it's own users ( means you have to signup at Y to post your property or get the app specific stats, though X's user will be given leverage to post stuff on Y without signing up and that needs to be handled in app's business logic.)
As an engineer, I see 2 options. Either to go in single-tenant fashion or Multi-tenant. Instead I share my opinion, I would like to know the best strategy / Architecture|System design that should be used in this scenario. What should be done for low coupled and easy to maintain code and cost effective approach ?