One of the mistakes made was to assume that everything the old team did could be described as a procedure that a junior offshore employee could follow. This is a fallacy at a basic level, and shows a basic misunderstanding of IT. Knowledge is more than just memorization of individual procedures, it's information about topology, architecture, the flow of information, how the business works, and where the knowledge points are in the organization. (Who knows what.) Degradation of that knowledge base began on the day outsourcing was announced, and by the time transition arrived, there wasn't much left.
I've seen the same. I took over a fairly large database project with distributed client software from a previous team. I had about a day to ask questions of that team. I learned most of it on my own; I added a lot of code comments, logging, and documentation as I went. The project was outsourced; they had 30 days of daily sessions and Q&A to learn the project. The team it was outsourced to supposedly had experience with this particular database (it has a client/user interface built on top of the database engine). They asked a lot of questions (all answered), received all of the documentation, had access to test servers for testing code changes, and managed to screw it up within a couple of days of taking it over. The support part of the team starting contacting me for help... After I'd been laid off. Not much I could do to help for free... They, of course, then promptly blamed me, claiming they hadn't been trained on whatever they screwed up. I heard it took them six months to get it straightened out again. You get what you pay for.