A few thoughts:
Did you perhaps use a different method for updating statistics than was used on 2008R2? The various methods can have very different results.
What was the compatibility level set to when the database was on 2008R2? It may have been lower than 100 since 100 is the minimum for 2014, and perhaps you've been affected by earlier statistics regeneration changes.
For the best odds of getting the previous behaviour back while you investigate, first set your compatibility level back to 100, and clear the query cache. (DBCC freeproccache--beware possible CPU impact on live system due to recompiles as queries are first rerun.) Then try to get the statistics back to something similar to their previous state (which should also trigger recompiles when appropriate).
(Sorry, I can't add comments yet, no downvotes please.)
To clarify why I said you should set compatibility level back to 100: That's because level 120 will enable the extensive changes to the cardinality estimator that SQL 2014 introduced, but level 100 will keep things as they were in SQL 2008R2.
But I'm curious as to the difference in query run time between the two plans you posted, as well as which system each was generated on. Because both plans have very similar estimated and actual rows throughout (which suggests that statistics are not the problem), and the plan differences I can see don't seem to be able to cause a massive difference in execution time.
Are you absolutely sure these queries were actually run with no problems before you updated statistics? If not, is it possible your SQL 2014 server has an insanely slow tempdb location which is killing the interim result set writes?
And are the queries you posted executed by the app exactly as posted, or are they run as part of stored procedures (which would make a major difference in the plans generated)? If part of stored procs, perhaps you simply have parameter sniffing issues, which will be alleviated if you add Option (Recompile) to the end of the large complex queries you've identified as problematic--at the cost of some CPU and response time and other downsides. https://www.brentozar.com/archive/2013/12/recompile-hints-and-execution-plan-caching/ is a good place to start understanding the nuances.
Please do post your eventual solutions, as this is an interesting case.