Having a group that solely focuses on refactoring and maintainability and implementing it at the expense of other development groups is dangerous to your organization. There needs to be a commitment from upper management, testers, and all development groups to improve the quality of the code via refactoring to improve maintainability and minimize bugs. It should be everyone's responsibility to improve the code. When refactoring needs to be done, then it should be put into the release schedule along with the new features. Managers need to be educated and understand that taking time to improve the code will pay off in the long run, because technical debt is what will bring a product to a screeching halt if not paid down as part of the ongoing development process. If all you're doing is constantly fighting fires from constant bug fixing, the house is going to burn down, because obviously the house is a fire hazard and needs better construction and reinovation.

You group sounds more like it should be a architecture/software staff group dedicated to developing the next generation architecture that will be more maintainable. Your group should probably focus on how to demonstrate refactoring pays off to the "pointy-hair" types, encourage developers with new methods and processes, and educate key stakeholders in management to adopt better code quality and get them to "buy-in" to the process. Come up with a plan to migrate products to a better architecture if anything by laying down a simple foundation first. Take the painful lessons everyone has been learning from supporting your products and come up with a plan to mitigate that pain in the future.

Having a group that solely focuses on refactoring and maintainability and implementing it at the expense of other development groups is dangerous to your organization. There needs to be a commitment from upper management, testers, and all development groups to improve the quality of the code via refactoring to improve maintainability and minimize bugs. It should be everyone's responsibility to improve the code. When refactoring needs to be done, then it should be put into the release schedule along with the new features. Managers need to be educated and understand that taking time to improve the code will pay off in the long run, because technical debt is what will bring a product to a screeching halt if not paid down as part of the ongoing development process. If all you're doing is constantly fighting fires from constant bug fixing, the house is going to burn down, because obviously the house is a fire hazard and needs better construction and renovation.

You group sounds more like it should be a architecture/software staff group dedicated to developing the next generation architecture that will be more maintainable. Your group should probably focus on how to demonstrate that refactoring pays off to the "pointy-hair" types, encourage developers with new methods and processes, and educate key stakeholders in management to adopt better code quality and get them to "buy-in" to the process. Come up with a plan to migrate products to a better architecture if anything by laying down a simple foundation first. Take the painful lessons everyone has been learning from supporting your products and come up with a plan to mitigate that pain in the future.