My opinion, that is one of those "it depends" problems. Is the timeout in code execution OR is the timeout in the connection?
If the timeout is in code execution, do you know which stored procedures are misbehaving?
If it is in the connection, is your firewall configured properly for the end users?
One fun one we ran into recently was with a stored procedure that had existed for ages. Having VB6 call it we got no errors or warnings or anything. But when the C# app being designed to replace the VB6 one was called we got errors. The problem was with data type implicit conversions resulting in data being truncated. There are a few easy fixes to our problem, we went with explicit conversion of the data type to a smaller one.
If it is in code execution AND you still have access to the 2008 R2 instance, might not hurt to look at what the remote query execution time was set to. If you don't, might not hurt to try increasing the default timeout.
That being said, it is more of a "band-aid" solution. When you say the query doesn't time out when run from SSMS, how long does it take to run? Are there improvements you can make to get better performance out of the query?
Extending the timeout might help get the application working, but as data grows the performance is likely to get worse and worse. Improving query performance may be a better starting point to fix this rather than extending the timeout.
Now, if it is timing out on connecting to the SQL instance, I would expect the problem to be more on the network or configuration side of things. When you upgraded, did you do an in-place upgrade or did you install a new instance and migrate the database over? There are benefits and risks to both methods, but I personally prefer the new instance migration method as it gives me a chance to validate the instance level settings and review the logins plus it gives you a very quick emergency rollback. It will take more time in the long run as you then need to map the users up to the logins for each database, but that isn't that tricky to do. You will also likely have the SQL instance running on a different port or different machine. This means that the application would need to be updated to handle connecting to the new machine/instance.
Either way, did you update statistics after performing the upgrade? That could be hurting query performance...