Software upgrades is a fascinating topic. It has been with us from a very early beginning of software. Seriously, we hate upgrades. On the other side, very often, this is the only way to make a progress. The main problem of upgrades is related to existing dependencies – migration of data, file formats and data incompatibilities, hardware incompatibilities, etc.
As software is getting more complex, the complexity of upgrades are increasing. Enterprise software is a very good example. Talk to people about ERP, PLM and other enterprise software upgrades and you can learn a lot about effort and cost of upgrades for an organization.
For a long time, enterprise software upgrades were considered as something inevitable. Which led to many problems for customers. One of the extreme situation is when a specific configuration of a system becomes non-upgradable. It is known as “version lock-in”. Most typical reasons – features and customization incompatibility between new software version and the one customer is still running. As much as customers are discovering the complexity of upgrades, we can see software vendors are trying to leverage it to demostrate their differentiation.
For last few years, I can see an increased focus of PLM vendors around “upgrade and migration”. My hunch, too many customers stuck in previous versions of PLM software or outdated PLM systems. Random PLM (future) thoughts article by Jos Voskuil speaks about PLM systems upgrades complexity. Read the following passage:
Not every upgrade is the same! Where consumer software will be used by millions and tested through long Alfa and beta cycles, PLM software often comes to the market in what you could consider a beta stage with limited testing. Most PLM vendors invest a lot of their revenue in providing new functionality and technology based on their high-end customer demands. They do not have the time and budget to invest in the details of the solution; for this reason PLM solutions will remain a kind of framework. In addition, when a solution is not 100 % complete there will be an adaptation from the customer, making upgrades later, not 100 percent guaranteed or compatible. More details on PLM Upgrades after the conference, let’s look into the near future.
I think, the overall trend in quality of enterprise software is positive. Consumer software mentioned by Jos is only one factor why enterprise software vendors are investing more in quality. Jos’ article made me think more about how customers should approach the topic of PLM migrations and upgrades. In general, I think, it can be applicable not only to PLM systems. PLM vendors are trying to make migrations easy from both economical and technological standpoints. Here are some of my thoughts about anatomy of PLM software migration.
Migration technologies
While some technologies can give you an advantage during migration and upgrades, from a technical standpoint you cannot avoid upgrades. Very simple – from time to time you need to restructure database to bring new features or optimize for performance. Since PLM is relying on OS and database technologies, you need to get upgrades to bring PLM system into compatible state with new OS/RDBMS. If you PDM/PLM system is integrated with other CAD systems, this is another aspect of migrations.
From technological perspective, migration is always sort of extract, transfer, load type of things. It can be minor or major. It can happen in a single database or may require a separate set of application or database servers. PLM system architecture designed with “upgrade in mind” can make it easier, but won’t eliminate it completely.
PLM vendors and economic of migration
PLM vendors are starting to pay attention to migration and upgrades. While the status of PLM systems is far from an ideal when it comes to migration, some vendors are proposing to cover upgrades and migrations as part of PLM service and licensing offerings.
SaaS (cloud) is providing another way to hide migration and upgrades. Since customer is not buying software to install it in their data centers, the problem of migrations and upgrades eventually is part of PLM vendor responsibility.
Technical elements of migration
There are 3 main elements that can increase PLM system vulnerability to upgrades and migrations – 1/ custom data model; 2/ code customization and scripting; 3/ integration with other system. The amount of specialization in each of them, can increase a potential cost and complexity of migration.
What is my conclusion? You cannot avoid migrations and upgrades. So, to plan ahead is a good idea. You should evaluate vendor and product for “updatability”. It is not simple, especially when it comes to on-premise software. Product architecture evaluation should be an important element of your system selection process. If you think about SaaS /cloud as a universal solution for upgrades and migration, I recommend you to take it carefully as well. It certainly removes a pain from a customer. However, take into account it won’t eliminate upgrades from technological standpoint. Upgrades are essential part of SaaS product development. Depends on SaaS architecture and development methodology, the system can be in an upgrade mode all the time. Which is a good thing because it will be become part of product delivery. Just my thoughts…
Best, Oleg
