My viewpoint most closely aligns with GoodEnough's as I've been in the same situation he describes most of my career, and I have some further depth/breadth to add.
Your best possible wager on an "off-platform" hire would be a Jack-of-All-Trades-and-Master-of-SOME. You need the guy to be a rock star in at least one or two of his areas because you need to be sure that he has the capability of exceptional work. You don't want a utility infielder type (can play every position but only as a mediocre replacement for the guy who really owns the it). He'll end up causing you more problems than he solves.
What you're looking for on the resume is a bunch of different platforms (with specific versions), a bunch of different languages, and projects complex enough to merit some really heavy design considerations. Just because the guy worked for a Fortune-100 company doesn't mean he worked on any mission-critical projects. They could've all been little internal department apps that nobody ever saw in the light of day. Make sure they have some significant business importance. If the guy's a real rock star, he'll gravitate toward the gnarliest projects. And regardless of how well he "talks" his game, if he doesn't have any big, nasty projects on his resume then he's not a rock star.
In the interview, you're primarily looking for a nimble thinker who is able to explain even the most complex of his former projects to exactly the level of detail necessary for you (and whoever else is in the room) to understand. Ask questions at different "altitudes" and expect the answers to be in the same altitude you asked them. Present a current challenge you're experiencing (or have already solved) and ask him for a similar example from his past and how he solved it. His story ought to resonate with you. If it doesn't or if you end up more confused after his explanation than before...then he's not the one.
And now for two very specific war stories. One with a good ending. One not so good.
Back in the day I was a Vignette consultant (hired gun, not employee). I was on a gig in NYC, and that company had partnered with a consultancy in Buenos Aires to extend their footprint internationally. I flew down to BA for a week to teach a roomful of ASP programmers (.NET wasn't yet a twinkle in Bill's eye) how to do Vignette.
So if you know anything about VIGN, you know that the special sauce for that platform was its ability to dynamically pull stuff out of a DB and then cache static HTML files on the web server docroot. Huge performance benefit vs. always pulling dynamically. And in order to most effectively architect the caching strategy, you had to "pack the OID" which means concatenating various primary key values into a single element in one portion of the URL of the cached file.
At the time, ASP programming was either POST-heavy (everything stuffed into the header) or GET-heavy (big ugly query string of vars). So as we went through the week, I continually hammered on them to replace their POST- or GET-centric design thoughts with pack-the-OID thoughts. Most of them seemed to get it, but this one guy was a real stubborn mule. Up until the last day, all his design exercises still looked like they were right out of the ASP cookbook. It wasn't until the "final exam" on the last day did that guy ever design an app with a packed OID. But of all of them, that guy ended up being their strongest VIGN guy because once he got it, he really got it. Just took a while for the light bulb to go on in his head.
The other story is much shorter. Big credit card processing company. Half a million lines of C talking to another half a million lines of COBOL. One camp (the C programmers) really wanted to implement CORBA. "Just need to stuff the C code in some CORBA-compliant wrapper, and we're off to the races," they said. The other camp wanted to rewrite the C in Java. Now this was in early 1997, so JDK 1.1 had just been released. As their "example" they (the COBOL programmers, ironically) wrote a massive several-thousand-line example java class of "how easy it would be to rewrite". Moral of the story: don't ever let your COBOL programmers write Java without Object Oriented adult supervision.