First off, congrats. Not many folks even get to this stage where you have a successful MVP with many users. Now, here are a few more things to think about.
Your Minimal Viable Product (MVP) is for experimentation and likely has many bits of code and shoddy-ish practices that are fantastic for testing out ideas, but not for sustained use on your client-facing platforms. So, don’t use your MVP as a technical foundation for your company for any longer than the initial stages of product/market fit and before scaling up to a brand new batch of employees.
Sticking with a MVP because of time constraints will kill you in the long run – you’re adding heavy floors on top of sticks and stones.
Write APIs, and then use thin clients for your app’s UI. These decouple the UI from the backend, and are both are easier to discard when the time comes without having to do a massive rewrite of both the frontend and the backend. I personally like Rails + Backbone.js for this at this point in time.
More often than not, the issue for not discarding MVPs is a lack of time/money. Just remember that technical debt is a lot more expensive in both sanity and money in the long run, so be mindful of every line of code you write.
Speaking of massive rewrites, the odds of success for one of those is comparable to that of a new startup. The longer your MVP sticks around, the more technical debt you incur. You never want to get to the point where the code needs to be rewritten but nobody wants to actually do it. Or even worse, if none of the new devs who rolled in actually understand the product well enough to make those many changes.
Commit yourself to discarding the MVP from day one, both verbally to your team and using TODOs in your code, especially if there are hacks in there that cannot be sustained over time.
Finally, actually do it and keep flying the plane while you do. It’s tough, but your product and your sanity will improve.