There's a fair amount to consider when consolidating database servers. The two most important things are resource availability, and support issues.

On resource availability, it's pretty obvious. If you have 5 servers (for example) all running at 100%, and you try to consolidate onto 1 server that's twice as powerful (CPU, RAM, etc.), then it won't work. Too much workload for the hardware. I'm assuming you've already benchmarked all the servers to see whether this will matter or not.

Support issues mainly matter if you have third-party databases, like Citrix, Blackberry, etc., and they are being supported, even partially, by vendors. If one database, say the Citrix one, needs to have an SQL hotfix applied, but another application, the Blackberry one, won't support that same hotfix, then you can't have them on the same server. The only way to find out if that matters or not is to contact the vendors, and ask them about that kind of detail. Get their answers in writing, formally, so you can have documentation to back up the support contract, if it ever matters. Don't just ask over the phone, in other words.

There are other considerations, but they're covered under "moving a database to another server", and that's usually really easy. Connections will have to be updated in applications and websites, and so on. Make sure all database users have compatible server-level accounts. Make sure access security has the right isolation (don't use one account to access all the databases, if you can avoid that). Make sure collations and server-level settings and objects are set up correctly (linked servers, extended events/traces, automatic jobs and plans, SSIS packages, xp_cmdshell options, CLR options, filestream options, and so on).

There's a lot of work to do, but the first two things are the ones you have to answer first, because that will determine if it's even possible to consolidate, regardless of technical hurdles.