A common scenario we have encountered during a Windows Server Migration project is re-visiting technological change and challenges that we part of a merger or divestment that occurred many years previously.
During the original merger project deadlines were tight and resources were limited so the most pragmatic approach was made. Something like connecting the two businesses via the company WAN, placing an Active Directory trust between the two businesses, possibly absorbing the Exchange mailboxes and then letting both companies operate as two distinct entities.
Other than cost and time one significant factor for this approach is because the analysis of the similar systems and integration would be very time consuming, difficult and costly. The benefit of this approach was time and the ability to keep strict lines of administrative control and data boundaries where needed.
Fast-forward to your Windows Server 2003 decommission programme. You and your server migration team are likely to absorb the discovery, analysis and change programme that was previously avoided. Even though the two entities operate as a single company they are two "islands"; administrative boundaries are clear, data location is clear, operational procedures for both may be different but still very clear for both.
You may end up merging and decommissioning the acquired company's Active Directory and servers. There might be software that is not available in the parent company. The whole discovery and assessment is key in this situation to know exactly what's being used in both businesses and what might need special attention.
It is also likely that the organisation grew through a number of acquisitions, therefore it is not a simple case of completing the merger of (simply) two businesses, the model is more likely to be a "hub-spoke" configuration with the parent company is in the middle and the smaller acquired satellite businesses all connect inwards. It might be that some of the acquired businesses traverse the main business to communicate and share information.
There are numerous challenges. One is the ability to plan and scope the work - until the project is well underway will you find the real inter-dependecies and blockers will appear. How does this lack of scope turn into clear actionable project workstreams? How are the workstreams budgeted when there are numerous unfinished projects to tie up?
It might be the case that one or more satellite businesses has different polices than the parent business. Policies such as compliance, protection, password, data and archive retention may differ. Remediation work may be required between the stakeholders from both businesses to find the right policy, for the business as a whole.
Due to the cost and business impact of these decisions these policy meetings are unlikely to be settled quickly. People need time to think, to design and agree new ways of working and to look at the longer term impact to the business. What started to as a server decommissioned project actually transforms into a company-wide strategy project - and you need to be able to drive these conversations forwards otherwise the project will come to a halt.
This scenario starts to demonstrate why we deem these projects as some of the most interesting and "creative" work in the Microsoft technology sphere. Because you need to review the appliction portfolie and combine business need whilst looking at longer-term policy. The projects are complex, requiring investigation and change across the business.
The most important factor is the understanding context of the work - how did the company get to where it is today? Knowing the company history may allow you to develop the right plan specifically for your organisation.
Technology debt is potentially a very large problem within organisations. Ad-hoc decomission work related to Windows Server is not the way to resolve it but you have no choice but to face it, head-on, if you are to complete your decomissioning programme.