Multitenancy is a hard problem. Very hard. I've seen a lot of companies do it, very few of them having done it well.
To cite just one of the many examples of where multi-tenant systems can fall apart, consider what will happen when one customers wants a data warehouse or ad-hoc reporting database. Can you spin one off relatively easily, or do you have to go through an immensely painful data scrubbing process that takes forever to run, has to drop a bunch of keys and constraints, and often loses data that is technically supposed to be shared?
I've seen the latter scenario happen at least twice. It's not uncommon.
Multi-tenant systems really have to be written as multi-tenant systems from the ground up. If you try to convert a traditional multi-instance farm to a multi-tenant system, you will screw it up for several iterations. And if you choose to rewrite... well, best of luck.
There are a lot of advantages to multi-tenant systems, but contrary to (apparently) popular belief and/or intuition, productivity is not one of them, at least not until such time as you are maintaining dozens or even hundreds of separate instances. It adds a huge amount of complexity, related both to look and feel and to the business logic itself. You'll probably need some kind of rules or workflow engine. And your uptime and support/call-centre performance will suddenly become a lot more sensitive, because any failure you experience will affect all your clients, not just one.
You will also definitely have to reign in the customizations if every customer is on a shared system. You will eventually run into a situation where two different customers have mutually exclusive requirements and will have to choose a victim. If your organization, like so many organizations, has trouble saying "no" to paying customers, this will bite you, hard.
Most of the cost savings that multi-tenancy has historically provided on hardware can also be obtained today with virtualization. With vSphere or similar products it's almost trivially easy and quick to spin up new instances, even if installation is normally very complicated.
What you don't get with virtualization is the simplified deployment (new releases) and the ability to do data mining. Question is, would either of these benefit you right now?
Rolling out 1 update instead of 10 updates might be easier... if you've got really tight QA and are extremely confident in the stability of the product. If not, then that 1 huge update is far riskier than the 10 small updates. Only you (and your company) can decide which applies to you. And as for analytics - if you're not big on analytics now, or privacy laws/regulations prevent you from doing that kind of data mining, then don't assume that a shared database is suddenly going to start benefiting you in the distant future.
Just to be clear, I'm not against multi-tenancy, but you're hardly the first person to ask the question or the first company to go down that path. Don't assume that it's going to be easy to consolidate, and definitely don't assume that it's going to be easier to maintain afterward. It's generally a lot harder; you should only go with that solution if its specific benefits are particularly important to you.
For vendors without a huge number of clients, it's probably better to invest your time in test and release automation. If you've got a full suite of regression tests running every night and can do a promotion in 10-15 minutes (generally parallelizable), the number of instances tends not to matter that much. There's a limit, yes, but... you'll know when you're getting near it.