The essential checklist for a successful PLM migration

Software obsolescence, increased performance, technological innovations, better ergonomics, or new business requirements are pushing you to consider migrating your PLM to a more recent version. The stakes are high (costs, timing, organization…) and dealing with this kind of project cannot be improvised. Here’s the essential checklist for a successful PLM migration.

With about thirty migrations, accompanying our customers, editors or as an integrator, we acquired a solid experience and a 360° vision over this kind of operation. Over the years, we matured our methodology so that each migration is a success, whatever the context. We invite you to discover it!

Before starting, a quick vocabulary point. A “migration” can also be called upgrade, or version upgrade, depending on who you are talking to. Theoretically, all 3 terms imply the same thing.

In this article, we will mainly talk about major version upgrades.

What does it mean? Generally, software versions have a numbering: X.Y.Z

• X being the version number (if it changes, we are on a major upgrade)

• Y being the release number (if it changes, we are on a minor upgrade)

• Z being the patch number (we are often more on a fix than an upgrade): the theory would be that a patch doesn’t impact business/functional or technical aspects, except to make a correction.

BEFORE THE UPGRADE

The upstream phases of preparation and planning are the most important ones.

✅ Before starting your migration, focus on initiating and building the schedule, considering the technical AND the business aspects.

 Technical side :

✅ Analyze and evaluate impacts on the hosting side

For a major release upgrade, more and more publishers are pushing their customers towards SaaS or Cloud.

This can also be a good way to simplify your IS management. In any case, anticipate the impact on all aspects of connectivity and therefore security (data entry/exit from your IS) that could impact your planning

✅ Also note that PLM will not necessarily be the only one impacted.

Let’s take an example: you upgrade your PLM, however your version of Windows server is finally not compatible with your new version of PLM. You will inevitably have to upgrade your server as well. This can also be the case for your additional tools (mainly Adobe) or for the SQL part. Therefore, you must imperatively evaluate the changes to be expected by asking the editor first. Be sure to stay informed of these changes thanks to the release note, so that everything is integrated properly within the testing phases that will follow.

✅ (For an on premise version) Consider the management of your environments (DEV, UAT, Pre-Prod, Prod…) and foresee that when migrating each server, you will probably have to duplicate it (new server in parallel with the server being migrated). Finally, in this case, don’t forget to provide availability for your infrastructure / production teams, so that they can handle this phase and mitigate its impacts.

My advice 💡: for UAT, I advise you to have a UAT server, at least during the migration phase, which is identical to the production server. This will allow you to perform all your tests in real conditions.

✅ Freeze all other evolutions in progress. Migration is a complex project, don’t add extra difficulties by keeping your teams on both evolutions and migration. All the teams must stay focused on the version upgrade for more efficiency. It is essential to work with a realistic roadmap!

✅ Anticipate the impacts on the IS. Do not neglect data exchanges between tools that must be tested.

✅ Don’t neglect scalability tests. These tests ensure that the PLM will be able to continue to respond in terms of performance, and thus, often avoid very long correction times later on. Provide dry run phases with operational servers for these tests.

Business side:

Upstream of the migration, the business teams have an extremely important role to play. Indeed, during a major version upgrade, there are new functionalities, processes changes, impacts on ergonomics or on navigation in the PLM… Therefore, it is important to identify upstream from a functional point of view what is changing, even if you remain within the same scope.

✅ Include both business and technical teams in your working meetings.

Keep in mind that they are the ones who will be responsible for all aspects of the functional scope. You must work hand in hand on the content of the migration, discuss with them the new features (ergonomics, use, etc.) and maintain strong communication between the teams.

These meetings will also allow the business teams to be prepared when you call on them for the testing phases. Feel free to organize a quick meeting with them before the acceptance tests, in order to present them all the new features and thus make the testing phases more fluid.

And precisely…

✅ Prepare the acceptance tests and identify key-users. The key-users are the people you will call upon during this phase to review all the processes concerned by the migration, to write the acceptance book and the test scenarios, and to plan and organize the UAT sessions by business. You will certainly have to schedule several sessions per business with potential incidents, new test phases, etc. Often very solicited by the daily life, the collections, it is necessary to anticipate their involvement as much as possible, given the large scope that can be covered:

Don’t forget that beyond the purely business processes, you will also have to carry out integration tests with the other IS tools impacted by PLM, and in particular the ERP on style, material, color, nomenclature interfaces, etc. This is an extremely important step for a fully operational transition to production.

Thanks to all the stated elements, you are now able to estimate the actions to be carried out and the points to be piloted upstream:

✅ Define the project objectives and its scope. The objective will normally be the same for everyone: to succeed in the migration on time. The scope, on the other hand, as mentioned above, covers a much larger number of functional and technical elements to be considered. So, make sure you have the most possible global vision over all the elements and that you don’t forget anything.

✅ Identify and set aside the time needed for all the players. Consider that the publisher, even if he is involved in the implementation, will not be alone. There will also be partners, integrators, so be sure to identify all the stakeholders- with defined roles for each one of them. Don’t forget to include people who are not working full time on the project, the production teams for example. You risk of seeing your deadlines extended by lack of availability at key moments of the project.

In some cases, the editor can tell you which people you need to ask, otherwise it is up to you to identify them. If necessary, feel free to involve an external service provider to take over the daily tasks so that your key-users can focus on the migration.

✅ Define a RACI, a schedule, and delivery date. Anticipate collection periods and book realistic delivery times. You can think about a plan B if you are unsure of your times. Avoid overly optimistic schedules to anticipate test return phases, intervention times, etc.

✅ Define KPIs, communication channels and comitology.

• For your KPIs: list the functional batches, set the expectations per batch then validate and test as you go.

• Regarding the communication channels: set them up beforehand to make the communication fluid. This can be a team conversation, regular follow-up points, a ticketing tool to manage the acceptance, etc.

• Finally, for the comitology: set up, for example, a monthly project steering committee and a 10-minute daily meeting with all the stakeholders. These meetings should be included in the schedule from the start.

At this stage, if all the previous steps have been respected properly, you will be able to obtain a realistic estimation of the budget compared to the macro estimation made beforehand with the editor.

DURING THE UPGRADE

Technical side: No actions to plan. We manage the load and make sure to respect the schedule at the same time. In case of overruns / shifts, we raise alerts and readjust the schedule.

Business side: The business teams will be extremely busy during the migration. They will have to be part of UAT sessions to test all the written and identified processes, but also to quickly detect incidents and deal with them. We recommend that you use tools such as JIRA to track and assign them (either to the editor or to the key users).

It is important to hold regular follow-up meetings on these incidents to test the processes behind them once again.

Once these both steps are finalized, you will be able to proceed with the production launch or postpone it if necessary. For acceptance & UATs, feel free to use an Agile method:

✅ Train all users. Once again, it is the business teams that will be heavily involved in this phase after the migration. Most of the time, only the key users are trained, who then train the end users.

✅ Update the training materials with the new software version. This phase is critical because when all the users will work with the new version, everything must be perfectly square.

✅ Take your users along the change management: you need to make sure that you don’t lose anyone along the way, that everyone has embarked on this new version with you. You need to track the skill development of your teams and evaluate the adoption of this new version to readjust if necessary.

✅ Do not neglect the handover phase. This phase consists in facilitating the transition between the project team and the run team (which is different most of the time) and is divided into 3 phases:

• Sharing the release notes: communicating on the elements that have changed and raising questions upstream

• Train the run teams on all aspects that have changed

• Maintain the availability of the project team during the post-release phase. For example, during the two weeks following the migration, make sure that someone from the project team can come and reinforce the run teams if necessary.

✅ Perform a sanity check during production launch.

• Define non-regression tests that will be replayed after the migration

• Make sure a business contact is available during the delivery weekend.

The idea is to select some non-regression tests that will be defined as priorities (for example: logging in, browsing the product list, creating a bill of materials, etc.) and have them tested during the migration weekend. The objective is to make sure that the major functionalities are up and running at the time of the startup on Monday morning.

To sum up:

• Upstream, make sure you have control of all the technical impacts and the integration of the business teams

• Schedule the UAT and testing phases

• Invest time in training and post migration support

• Don’t forget the handover and the sanity check!