There are ways to instigate a change without being loud about it. When you write your code, write it pretty, well documented and with great unit tests. When you are releasing, write good release notes. When you are in charge of a feature, do good code reviews. Make code review templates. Write good documentation. See what happens.
If you really want to put this on the corporate agenda, you need to convince the person making technical decisions. If this gets on his or her agenda, things will happen. Beware when approaching this person - you've been thinking about this for weeks or months, while it may be quite a new idea for them. It may take a while for things to sink in. Don't expect it will happen quickly, or even the way you think is right. Plant the seeds and tend to them as they grow. Be prepared for resistance among coders too - writing docs, tests and releases are rarely seen as very compelling work, especially with tight deadlines.
Before doing anything though, you need to think about how important this is to the business. To you, it may seem like a very important thing and a complete no-brainer. However, you may not have all the information necessary to make this decision for the business. To the product and business people, the opposite may equally seem like a no brainer. All they care about is that it does the job and hits the market when they need it. Tech leaders are often enslaved to this kind of stuff.
Also, in my experience, many times a rewrite / major refactoring ends up costing too much and producing little benefit in the long run. Old idisyncracies are replaced by new ones and key sections of the code - often most critical to the business - end up scarred by changes around them and not better in any way. Be prepared to encounter people with similar experience and perhaps a bit of resistance along those lines.
