Moving the 3DEXPERIENCE platform to the cloud in SaaS mode is now a serious option for manufacturers. The benefits are clear: lower ownership costs, fewer painful data migrations, and access to new data and AI features. But the journey is not always straightforward. Five major obstacles still stand in the way, according to Martin Kraus, CIMPA PLM Services' Deputy CEO, and Bruno Puechoultres, Partner, PLM Consulting, who have led migration programmes to the 3DEXPERIENCE SaaS PLM platform at Sopra Steria-CIMPA for the past six years.
PLM migration to the cloud began quietly around a decade ago among start-ups and SMEs with no existing PLM system. Today, even the largest industrial companies are considering shifting their PLM programmes to the cloud.
Dassault Systèmes has made this direction its own: since 2024, all new roles on the 3DEXPERIENCE platform have been delivered primarily and in some cases exclusively in SaaS mode.
Migrating a PLM system to the cloud, however, is not simply a matter of changing hosting arrangements. It represents a strategic shift affecting integration models, project methodologies, the three-pronged relationship between industrial company, software publisher and systems integrator, and the day-to-day work of operational teams.
Sopra Steria, recognised by Dassault Systèmes as "Best in class integrator for go-to SaaS", has been supporting these transformations since 2020, with its first production deployment completed in 2021.
Six years of experience and eight projects has revealed one truth the gains are real, but a migration of this scale resembles a hurdles race in which each obstacle must be cleared at the right pace and in the right order.
Why industrial groups are moving to the cloud
Three motivations underpin migration decisions. The first is economic. This is the promise of a lower total cost of ownership over the long term compared with the cost of "on-premise" PLM systems in licences, infrastructure, integrated solution development and maintenance.
Martin Kraus, Deputy CEO of CIMPA PLM Services, has seen the impact on clients that have already made the move. "They no longer ask themselves about the cost of their next migration; the issue has disappeared from their day-to-day operations," he says.
The second motivation is to accelerate deployment: this means setting up a cloud infrastructure made up of several "tenants", working iteratively with business teams to avoid costly bespoke developments over the long term, and extending usage beyond the company's own walls.
The third is helping to manage outdated systems. Rather than financing yet another expensive migration from one on-premise version to another, companies move to a solution operated by the software publisher and free themselves from the risk of obsolescence.
Added to these drivers is a more recent but decisive factor. New-generation functionalities centred on data and artificial intelligence will increasingly only be available in SaaS mode. Analytical layers capable of aggregating information from PLM, ERP or maintenance systems, and then feeding it back to engineering teams to guide design decisions, require computing power and development cycles that only the cloud can manage.
The move to the cloud first took hold among companies with no PLM legacy so-called "greenfield" projects. Now large companies operating systems installed decades ago, with extensive data estates containing critical intellectual property, are making the move. This is where complexity intensifies and where the hurdles metaphor becomes particularly apt.
Hurdle 1: The out-of-the-box shock
SaaS requires companies to work much closer to the publisher's standard offering. Large bespoke developments, fully customised screens and workflows tailored to every team are largely over.
This "out-of-the-box" (OOTB) approach is viewed favourably by management because it stabilises costs and secures version upgrades. For operational teams, however, it is a very different matter, says Bruno Puechoultres, Partner at PLM Consulting. "There is a contrast between the value perceived by decision-makers and the experience of teams on the ground. Previously, everyone customised the system to match precisely the way they worked. Now people must agree to de-customise. It is not so straightforward."
The challenge is as much human as technical. It requires a change-management effort from the scoping phase onwards in order to align business practices around a common foundation. Without this, the cloud solution risks rejection before deployment even begins. It also requires a project methodology specifically adapted to this challenge, in which change management is considered throughout the implementation process.
Hurdle 2: Relearning integration and security
A standalone PLM system is of limited value. To generate value, it must interact with ERP, CRM, manufacturing execution systems (MES) and Maintenance, Repair and Overhaul (MRO) systems. In a SaaS cloud environment, however, these integrations are no longer built as they once were. The development tools of historical on-premise versions have given way to APIs and web services that integrators can no longer bypass.
For project teams, the frame of reference has changed. "Integrators have lost the benchmarks that once allowed them to move quickly," says Puechoultres. Established methodologies no longer apply directly, while the available toolsets are sometimes newer and more constrained.
This is where accumulated experience becomes decisive and where the maturity of the integrator truly matters. "To address this, we invest heavily in knowledge bases for our consultants and developers, as well as reusable technical assets across projects," he adds.
Hurdle 3: migrating the data estate
Migrating the data estate is perhaps the obstacle most feared by large industrial companies. Their PLM systems contain decades of models, bills of materials and technical data of varying quality and with semantics that have evolved over time.
Moving these into the 3DEXPERIENCE SaaS solution requires not only mastery of new import tools, but also transformation of the data itself so that it fits the target structure and enables optimal use within the new business environment.
Kraus is currently leading two major migrations of this type. The complexity, he says, is twofold: "Technical, because the right tools are needed to move from on-premise to cloud; and semantic, because historical data must be transformed into a new structure."
Migrating to the cloud takes longer than migrating locally the cloud does not open with a single click. The most mature companies begin by using SaaS for new products a so-called "greenfield" transition that allows them to test the target data model before addressing the existing estate. In most cases, this gradual approach is a crucial condition for a sustainable transition.
Hurdle 4: Managing a three-way game
In the on-premise world, the division of responsibilities was clear. The publisher delivered the solution, the integrator installed, customised and integrated it into the broader IT system and the client operated it.
In the SaaS cloud environment, this balance changes significantly. The publisher becomes the operator. It delivers the cloud tenants, sets the pace for version upgrades and determines the timetable for new functionalities. "It is a three-way game, not a two-way one," says Kraus.
The consequences are tangible. Clients no longer choose the timing of updates they arrive and organisations must be ready to use new functionalities as soon as they become available. Alignment between the publisher's services, those of the integrator and the client's teams becomes fundamental. "This trio requires renewed governance and a revisited RACI model," says Puechoultres. Above all it requires a relationship of trust built over time.
It is this model of close collaboration that Sopra Steria has co-developed with Dassault Systèmes teams across several programmes, using varying engagement models including co-development, publisher support and integrator-led management, depending on the phase.
Hurdle 5: Choosing the right route
No PLM cloud migration resembles another. Depending on the client context, the data estate involved, programme criticality and team maturity, several paths to migration are possible. Sopra Steria-CIMPA has identified and tested a number of them, each with its own stages, checkpoints and risks.
The common principle, however, remains the same never attempt to clear all five hurdles simultaneously. Address OOTB on one side, IT integration on another, conduct data migration in parallel on a limited ranger, and progressively establish threeway governance. More than any specific tool, it is this sequencing that distinguishes a migration that fulfils its promises from one that becomes bogged down.
Puechoultres illustrates the point with a metaphor. "When you go into the mountains, you do not cross five mountain passes at once. You tackle them one after another, rest in between and choose your route," he says.
"Our value as an integrator today lies in having already tested several paths, and in knowing how to choose the one suited to the client rather than imposing a supposedly ideal route."
Expertise built through experience
Since 2019, Sopra Steria has delivered the first 3DEXPERIENCE SaaS deployments into production, notably in the rail sector and is today leading several major implementations and migrations for companies in the fields of aerospace, defence and transport.
Through its subsidiary CIMPA and its 1,600 employees dedicated to PLM working alongside the industrial vertical structures of the Sopra Steria group the company deploys industrial-scale capabilities across seven countries to support these programmes.
This accumulated experience has resulted in a portfolio of methodological assets, migration assets and documented integration feedback. It is this experience dimension that Dassault Systèmes acknowledges in positioning Sopra Steria as "Best in class integrator for the go-to SaaS strategy". The status is not an end point, but recognition of an advantage that has been built project by project, hurdle by hurdle, and one that requires continuous improvement.