Software migrations are like a divorce

Moving to another enterprise software stack is like a divorce:

  • it costs a lot of money
  • It never goes as planned
  • There will be a lot of yelling and name calling
  • It’s an emotional rollercoaster
  • Having to move out into a new “stack” is scary
  • Once it’s completed you feel great

And if you decide not to “divorce” you:

  • You will be miserable
  • There will be a lot of yelling and name calling
  • You won’t get to try out new things
  • Your users will continue to be miserable
  • You only live once
Advertisements

Comments

  1. I’m not sure I get what you’re trying to say here. On the surface this seems easy to agree with but on reading it deeper you’re basically saying that if you’re even considering a migration then you might as well migrate. It sounds like “Heads I win, Tails you lose”.

    You have one condition here; migrate or be miserable. Complete your migration and you’ll feel great. It’s all “emotion” based.

    I’d rather hear about ways to evaluate and make good informed decisions when dealing with a potential migration. Regardless of platform, there have to be some cases when a migration doesn’t make sense.

    Just my 2 cents.

  2. its very easy to say Bye Bye IBM.

  3. Great Point Bruce. Here are my thoughts. When any organization is considering a platform migration, the underlying reason must be understood. Having been a “Yellow” person for a VERY long time, I have seen the massive transformation of companies (yes a lot of them) move from a Domino based platform to a Microsoft one. Why is this?

    What drives the executive level staff of an organization to consider a move, whether it be Messaging, ERP, functional systems, to something new? There are dozens of motivations for this. It could be a lack of functional necessities of the existing system; it could be that the financial costs associated with licensing are exuberant; it could be that human cost of managing it in house are much to high.

    Here is a pertinent example. For a very long time, IBM and Lotus Notes/Domino was the platform to move to. Be it ccMail, Groupwise, Exchange, IMAP, Lotus Notes offered so much more than just a messaging platform. The whole idea of Lotus was so fantastic that IBM wanted that piece of the pie. For a few years IBM left Lotus alone to be a stand alone part of the business. Next they were transformed from “Yellow” to “Blue” and that started the demise of Domino.

    When Lotus managed it’s own sales staff, they knew how to sell this platform and knew how to position messaging coupled with Rapid Application Development. Once IBM acquired and started to sell Lotus/Domino, well the sales staff were not solely focused on messaging. If I can’t replace the ERP with a new iSeries AS/400, the Windows servers with AIX servers, why would I pursue a messaging only sale? From a cost of sales perspective, messaging alone is not profitable.

    Microsoft saw this and they honestly embraced this. Microsoft has managed to swing almost all of the Banking industry to move to Exchange. Microsoft launched BPOS and subsequently Office 365 to provide Messaging as a service. IBM tried to follow with Smart Cloud, however having seen both, and what can be done from a customer perspective, I have a whole more control as an Exchange Admin on Office 365 than I do as a Domino Admin with IBM Smart Cloud. This is a practical example. Office 365 gives me almost full control of the user objects in the cloud to manage, service, fix, and control my messaging system than I can ever hope to have with IBM Smart Cloud.

    Much discussion has surrounded this on both sides of the messaging world. From the standpoint of which system is better than the other, it doesn’t matter from a technical standpoint. What truly makes the determination of which way organizations move their Enterprise Systems to, comes from business decisions. Companies are in the business of making money. The more of the underlying services that IT today provides that can be paid for as a service, in the long run will save the organization money.

    SAAS is the buzz word now. The service providers have been able to provide online cloud based systems that are secure, powerful, and can be accessed from virtually anywhere in the world, from any devices. Why as a business owner would I want to incur the costs of equipment, licensing, servicing, and support when I an pay an organization a fixed fee per user for these services?

    So to the basis of this posting, Migrate or Not Migrate. Which should it be? It comes down to individual organizations.

    Migrating does cost a lot of money yes. Can you do it yourself? Sure, but the time and costs associated with training, understanding, lack of experience in the process, (not to mention the ramp up time) will be much more expensive in the long run than having experienced people do it.

    Migrations never go as planned. This is true. Why would this be the case? Even professionals who execute migrations on a daily basis, find new and unexpected issues in most migrations. Why? Your best practices and standards will be different than the next company down the street doing the same thing you do.

    There will be a lot of name calling and yelling. Why most of the time the people who want to migrate have an expectation of what they think should happen and what actually can happen. Setting these expectations up front can help minimize this.

    It is an emotional roller coaster. Yes it is! Human nature does not like change. This is the case from our basic emotions. From a business perspective it is further compounded. What are the roll back options if there is a problem? What are our contingency plans? What happens to the end users?

    Having to move to a “new stack” is scary. Obviously. We fear the unknown.

    Once it is done you will be happy. Yes you will. With the right people executing the migration, people with expertise, the issues encountered by the uniqueness of your organization can be addressed quickly, thereby minimizing the risk and expediting the project completion. The underlying reasons for considering the migration are gone and the perceived benefits to executing it are exposed.

    As for the reason not to divorce, well consider this:

    You will be miserable. If you were unhappy with your initial situation to the point that you have considered it enough to research and deciding to migrate or not, you are still in the same situation you were prior to this exercise. You will still have the same initial concerns that you had.

    There will be a lot of name calling and yelling. Yes this will still happen. Some people do embrace change. Some people will be resentful that the organization did not move forward with the plan and may feel resentful.

    You won’t get to try new things. Well remember when dealing with production systems, we NEVER, EVER execute upgrades to production boxes. We need to test first. That requires test platforms, which require hardware which requires money, which cuts profits. And we may be out of “maintenance” on our software which will would need to “true up” to get the upgrade in the first place.

    Your users will be miserable. When organizations do not upgrade, the users do not get to use new features. The users may hear of things from friends, family and wonder why their own company cannot do these things. I personally have seen this when former coworkers of mine regularly email me with questions regarding the fact that they have moved companies and are on older versions. How can I do this in version XXX when you are on XXXX?

    You only live once. Be the person responsible for the systems and you with either be the hero or the villain. There is no middle ground.

  4. So Perry and Bruce, your real world analogy is that we should all have repeating mid life crises whereupon we become enthusiastic and invested in something other than you already have ( from the last crisis ) rather than enrich what we have to its best potential ( assuming that potential is enough )

    I often see Industrial Engineers who get great praise for fighting fires rather than preventing fires. Putting out fires rather than preventing them doesn’t make them good Engineers from a business perspective. Maybe the same should be said of CIOs who are keen to impress.

    IBM is responsible for a great deal of the demise of Notes ( the obsessional focus on only supporting “net new sales” being key in my mind ) but as good as SharePoint is people still seem to be left with Domino servers running for long periods after the migration has been declared a resounding success.

    I would love to have been a fly on the wall during the IBM and MS conversations with these CIOs. It must have been fascinating. It is becoming increasingly academic as time goes on but what the hell went wrong ? I hope someone writes a book with balanced perspectives from both sides because I am baffled.

  5. In the spirit of openness I should admit that I have had a mid life crisis and have invested myself in a particularly elegant model – http://seancull.co.uk/wp-content/uploads/2015/11/2015-11-29_19-31-33.jpg

    • Sean I too have undergone a mid-life crisis. IT is not the business it used to be. When I got into the Notes World myself over 18 years ago I was not a fire fighter. I was a fire marshal. I prevented fires. I made sure that things worked well, went smooth and had time to find fires before they got out of hand. Over time, I saw that as the times got lean, staff was reduced. I ended my Domino Admin career as a fire fighter. Time being the difference. IT got too expensive and staff levels were significantly reduced. No time now to prevent fires but only time to react. This is where it all went wrong.

      My midlife crisis, well I have a new love: http://www.hiltzybbq.com I’ve gone into making award winning BBQ and entering competitions.

      • You had me at “award winning BBQ” but the link failed. Is it http://www.hiltzysbbq.com/ ?

        As for migrations….I’m in the home stretch (yeah…right) of an Amazon subsidiary migration onto an Amazon internal stack. Same as enterprise…except it’s mostly OSS and internally built stuff…not vendorware. But migrations are hairy beasts, wherever they live.

  6. Yessir. That is it!

%d bloggers like this: