I do this sort of thing as a matter of course, normally in much smaller environments. Healthcare organizations are problematic: they often have proprietary software wedged into their workflow in fascinating ways, such as laboratory data reporting tools and legacy accounting applications. Whether to maintain a minimal Windows architecture, or any other displaced architecture, for access to this old data is an important technical and buisiness decision. It has become easy to virtualize and isolate such hosts, so the underlying hardware is Linux based or VMware based, and the guest operating systems can be isolated and locked down for security and support reasons. Also, getting people off of Outlook and documenting everything with Word documents is often a nightmare. Documentation policies and a good mail system with good scheduling tools are invaluable for the migration.
A team of Windows admins in a large organization, such as 3 for Exchange, 3 for AD, 3 for the accounting system, 2 interns for swapping and transporting backup tapes, and 3 for desktop support, can often be retrained and shrunk. Or their roles expanded to cover tasks they couldn't manage before, such as security. If they're not already interested in the idea, the project will fail: That large of a bureaucratic group can poison a technology switch, even if they're reasonable as individuals, In some cases, they can often take over work previously passed off to external consultants and keep their head count. But if the migration is a planned from the vice president as an arbitrary "big picture" switch, without details considered, and it's a recipe for disaster.
Retraining is possible. Good engineers who handle such large migrations are worth their weight in gold, and even if the IT headcount shrinks, some can be convinced to take up a consulting role to support legacy apps and critical environments for long-term data access. (This is often critical for old medical or fiscal records.)
And there is one critical piece that I've repeatedly encountered. There is usually one absolutely critical software server, running on obsolete and unmaintainable hardware, that is neither allowed to be shut down for maintenance nor migrated to a newer version because "there is no budget for that", and yet is a critical 24x7 application. Whether it is a license server, print server, spam filter, or accounting software does not matter. This server has inevitably not gotten system updates in years, is unmonitored, has no password for its admin account, and is only discovered when attempting to clear an office of equipment and the entire environment shuts down when it is unplugged. The migrators are _always_ blamed for the problems with these unmaintained systems. It's vital to get such critical legacy systems into the migration plan, _in writing_, to avoid confusion about who gets to fix it when they inevitably fail.