Legacy System Support Decisions Require Collaboration

Legacy systems are a challenge for all companies, especially those who grow through acquisition or need to focus on immediate profitability after a merger. Modernizing and consolidating systems is often left out of acquisition timelines. Unfortunately, this often leaves IT with a patchwork of legacy systems to manage and a lack of partnership between IT and the rest of the business.
While working at a medium-sized company in the Seattle area, my group was left to manage a setup just like this. A growth model structured around acquisitions, combined with a lack of system ownership within business groups, left IT to manage a patchwork of nearly a dozen separate Finance, HR, Payroll, and Sales & Marketing systems across several business divisions. Our IT team of three was left with the challenge to integrate, administer, and patch this network of systems on our own.
Taking Ownership
The IT team knew these systems were designed to help the business function consistently and efficiently, so we set out to do everything in our power to provide the business with maximum value from these systems.
However, without any direct partnership between the IT team and the business, four issues arose.
When an issue was discovered, IT had no clear escalation path to follow to find users to help troubleshoot and design workarounds to resolve these issues. We were unable to get any help with testing a time-critical workaround and left entirely on our own to first find and then communicate to all impacted users. Since IT alone was testing the fix, two additional risks arose: That the potential fix may not resolve the entire issue, and that the fix itself may negatively impact another group after it’s implemented.
IT had no single contact for planning patches and system outages. Again, we were left to find anyone who would be impacted by these projects. Generally this wasn’t an issue, but special projects or new groups unknown to IT were at risk of unexpected impacts from these outages. Whenever this happened, the project would need to be immediately halted, reverted back, and then re-planned; this led to a lot of extra planning for IT as well as the business units that needed to work around the outages.
Required patches and system upgrades often release new, important, and time-saving features, but they can only be implemented if IT takes the extra step to notify the business of a possible enhancement. Since we didn’t see all of the operations of the business, we didn’t always know that a feature would be beneficial. As a result, these changes would go undiscovered and unused for long periods of time after release – if they were utilized at all.
Suggested upgrades and changes would come into IT from any user. There was no “owner” to triage and prioritize these suggestions. We had to independently prioritize these suggestions based on whatever information we had. This led to resentment...