Copy a similar list to another
Small things

Your code styling is generally good, but a few possible improvements:


You can add a second generic type parameter to your method to avoid the need to cast to object. i.e. public static List&lt;TIn,TOut&gt; MergeListData&lt;TOut&gt;(List&lt;TIn&gt; collection)
You can probably use a more general collection than List&lt;object&gt; for your input collection. If you use IEnumerable&lt;object&gt; (changing your for for a foreach, which you should probably do anyway), then you can avoid the cast without having to do the previous bullet point, since IEnumarable&lt;T&gt; is covariant
Those exception handlers probably shouldn't be crammed onto a single line. If it were just the catch or the if, it'd be okay, but combining the two seems like too much
_propinfo shouldn't have the underscore, this is usually used for class-level fields.


The general approach

More of an issue is the overall approach of using reflection here. Reflection has three major problems:


It isn't safe. For example, here you could pass a generic type that doesn't have a default constructor and fail on the Activator.CreateInstance. This could be fixed with a generic type constraint, but that limits the useability of the method.
It's hard to read and maintain. The previous bullet point is one potential issue I noticed. Are there others? Who knows, reflective code is really ugly, and verifying all the edge cases by eye is tough!
It's slow. Whether this matters depends on context, but this method is pretty general-purpose, low-level, and operates on collections, which means that decent performance is at least desireable.


So, can we avoid it? Well, when you call the method, you already know what your two types are. Code with that knowledge should also know how convert between the two. So why not delete all that code and just write:

var bs = List1.Select(x =&gt; new Name2 { First = x.First, Last = x.Last }).ToList();


What you lose in automagicness you more than make up for in clarity, conciseness, verifiability, and performance. You can of course use a method somewhere instead of a lambda, to avoid spreading the mapping info all over the place.

If you really need this functionality (e.g. because there are lots of types, most of them can map to each other, and you don't feel like writing n^2 mapping methods)... well, that seems like an unusual situation, and I'd start by taking a step back and asking if this indicates a broader architectural problem. But if you've satisfied yourself that it's sensible, then I'd suggest using a library like AutoMapper rather than trying to roll this yourself. That way you don't have to concern yourself with how the magic works, and you get something much more mature and fully-featured (and, probably, performant).