Moving Your PLM to SaaS Shouldn’t Be Painful. So, Why is It?

Let’s start by saying something many PLM professionals and end users may dread hearing: sooner or later, you will need to move your PLM solution to the cloud and maybe even into a SaaS deployment. Of course, moving to the cloud is not a bad thing. In actuality, it may be today’s most important strategy to prepare your PLM for the unknown demands of tomorrow’s product complexity. See my blog “De-risking Your PLM Should be Your Number One Priority” for further discussion on this point.

So why the conflict? Experienced PLM experts know the ugly truth–nobody wants to make major changes to their PLM system. Seriously, nobody. If it’s working, don’t touch it!

The core of the issue that caused this conundrum is that most large-scale PLM solutions were designed and built decades ago without the capabilities for customers to build the organization’s specific business logic into the system. These systems are large and complex and, aside from some built-in configurability, were not designed to support customer requirements outside the solution provider’s code base. The assumption was that the out-of-the-box (OOTB) functionality would suffice, and customers would adapt.

Customizing your PLM, the gift that keeps on giving

Unfortunately for PLM providers, customers had their own perspective on the importance of using their specific business logic over the vendor’s OOTB functionality. Something needed to be done as business requirements changed too quickly for large PLM solutions to keep up with customers’ new requirements. This situation led users to customize the system any way they could—and they did just that. They customized, customized, and then customized some more, creating new levels of complexity in the system along with new processes and coding issues in their deployment.

With each new release, it seemed that for every issue the IT organization fixed, two more were created. This left the organization in a perilous state—the effort and cost to upgrade to the provider’s latest version increased significantly, limiting the customer’s ability to take advantage of new OOTB capabilities. See the CIMdata publication “Deferred PLM Modernization Delays Time to Value” for an excellent analysis of this point.

Moving PLM to the cloud and SaaS is inevitable

While companies may not want to initiate a major change to their PLM environment, the momentum of moving to the cloud has become too strong to ignore. (See my blog “The Unstoppable Momentum of PLM SaaS” for more on this topic). At this point, there are just too many transformational initiatives that require not just today’s digital product data but a rapidly growing level of product data detail and its associated data from nearly every system across the organization. These initiatives will require a robust digital thread to drive their digital twins, digital engineering strategy, and AI efforts. They will even help satisfy new, complex compliance efforts like the EU Digital Product Passport. Companies now require higher flexibility, scalability, and security levels to navigate these efforts successfully. The earlier they move their PLM to the cloud, the further ahead they will be in all of these efforts.

Watch the webinar “Let Business Value Drive Cloud PLM Transition,” in which Jim Brown, president of Tech-Clarity, and I discuss how to align your SaaS PLM strategy with your business objectives and drive maximum value from your cloud solution.

No pain, no gain – 3 pain points and how Aras avoids them

So why does moving your PLM to the cloud and SaaS hurt so much? Shouldn’t this be easy? Can we go back to Excel? Seriously.

For the purposes of this conversation, I will focus on migrating a customer’s on-premises (or perhaps a company using IaaS) to their software provider’s SaaS solution on the cloud. Theoretically, one might assume that migrating a software solution between two deployment methodologies would not be too painful. Before starting your cloud or SaaS migration, here are several points to consider.

1. Customization and De-customizations – We discussed customizations earlier, and this tends to create the most pain for a migration (other than potentially the data migration, which I will not include here since that is not unique to cloud migration.) So much pain that many PLM vendors have given up on the idea of allowing any customizations with their new SaaS offering. So, what happens to the existing customizations? The software providers have simply introduced the idea of de-customization. For some reason, these vendors feel the customizations their customers spent substantial time and money on over the past years are no longer necessary. Hypothetically, the functionality will be available in a newer version that they could not upgrade to previously, but perhaps not. Some potential impacts of de-customization include the introduction of new and increasingly more complex business processes, which will increase process time, additional change management and training when introducing the new SaaS deployment, and the risk of lower user engagement and satisfaction with the system. Nobody likes an unhappy user.

What’s gained for Aras customers: When a PLM platform provides the same customization capabilities of their on-premises solution in their SaaS offering, the organization can keep the investments they have made to their system without disrupting the organization. Additionally, they can continue investing in building company-specific functionality to grow the value of their PLM in the future.

See my blog “PLM Customizations and De-customizations: How SaaS is Changing the Future of PLM” for a more detailed discussion on de-customizations.

2. Upgrading from an old software version – In the analyst report “Deferred PLM Modernization Delays Time to Value,” CIMdata concluded there was an average upgrade time of 11 to 14 months for three of the largest PLM solutions. The survey also stated that only 32% of PLM users from the same three large PLM vendors had upgraded their solutions in the past two years. That leaves a lot of PLM solutions running on old versions in the field. This means when a customer is ready to move to SaaS, the first thing that needs to happen is to pay for their past “offenses” of neglecting their PLM upgrades. They must upgrade the system to the latest version, which can mean jumping several versions at once. Of course, this process will also include de-customizing the system. In other words, before the move to SaaS can even start, the vendor and customer have a tremendous amount of work to execute.

What’s gained for Aras customers: The same CIMdata report reported that 71% of Aras customers have upgraded their system within the last two years. Since most Aras customers start their SaaS journey from an up-to-date software version, the process initiates quicker and with a head start to the finish line.

3. Tracking down tribal knowledge – Remember when I said if it’s not broken, don’t touch it? Once the migration begins, there is detailed technical information about the current state that is necessary to create the new, cloud environment, especially when dealing with old integrations. These legacy integrations need to work the same way as the on prem deployment and in many cases, this information is not well documented leaving the IT department to start calling around, even to the guy who retired three years ago.

What’s gained for Aras customers: Well, there is no way around fact that missing critical tribal knowledge is one of the main reasons a migration to SaaS may be delayed. The silver lining to the issue is once the information is gathered, the critical data is formally documented as part of the implementation and never lost again. No need to ever bother that retired programmer who built the integration a decade ago again.

Aras Innovator SaaS – a painless migration

For those fortunate enough to be on Aras Innovator®, migrating to Aras Innovator SaaS is a relatively painless process, and customers have realized this. In a recent announcement, Aras saw a 50% growth in SaaS deployments of Aras Innovator, with many existing on-prem customers deploying SaaS. The not-so-secret reason for Aras’ success is that Aras Innovator SaaS has the same ability to customize as the on-prem standard subscription. This allows customers to retain all of their customizations following their SaaS migration.

Additionally, since Aras has always included and executed customers’ upgrades as part of the subscription cost, existing customers have never fallen behind. CIMdata’s report stated that nearly half of Aras users had been upgraded in the last six months, and the average upgrade only took three months.

For more information on Aras SaaS migration, read CIMdata’s newest commentary, “Migrating to Aras Innovator SaaS.”

Another great resource to review is Tech-Clarity’s white paper “Achieving the Business Value of Cloud PLM.”