The discussion here is about structure and form, not about whether outsourcing will play some role in your IT acquisition strategy. We're assuming that you don't have all of the talent you need in-house and that your appetite to continuously recruit, satisfy and (re-train staff is shrinking (at least a little!).
You have a number of outsourcing options:
Of course there are variations on all of these but the four identify the primary outsourcing models you might consider.
All of these variations require that you:
I strongly suggest that you seek outside help to develop your outsourcing strategy. I realize that this may sound absurd: The recommendation is that you outsource the work necessary to outsource the work! But the fact is that outsourcing has become very complicated and there are now consulting organizations that specialize in this kind of work. These consultants have experience writing requests for proposals (RFPs), screening the proposals and the bids, negotiating contracts, and then managing at least the initial implementation phases.
There are also some rules of thumb you might want to consider:
1. Above all else, your outsourcing process should be driven by the results of your core competency assessment and you skills gap analysis. If you find that you really don't need to be in the data migration business and that you have no data migration talent in your shop, but that data migration is an important (though non-core) component of what you need to do, then obviously you need to outsource data migration (probably as part of some large applications modernization process).
2. Make sure you know what you're doing. While evolutionary experimentation is often a good way to learn about some new process (like outsourcing) it may not be prudent. Breaking off pieces of your internal IT shop to give to outsourcers to try them out may make abstract sense but in practice may be doomed to failure. Why? Because you're likely to outsource the pieces that are the most politically correct while avoiding the really hard decisions about what's core and what's not.