We have a kind of one-stop shop that supports a lot of different applications that belong to different parts of the business (and ultimately to clients).
First thing is to organize for success. Get everyone in the group on the same source control for instance. Next even though you all report to the same person rather than diffeernt business groups, there is nothing stopping you internally from designating programmers by product line or internal client.
We do move people around some in an emergency or when a new big project comes along, but generally they work on the same applications for the same clients. Each internal group of people may support multiple internal clients though. This at least gives the best chance that someone familar with the application is looking at it. It also means the C# programmers will be working with the C# programs and the Access programmers won't be expected to suddenly take on a project way out of their skill set.
If you are bringing together groups with wildly different expertise, then you need to build a matrix of who is qualified to work on what. (This will help in resource planning). You may need to find the time to set up some cross training, so that developers who use languages that don't have many projects can expand their skills to be more valuable to the group.
You may also need to look at making sure you have created a path for developers to move up in the organization. One of the few benefits to the change you are about to make is that more devlopers in one place means more chances to move up to senior developer and technical lead.
Given that you previously had many programmers in different parts of the organization, likely you have wildly different types of expertise, coding standards, processes. Some teams might be agile and some might be using Waterfall. If you want this to be effective in the long run, you need to work on moving to more standarized ways of doing business. Start with source control, then move to processes (If you can get everyone on agile, it might help some of your resourcing issues as once someone is on a sprint he or she woudl stay on the sprint.) In some teams you might have support devs and new development devs and others might expect a person to do both new development and support. Standardize on one method. Determine if possible a stardard set of tools you will all use or that will be used on all new projects. Set coding standards that will be used for all new projects (It may be too much to expect to change all the existing code done using a wild variety of standards.)
Next you need to set up how you are going to handle resourcing. There has to be a weekly or monthly resourcing meeting and all new projects will go into it and resources will be assigned. Resources can be reassigned between meetings but only within the resources available to a particular group (so if accounting has 3 resources assigned this month, they can move them from project A to project B when it suddenly becomes a hot topic, but they can't steal resources from the Sales team until the next resource meeting). If you are doing agile, the resource planning meeting should be one week before the start of a sprint and all sprints should be on the same schedule and duration (everyone has two week sprints and the sprints all start on the same day, for instance). Do not forget to allow time for production support in resource planning.
Get a standard process set up for how you will estimate the hours needed for each project. Do not forget to add time for QA, fixing bugs, deployment issues, development of technical specs, communication (you can spend a lot of time in a project on meetings and emails). In your resourcing, never plan any person for more than 75% of the time (you have to allow time in the schedule for leave,holidays, required company meetings, unavoidable delay, setting up computers when they havea new one etc. ) In my experience assuming 100% of the time for project work is one of the biggest reasons for deadlines to be missed, no one is ever at 100% of the time on direct work forever.
Make the individual departments you are supporting responsible to create requirements documents. If unfamilar people will at times be working on their projects, you need formal requirements documents. No Requirement document, no project. Period. Also, you will have to have a formal project management system set up. No one will work on anything until the internal client has set up a project to charge the time against. No more "oh by the ways", everything will have to be formally requested and worked into the resource plan. No more last minute requests either (except actual production bugs of course), let them know that all resources will be planned X amount of time in advance. Bugs should be reported in a formal system as well, there are many bug trackers out there.
In implementing the change, now might be a good time to get things you haven't been able to get before, like better equipment for everyone or some tools you would like but haven't had the budget to purchase (ask for suggestions from the folks in the trenches). Make sure everyone at least has two monitors!! And a good chair. Getting better euipment might help people in accepting the new system as at least there will be something in it for them!
I'm sure there is more, but that is all that comes to mind right this second. At least it will get you started on the planning process of how to implement.