I am thinking of repatriating IM/IT services that were centralized a few years ago. Does anybody have advice on how to do this transition smoothly?

Make sure you have accounted for the change in tools and apps that will be required; I assume you will be using Virtualized/Private in-housed Cloud services?  Also, a BIG one is how you are going to deal with security, regulatory regulations and requirements, etc.
Backup and snapshots might also need to be dealt with differently, as will your calculations for disk space usage.

Good points from both Roland and Joanne already so I won't cover any of that.
I think your question is probably about only certain services and not 100% of all Centralized IT services.  Somethings don't distribute back to the businesses well after consolidation and "optimization" (job reductions)   E.G. your WAN and Network security services wouldn't be a good choice to decentralize.   Where we successfully decentralized were key services that individual businesses valued more than others.  Some of our low margin businesses just want IT to be as cheap as possible and don't want to manage a single aspect of IT.  Our high margin, highly technical businesses want rapid IT response for PC problems, mobile phone app support, SAP & ORACLE support, BI Support.  Those businesses could then hire some dedicated IT support that only worked on their business specific issues.  They did have a dotted line back to CORP IT, but CORP IT had zero say over their performance reviews, pay raises etc.    I would start with the services that your business demands the most value and speed from first.

First ask why.

I would first want to understand the real value of a repatriation exercise, and to ensure a successful outcome means the first step is to focus on the end state. 

Once repatriated, what specific problem (or set of problems) has the repatriation solved today, near term, mid term, long term. By example if the "centralization" was a lift and shift to a cloud, and the result is network latency, that impedes a process or data flow and that can be solved by having workloads at your edge (node) that would not only make sense but create measurable business value. 

At that point I would then move on to looking at cost, benefit and risk, including sunk cost (centralized) application refactoring..

What is the perceived  impact to the rest of the organization which remains on a centralized architecture. Apply many lens (process+Value+Impact) to truly ascertain gaps that would be created by decoupling one facility or division from many others.

Once you've worked all that out, then you'd be well positioned to deal with the human capital management and leverage HR for help.

 

 

 

As with unification, the decentralization must be handled in a similar fashion: people, process, technology.  The transition from one org structure to another requires a very careful and deliberate transition plan, starting with a vital communication to all that are affected.  The position descriptions have to be addressed to verify there are on changes to work assignments--this requires close coordination with HR.  Budget codes have to be reviewed and approved by Finance Dept. Process documentation needs to be handed off to ensure smooth transition.  Lastly, the technology or supporting tools need to be identified and also handed off.  This last area also has a financial component if there are commercial software tools with recurring expenses.