I'm maintaining a legacy application that interacts with an ERP. The ERP has a lot of cool features. One goal of the legacy application is to store preparatory data to be sent to the ERP, but also keep the data up-to-date based on what happens in the ERP. A two-way synchronization.Sadly, the legacy application does not implement all the features of the ERP for the bits it needs to synchronize. But that did/does not prevent the business from using all the ERP features and then demanding that the legacy application remain synchronized.The differences are structural and not simple to implement in the legacy application. The business does not care about the issue because it's dealt with by the developers who have to cram data in a structure not meant for it, leading to many bugs and being forced to break data integrity rules in the DB (which impacts the business in return but in such indirect ways that they don't get it, no matter how many times it's explained). The business has better priorities.In the given situation, would it be a moral and/or professional duty to prevent this from happening further to preserve what little data integrity is left and start going down a cleaner road, or should the business's decision be the end all be all?In case stopping the madness is the right thing to do, how would one go about it?Knowing that in the current context, it seems impossibly hard to say no, the software cannot deal with this, stop trying to fit square pegs in round holes. The business is extremely frigid at the idea of developers spending time on making things structured and safe since it doesn't give them anything new (functionality-wise) to chew on. It's interpreted as wasted time basically.
How do you deal with clients who cannot wait for a feature to exist?
client relations