Introduction
Before joining Netwoven, I had never worked on a project making the technical changes needed to merge or separate two companies. It is a unique challenge. In this post, I will be sharing divestiture lessons I have learned, some painfully and some not.
Think about it: “divest” usually means to shed underperforming assets (exception: divest a potential star to help it grow, though you still have a stake). Companies divest assets for all sorts of reasons. A common reason is that the company is getting out of a business they used to compete in.
Move It or Lost It
I have experienced two things that are remarkably similar.
I have sold my home and moved out. (I will be moving into my next home in another month). And I have managed some projects brought about because one company was divesting itself of certain assets.
I have discovered two key characteristics of these two activities.
First, you must move everything. Not 90%. Not 98%. Everything. We all know that the 80/20 rule applies here, and that the last 20% takes a huge amount of effort to move.
Second, all your organizing and maintenance sins are exposed. Where did we put the keys to the garage door lock, the one we never use? Why do we have a trunk full of DVDs, when we do not even own a DVD player anymore? And so, we face the decision. Throw everything in a box and move it, even though we know we’ll never watch those DVDs again? Or clean up, purge the stuff we have outgrown, and just move what we know we will use?
Companies face a similar set of issues when they decide to divest parts of their business. (There are also issues companies face when they acquire businesses. Let’s save that discussion for later.)
When company A wants to divest certain parts of its business into a newly created Company B, they call us i.e. Netwoven.
Why? Because we know how to do this detangling. Moving elements of an IT network, its data and its applications requires in-depth knowledge of the underlying networks and service architectures. We have that knowledge. And the experience of using that knowledge multiple times.
Some Divestiture Support Lessons
I have learned plenty from these divestiture support projects. I have learned some technical lessons, yes. I have also learned (re-learned, actually) that these divestiture projects do not take place in a vacuum. They happen within an organization. And across organizations. This means that process matters. HWGSDH (How We Get S*t Done Here) matters. People and their feelings matter.
So, one divestiture lesson is this: understand the process of the divesting organization. What is the process for getting the information you need? How long will it take to get the information?
Similarly, what is the culture of the divesting organization? Is there a strong preference for hierarchy, where you need to get permission from above your peer level before proceeding? What are the rules regarding what we do and do not do here?
Do you understand the context for the divestiture? What is driving the desire to divest this part of the company? Do you know the negotiated date for the divestiture to be completed? Do you know what financial penalties will be imposed if the migration date is missed?
What kind of cooperation can you expect from the divesting company? What incentives are in place to drive cooperation?
I Want It Now. I Want it Perfect.
Another divestiture lesson is this: recognize that your project will be pulled in two directions at once.
- There must be a strong desire to get the job done. Deploy the applications as they are used today. Doing anything differently costs time and money.
- The opposing desire is to improve the application experience while you deploy the application. Go back and address those annoying interoperability issues. Get the workflows running as they were intended to. Move to the cloud.
As the migration support team, you are responsible for balancing these competing desires. Where can you improve the way an application or process works, without introducing undue risk to the project? What are the changes you must make to keep the application working? What is your fallback plan if your planned improvement becomes a scheduled risk later in the project?
People may think they know. They may say they know. They don’t know. You must discover what is there and what isn’t.
Hey, I am Working Here!
And this is a critical divestiture lesson. People were working yesterday. They are working today. They expect to work tomorrow. The business cannot afford downtime while IT figures things out. You are often working directly in a production environment.
Think of your divestiture migration as repairing a highway. If you could shut the entire highway down for a while, you could make your repairs and finish quickly. Of course, you cannot close the highway entirely, except for brief periods. You must migrate and upgrade in place. You must minimize the impact your migration project is having on employees.
Thanks to the pandemic, you are likely to find that application users are much less likely to be working in the office all the time. Where are they? How can you reach them? How will you handle device upgrades when it is difficult to physically touch the device?
Another divestiture support lesson involves autonomy. What online migration tools do you use? Will the divesting company allow you to install migration-related applications in their network? How free are you to muck around the network? Can you certify that your migration tools are virus-free? Remember, to the divesting company/network, you look like a virus or an attacker.
Roll with the Changes
Divestiture projects are big. They involve many stages and multiple consultants. Today you are handling behind-the-scenes technical changes. Tomorrow, you are asked to step up and handle rollout to end users. The constraints you originally used to scope your work can and will change. Be ready to respond!
Some Divestiture Technical Lessons
The next divestiture lesson will not shock anyone who works with technology: it’s never as straightforward as it looks. You find that components of an application aren’t there. The application does not support the more modern authentication methods you implemented elsewhere.
The divestiture lessons that are technology related change with each divestiture and set of hardware, software, and services.
Here are some challenges we ran across.
- We implemented Entra ID and its use of modern authentication, but some of the applications cannot authenticate using modern authentication methods. They require an on-premises Active Directory.
- We packaged applications with Intune and used Autopilot to push the applications to computers at the divested company. But not all the applications could be packaged with Intune. Or they could, but only the client “stub,” which would still need to go out to a licensing server to fetch the licensed modules of an application suite.
- We wanted to apply information security labels to documents and files. But first, we needed to remove the information security labels that were applied by the divesting company.
- We wanted to host applications in Azure Foundation. But some applications didn’t perform well when hosted in the cloud. We had to solve performance problems that arose because the application was originally developed with the assumption that resources would be accessed at LAN speeds.
What Gets Migrated?
In a word, everything. OK, not really. Businesses are never so cleanly organized that divesting a business unit means cleaving the assets along some prescribed line. That said, here is a list of some of the things that get migrated.
- People. Email addresses, identities, personal content, preferences, contacts, heretofore hidden applications.
- Applications. Or not. IT-installed applications. User-created applications. SaaS applications.
- Equipment. Manufacturing lines, trucks, buildings, production networks.
- Servers, firewalls, access points, printers.
- Content (data, documents, production files, etc.) Except, just the content that goes with the divested company. This entire site. That file server. That file server, except for these mapped drives.
- Service subscriptions. This is a tricky one. Does the divested company get some of the subscriptions and licenses?
- Direct Inward Dial (DID) numbers. Maybe you will migrate just the numbers attached to people and devices that are being migrated. Or maybe you will migrate the entire DID range.
Get your data security assessment for Free
I hope you get the point. I have learned a lot of divestiture lessons that I can apply to the next project. It will be interesting to see which divestiture lessons repeat and which ones are new.
