Migrating platforms; out with the old, in with the new!
A CTO friend of mine asked for my advice today on a topic I spent roughly a year immersed in during my stint at AOL. He's a faced with moving a large IT/engineering organization off of an old "legacy" platform and infrastructure, over to a new way of doing.
The legacy solution is rooted in 20+ year old thinking, formats, and standards. His solution is a modern SaaS model, using modern standards (HTTP, XML, etc). The technical details aren't important. He was concerned with the cultural shift necessary to move from A to B.
Along with a few colleagues, I was charged with moving AOL's proprietary infrastructure (20+ years old) over to new web standards based methodologies and technologies. For those AOLers reading this, I'm talking about the move from FDO/Bucky Ball/SAPI/FLAP to HTTP/HTML/JS/CSS/XML/REST. It was difficult. I'll try to avoid the technical detail rat-holes; they're actually fun to get into, but are best left to whitepapers or conversation.
Culturally, the "old" team were technical leaders at AOL. They are indeed genius and nailed more interesting technical challenges than today's lazy, in-efficient, web based models. They built a real-time publishing infrastructure that scaled to literally millions of simultaneous open sockets, all over 300 baud modems, and delivered live content to millions of customers. Today's web wouldn't stand a chance on connection speeds like that.
We tried the technical superiority approach to dethrone the wise men. No dice; they were smarter than us. We took the moral evolutionary high-ground, "the entire space has evolved, and we need to keep pace with the industry," and generally won that point. However, an interesting thing happened. We severely underestimated the loyalty engineers can maintain to technologies. When faced with job-loss due to necessary adaptation to something new, more folks threw themselves on the sword and quit, rather than conform to new stuff, than we expected.
When we couldn't convince everyone to "switch," we had to report back to management that our efforts were having limited impact. We had easily convinced upper management of the necessity in making the change early in the process; they, rightfully, swallowed hook line and sinker. Management's response was to simply layoff swaths of "old schoolers" to make way for the new thinking, and illustrate how serious they were at making the shift.
The end result was a complete shift from A to B; it was successful in the end.
My advice to anyone facing these kinds of, large (small teams are different), changes is to rip the band aid off. Attrition will happen. People marry themselves to specific solutions and simply don't want to change. Parting ways with them early, rather than wasting weeks/months trying to convince them, will save you much heart/head ache.
Recommended steps:
- Clarify, with necessary management support, what switch is occurring.
- Offer training/education on the "new" to everyone impacted.
- Sit down with the folks who didn't attend training, and either let them go, or find them completely new roles in the company. They're not on board. Don't waste your time.
- Start the transition.
- Enjoy having transitioned, and knowing you avoided much pain and suffering (for all parties involved).