Lessons Learned from Post-Divestiture IT Chaos (and How to Prevent It)
- This topic has 1 reply, 2 voices, and was last updated 6 months, 2 weeks ago by
.
-
Posts
-
While acquisitions often get the spotlight, divestitures can quietly introduce just as much disruption—sometimes more. In particular, I’ve seen post-divestiture environments left in disarray because IT wasn’t given enough time, resources, or influence to plan and execute a proper separation.
In some cases, IT teams are still trying to untangle shared systems long after Day 1. In others, systems that were hastily duplicated or forked have become a maintenance headache. Worse yet, I’ve seen situations where both the buyer and seller assume the other side is handling critical support functions.
These experiences have reinforced the importance of clearly defined responsibilities, pre-separation baselines, and strong post-close governance. A good exit plan doesn’t just support the divested entity, it also protects the parent company.
What types of post-divestiture IT issues have you run into? And how have you mitigated the risks in your environment?
Dual running systems ongoing for a single customer who refused to allow their data to be moved without going through their full IT project delivery lifecycle, architecture review boards etc. The result was us migrating all other customers and having to retain the legacy instance (doubling the licence costs) while the customer’s data remained there. Lesson learned was to engage with customers early when moving systems/data, as each can have different expectations and commercial agreements which must be adhered to.
- You must be logged in to reply to this topic.