Why The Product Migration/Upgrade is very challenging exercise for Every Organization

With Latest Mobile technology you could upgrade your IPhone Operating system or any app almost instantly, But why an enterprise   application/product migration/upgrade projects takes years  to complete and lots  those projects fail before reaching finish line. 

What’s the difference?  The most obvious reason is typically the corporate applications are lot more complicated and carry lot more risk with incorrect upgrade or failure. The risks are even more if it is involves a business operations involving customer data.    With the SAS (software as service) model does this makes it easy for organizations to manage/Upgrade much more efficiently. Before we make the decision, let’s look the reasons and complexity of Product upgrades.

Enterprises typically built their own software or purchase it from software product development companies like IBM, Microsoft, oracle and many more. Some of the Enterprises will provide Software Product/Services to their business customers  it could be likes of Sales Force, Workday ,QuickBooks online and many more. In all these scenarios typical product implementation goes thru following patterns

 Every enterprise has somewhat unique business process and business needs that application fulfills. Typical commercial application has configuration features where either Product implementation team or System Integrators will do configuration work. On top of the enterprise go ahead and do more product customization specific to their needs which could even involve tinkering the code of specific components. As you could also see that a product might become integral part of the business operation where data/information is exchanged with many other application/products within the organization. That’s bring the complexity and fear of something going wrong. Even small change in a product might impact somewhere in downstream and could hurt the business outcome. On top of it goes across multiple business units/departments  so each of them might look  product from vary different  context.

Here is the some of the Important reasons for any Product Migration will get in to challenging:

1.   Product development ,Product Sales and Product Implementation teams are not always on same page and will pull  product road map in  different directions:

 Product development team looks the industry trends, what competition doing and try to build the features  (Many times irrespective of current customer demands).

Product Sales team goal will be selling the product and would push lots of Ad-hoc requests for customization of the product for it to go thru. Depends on the size of the customer they are pursuing , the noise they can make, the influence they have on product company  the product company goes with specific customizations to impress the client.  So Product upgrade will have challenges to these customizations where they might not incorporated back in to the product.

Product Implementation team will also similarly use their creativity in the product configuration to fit customer specific business needs, even they are not direct fit for the product they are using. Data /Feature over loading to take care of the customer current problem in hand only make it bigger unmanageable problem at upgrade time. Also this is just configuration so it is seldom documented with very little trace left behind until totally different problem presented to customer at the time of product upgrade. Many of these hacks done by Implementation teams never reach product developers as needed new features. so they very rarely show up in product development roadmap.

                   So every time a Product releases a new version, these configuration(s) and customization(s) will potentially become road blocks to upgrade. Discovering the problem, finding solutions (one more round of Band-Aid fix thru configurations and customizations) will take lot of time and resources. Take a look of your last ERP/CRM upgrade, how rarely you hear it went smoothly?.

2.   Product upgrade sometimes drastically change its Architecture 

With ever changing nature of current marketplace and technological innovations, Products want to stay above the curve and provide new and fancy features to customers. While implementing these new features leads to drastic changes to existing product architect and discontinuing old features and services.  With the change of architecture all the plumbing between applications need to be changed leads to lots of rework and changes to many other applications in echo system.  Again that’s add Time cost and resources.

3.   The Fear of the change and lack of understanding the impact

With vary matrix nature of the current corporate world but where common thread of applications/data ties them together, there is always fear of change scares every organization. It is very hard to evaluate the change and what could be impact in the organization.   Even a small change  in echo system could have big impact in lot of places, so that fear force organizations to spend lot of time to evaluate and test every possible way  to reduce the risk before getting on to new product release.  If we look around we see companies still using  Internet Explorer version 8 as enterprise standard and not allowing to upgrade to latest version for the fear of some applications are not going to work and ready to hold on to a version of more than three years old. There is a telecom company still using their green screens to provision the land lines, just because they are not able to get the applications to latest technology.  Lotus notes survived as email engine for more than 20 years even it became outdated for same reason and there are companies still hold on it.

4.   The Testing cycles takes for ever

In most organizations given the intricacies about the usage of product or its produced data, the organization really want to be sure that the  upgrade is not negatively impacting any of its current business usage. For that reasons there will be enormous effort is spent on thoroughly testing the upgrade with all the scenarios. Even after that still try to keep both versions ran in parallel for months until every corner of the enterprise build confidence of the upgrade. Sometimes even a small impact could also push back the upgrade to start over again.

          Here are some of the main reasons for product migrations/upgrades takes forever to complete. Now  if we take SAS(Software as Service) model does it  makes any Better?.

          Many Product companies selling their product as SAS model by just installing the product on a Private cloud. But product is still the same and going thru same versions/releases.  I don’t think there will be much change still it depends on how strongly it is connected and integrated with in the enterprise. There is also additional challenges comes when in SAS model with multi-tenant environment (Many customers/companies using the same application) as all of them need to be ready to migrate to new version of the application or  the application should able to run multiple version(s) in same instance.