First you have to identify the performance blocks before you can estimate the time to fix. If the block is caused by needing a newer server with more memory and processing power that doesn't take long to fix. If they have a good equipment, but the problem is the basic design of the database, that could take a year or more to fix. Or maybe they need database partitioning to be able to access things faster.
In a mature product, you should have dbas finding the long-running queries and fixing them on a regular basis. Performance tuning should be continual. Further your devs probaly have a good idea of where the technical debt lies and that is a good place to start looking for performance problems.
I would estimate the time to identify the performance blocks and tell them that you will prepare an estimate to solve the problems once the problems are known. I would also start right now to look at your long running queries and fix them. Each incremental improvement will help keep the client on your side. You might also have them give you a prioritized list of the areas where they have the slowest performance to give you an idea of what to start with. You might even consider proposing an interative process when you spend a week or two identifying problems in one specific part of the application and then another week or two fixing those problems then move on to the next section, etc. That way, you can start improving before identifying all the items causing the poor performance.
There are known performance issues with certain types of SQL structures (this varies by database backend), but for SQL server, if you are frequently using such things as correlated subqueries, cursors, functions in joins and where clauses, scalar UDFs, views that call views that call views, then it is likely your database needs a major overhaul. If all your foreign keys are not indexed that is an easy, cheap (in terms of time) win. If your devs don't know what sargable means, then likely you have badly written queries and almost every query will need to be examined for poor practices.
Frankly, it is nice your client is willing to pony up some of the money for this, but you did the poor design, your company should pay for the majority of the fixes.
Finally, make sure you learn from this. If the problem is bad design of databases or poorly performing queries, train your devs to write performant queries and/or hire a data specialist. Anyone who designs an Enterprise system without data specialists in the design phase is likely to have a system that fails when the load gets high. Performance should be considered in the design phase of database. This is NOT premature optimization, this is avoiding known performance issues. It is far harder to fix a mature Enterprise system in production that to fix a bad design.
I'm not saying the database is the only source of your performance issues, just that it is one of the most likely places. You do need to profile to see what is happening. I can remember one time when we were having a performance issue and it turned out the application was calling the same proc thousands of times for each page when it only needed to be called once. But as a data specialist, my experience has been that there are many poorly designed and poorly performing databases out there.