Using schema + Filegroups or entirely separate database(same instance) to partition some big tables?
Your problem is apparently all about storage space.  

Your SSD array is not large enough to hold all your history on SSD.

Creating another filegroup is a good way to separate the use of storage space. That way you control what goes onto the historic data disk array. (When creating objects on a filegroup other than default, you must be sure to specify the filegroup you are using of course. )

Depending on how massive the historic data is, you may not need to split the data by quarters, etc.  

For example, you were running well on the SSDs until space became a problem.  So, remembering that space is the problem, you could ask yourself questions like:


Are my indexes well-designed for this workload?
Do my queries require scanning all of the historic data?  (Apparently not, according to your comments above.)
Is the overhead of maintaining quarterly databases going to buy you significant query improvements?  (Especially if you will need data from more than one database.)


Making things simpler and well-designed should be a first goal.  But, if that is not sufficient then you should add layers as they are needed. Keeping performance statistics will help you measure the benefits. 

There are plenty of web sites with help.  Here is one set of queries by Glenn Berry: http://www.sqlskills.com/blogs/glenn/category/dmv-queries/