You are dealing with technical debt here. In short, technical debt imply interest, that you have to pay over time, and at some point, you have to refund it.
Develloper's time cost money, so the technical debt can be seen just like the real debt, and cost real money.
You have basically two main solutions, and many solutions in between. You can decide that you don't want to refund that debt now, and continue to pay interest. Obviously, this will cost more in the long run, but allow you to have result right now. You can also choose to refund that debt, so you'll not go forward anymore as long as you don't refund it, but, at the end, you are free from interest.
Usually you have deadlines for delivery, and missing a deadline will cause distrust of your customer, and eventually you'll loose it. This could be a valid reason to burrow technical debt : you consider that what you gain with the customer worth the extra exepense of technocal debt.
You know that at the end, you have to adopt the new methodology, otherwize, you'll get more and more debt and you eventually go bankrupt (you now, when people decide to start again from scratch or when the project fail badly).
You have to plan how you'll change the existing codebase and transition to new practice over time, and distibute the change bit by bit on a daily basis. At some point, when thoses refactoring will leads to other losses, consider which loss is the worse and go for the best one.
The cost of not refactoring will increase over time (this are interests of technocal debt). So this will become eventually the costliest choice.
Be sure that your boss understand the concept of technical debt. Even with precaution, you will create technical debt. At some point, money as to be used to refund it. When you create technical debt on purpose, you HAVE TO have a valid reason for it, and see the debt as an investment (just like real debt). In any other cases, just DON'T DO technical debt on purpose.
You may be interested on methodologies to evolve DB and deploy thoses evolutions : http://richarddingwall.name/2011/02/09/the-road-to-automated-database-deployment
By the way, that's a difficult task, so good luck. It worth it !