Now i'm running them both side by side
So, to clarify, you did a side-by-side upgrade. Meaning that you installed a new instance of SQL Server 2014?
In that case, if you are ready to rid yourself of the SQL Server 2008 R2 instance then you would need to transfer all of your necessary entities from the 2008 R2 instance to the 2014 instance. That'll include everything it would take to make your clients hit the new 2014 instance. Most notably, you'll be backing up and restoring your databases from the source (SQL Server 2008 R2 instance) to the destination (SQL Server 2014 instance). But you will most likely need to transfer other server objects as well.
Note: Max brought up a good point in his comment below, ensure that you have a valid database backup/restore on your destination instance before removing anything.
how can I abandon the 2008 version and only run on the 2014 version
Point your applications/clients to the new SQL Server 2014 instance after the migration. And then you can rid yourself of the SQL Server 2008 R2 instance if you no longer want those bits to be living on that machine. Warning, you should verify with the business and end users that functionality is now back to the same state as it was prior to the upgrade.
I've check the properties on the SQL 2014, and it shows that I'm still with 2008 R2 Express edition
I'm not sure what you mean here. How did you check the "properties" and what exactly are you referring to? You're either connecting to your old SQL Server 2008 R2 instance, or you new SQL Server 2014 instance. If the former, you'd be in the context of the old one. If the latter, you should be seeing the new 2014 instance. If that's not what you mean, then please clarify.
KB 3034297 - Cumulative Update 6 for SQL Server 2014 describes the issue that you are encountering and is fixed in SQL Server 2014 CU6
When you turn on SQL Server Managed Backup in Microsoft SQL Server 2014. When you let SQL Server and SQL Server Agent run for several days, there are many connections with the program name SQLAgent - Temporary Worker. They are created by "sqlagent.exe," and cannot be closed.
Best Answer
So you want to differentiate between the app calling stored procedures vs sending T-SQL directly? Sounds like an Extended Event trace would so. Assuming the programmers call these procedures correctly from the API (and not just send a text string with EXEC procname in it).
If you capture sqlserver.sql_batch_completed and sqlserver.rpc_completed I think you will cover the submissions into SQL Server.
When an app doesn't call a proc you should either see sql_batch_completed or rpc_completed. For the later, you can check out the object_name column and if it is sp_executesql, then you have the "not calling stored procedure" case.
When it does call a proc, you will have (hopefully, if they do it right) rpc_completed with something else in the object_name column.
Depending on how sophisticated you want to be, you can play around with event_counter and the histogram targets. Or even store the trace data in a table and query that table.