Table Partitioning, like several other features, is quite often (or possibly even most often?) used inappropriately. Any of the cautions I would give have been nicely stated in @swasheck's answer.
In addition, an alternative to consider is Partitioned Views. This is a way of keeping fully separate tables but linking them together via UNION ALL in a View. Each table requires a CHECK CONSTRAINT enforcing which range of data each table holds. The optimizer knows of this construct and should only access the underlying tables that are required by a query using the View (I don't recall all of the requirements to have this work as intended so please see the CREATE VIEW link at the bottom, but I have set it up before and it wasn't difficult to get it to work as expected).
There are definitely some restrictions, and a main downside is that it is less transparent as compared to Table Partitioning. However, a main benefit is that these are separate tables, and hence the statistics are completely separate, whereas with a Partitioned Table they are for the entire table (even if, starting in SQL Server 2014, you can update the statistics per partition).
If you are not going to be making use of switching partitions in and out, you should consider this option. Especially if the older data isn't changing much since the tables holding the older data don't need their indexes / statistics updated nearly as often (or possibly ever if that data never changes).
Another downside to Table Partitioning that goes unmentioned / unnoticed all too often is that starting in SQL Server 2012, you no longer get a "free" UPDATE STATISTICS WITH FULLSCAN when rebuilding partitioned indexes. You still do get this update stats with a rebuild on non-partitioned indexes, which the indexes on the tables in a Partitioned View would be :).
For more information on Partitioned Views, please check out the MSDN page for CREATE VIEW and look for the section on "Partitioned Views" under "Remarks".