Yep, without primary keys you won't be able to replicate changes.
How much lag (distance from real-time) is acceptable?
How big are the databases?
How big are the tables you are interested in?
Do any of the tables you want to move to the 2014 instance have deltas indicating when changes occur?
With the version difference tossed in, the options get a bit limited.
You could do snapshot replication, but that may not bring over structural changes, and you are basically wiping/replacing the data in the reporting server.
You could do the backup/restore routine over and over. This would require a bit of scripting, and care to include the COPY_ONLY directive on the source system's backup, so it does not interfere with any of the regular backups and possibly differential backups you may have. This also does not allow for changing the structure or indexes on the reporting system, unless you get into some serious scripting.
You may be able to implement change data capture, but I believe that will require a PK on the tables you are monitoring.
If you implement Merge replication, you will get just the changes in the data, but you will incur a pretty serious performance hit on the source system, especially for large updates, or high numbers of updates, as this will place a trigger on each replicated table.