The reasons why it it picking that plan are actually quite simple.
On the 'good' server the cost of the 'good' plan is:
cost:2276580
On the 'good' server the cost of the 'bad' plan is:
cost:2900007
So the 'good' plan is picked.
-----
On the 'bad' server the cost of the 'good' plan is
cost:1.649122e+007
On the 'bad' server the cost of the 'bad' plan is:
cost:3573960
So the 'bad' plan is picked.
The reason the cost of the 'good' plan is so different is 2 fold:
A) The selectivity for IndexRef2 = 1942454143 is 'slightly' higher so it estimating that ~3000 rows are coming out of the scan of RSContent instead of ~800 rows on the 'good' server'.
B) These ~3000 rows are then used to cost the join to RSIndex and this is where the real problem comes in (as explained above). The data row cluster ratio for RSField3Key is 0.6137234, meaning it estimates it has to do 16 times more logical i/o per scan. This pushes the estimate up hugely.
Even if the estimate number of rows from RSContent were 800 rows it still wouldn't pick this plan.
On the good server, the data row cluster ratio is 0.99999 for this index so the estimate data page lio is a lot less. The DPCR figure is primarily driven by how well the data is ordered with respect to the index key. I.e. it reads a key value from the leaf level, this points to a row on a data page. When it reads the next key value is it likely to be on the same data page that has just been read or must it read in another one. If the data is ordered by the non-clustered index key then the DPCR for that index will be closer to 1. Index rebuilds won't effect this figure massively.
I notice the table says it is partitioned 8 ways, is it possible you have stuff distributed oddly and differently across the two servers?
You can also see that the estimate cost of the 'bad' plan on the 'good' server is only a touch less than the 'good' plan so the plan could flip easily on the good server.
You need to find out why the DPCR for the RSField3Key index is 0.99999 on the good server and 0.6137234 on the bad server. This may relate to the clustered index key, the partitions or something else. Unless the DPCR is near enough 1 it will not pick that plan. Even if it is 1 it almost picks the bad plan anyway and may well do if the search arguments change. Looking at the selectivity difference (A) from above), even if it were 1 on the bad server it would still pick the bad plan.
