IT or software migrations are business as usual for companies. Old platforms retire, and businesses have to shift to newer, more advanced options. However, they are never easy, both technically and culturally. Agile PLM users are well aware that time is upon them as the veteran PLM platform will reach its end-of-life on 31 December 2027.
The lift and shift strategy makes data migration a lot less intimidating. Data migration services use it to move an entire application from one environment to another with minimal changes. Lift and shift is pretty much like hiring a moving company when you’re switching homes. Just pick all your stuff and place it somewhere else.
In this blog, we’ll explain how you can lift and shift from Agile PLM to modern PLM platforms easily and quickly before the deadline.
What’s next for Oracle Agile PLM users?
Oracle Agile PLM has been a foundational system for manufacturing complex products. For over two decades, it remained the #1 PLM software for managing product data and engineering change. But it’s time is coming to an end as Oracle has decided to retire the platform. 9.3.6 is the last version, and support for the product will end next year.
Therefore, for Agile users, a pivot to modern PLM platforms is critical. Sticking with Agile poses security risks, and it no longer fits its name as an “agile” platform. It will slow down your workflows to your own detriment.
So, what is the next step for Agile users? That depends on your needs, but Aras Innovator and Propel are two great platforms to carry on your PLM journey. They incorporate the strengths of Agile and also offer advanced cloud capabilities that you won’t find in the legacy platform.
But you need a data migration strategy, like lift and shift, to properly transfer all your data from Agile to these platforms without any loss or damage.
What is lift-and-shift migration?
Lift and shift is a data migration strategy where an exact copy of an application is moved from one IT environment to another. Usually, it is from an on-premises setup to cloud platforms.
It is also called rehosting and is often the fastest way to move to the cloud because it takes less time than rebuilding everything. Concomitantly, lift and shift also requires less labor and cost than other data migration options.
In practice that means:
- Minimal code changes
- Preserve existing architecture
- Rehost workloads as-is
Lift and shift is a popular choice for large-scale migrations. Its beauty is in its simplicity while dealing with a web of interdependencies and data sources. However, keep in mind that it is not the best default choice for every application.
Ideally, lift and shift works best when the workload is already fairly compatible with the cloud, such as containers or microservices. You can also use it as a temporary first move, where you migrate the application now and improve or redesign it later in the cloud.
Using lift and shift for Agile PLM migration
Some people don’t think lift and shift is the right approach for PLM migration. And to be honest, they have valid concerns. However, they are only true for some PLM migrations. Its success or failure depends largely on your objectives and source data.
PLM data migration risks of lift and shift
The first thing you need to know about PLM data is that it is very messy. Everything related to product development is built around data. You have suppliers, parts, revisions, BOMs, documents, and a ton of other things interconnected.
Therefore, PLM data migration cannot happen in isolation. If these dependencies are damaged or broken during migration, the product structure won’t work in your intended PLM software.
Now, newer PLM systems often expect or demand cleaner, more standardized data. This at first makes lift and shift challenging for PLM migration because moving data “as is” creates some problems:
- Data fails to load because it does not meet the target system’s rules
- It loads in a poor-quality form that makes it hard to trust or use
Making lift and shift work for PLM platforms
You can’t just dismiss lift and shift for PLM data migration because of these risks. These are operational roadblocks that can be resolved with the right approach. Lift and shift works great for PLM migrations if it is moved with enough cleansing, standardization, and validation to make it usable in the new system.
Here’s how we approach lift and shift for Agile PLM migration:
1. Data quality is paramount
If your legacy PLM data is inconsistent, the root problem is the data quality, not lift and shift by itself. A lift-and-shift approach can still succeed when you ensure these things are accounted for:
- The source PLM instance already has strong governance
- Required attributes are mostly populated
- Classifications are controlled
- The target system is configured to accept equivalent structures
So, lift and shift for PLM migrations only fails when poor-quality data is moved without preparation.
2. Don’t copy blindly
The fact that lift and shift requires minimal transformation doesn’t mean everything is copied without validation. Mapping of code values, cleansing of critical fields, pre-load profiling, and validation for high-risk objects is still lift and shift in spirit.
Therefore, allows teams to do basic mapping, targeted cleansing, and risk-based validation so the migrated data can load successfully and remain usable, without turning the project into a full redesign or transformation effort.
3. Configure the target system
Sometimes, it really is impossible to make your legacy PLM data work with the target system’s rules. But modern PLM solutions like Aras or Propel are quite flexible, so you can tweak around.
You can configure their platforms to support transition and data migration. For example, Aras supports Extended Classification, which lets teams assign properties based on classification and evolve classification structures without modifying core item types every time.
That can help during migration by preserving legacy distinctions in mapped fields first, then tightening standardization later.
4. Prioritize critical data
Not all PLM data needs the same level of cleanup or care. Some data is used every day, so it has to be clean and reliable. Other data is old and is only kept for reference, history, or audit purposes.
For example, legacy documents may only need retrieval accuracy. That is why a lift-and-shift approach may be perfectly acceptable for low-change, historical, or archive-oriented datasets. That still counts as a successful PLM migration for those domains.
5. Avoid strict standardization
There is nothing wrong with cleansing and standardizing data before migration. But it is not always the best path. Heavy pre-migration transformation has its downsides, such as:
- Lengthened timelines
- Increased business disruption
- Mapping errors
- Delayed retirement of legacy systems
In some situations, moving the data first and improving it in the target system is actually safer and faster.
Conclusion
The debate around lift and shift in PLM migration often gets framed as a simple yes-or-no decision. In reality, it is neither a silver bullet nor a flawed strategy. Its success depends on how thoughtfully it is applied. When organizations treat lift and shift as a disciplined migration approach, it can become a practical way to move forward without turning migration into a multi-year transformation project.
For Agile PLM users facing the end-of-life deadline, the real challenge is deciding how much change is truly necessary at the moment of migration.
If you are planning your transition from Agile PLM, don’t wait until the deadline forces difficult decisions. Xavor understands both the technical and operational realities of PLM migration. Our PLM experts have in-depth experience of using PLM platforms like Agile, Aras, and Propel to accelerate your Agile PLM transition. We can migrate complex product data safely to modern platforms using proven strategies that balance speed, accuracy, and long-term value.
Contact us at [email protected] to plan out a migration strategy that keeps your engineering teams productive and your data working for you.
FAQs
A common example of lift and shift is moving an on-premises application from a company’s own servers to cloud-based virtual machines with minimal changes. In a PLM context, it could mean transferring an Agile PLM instance and its data to a new hosted environment first, then optimizing or redesigning it later.
Lift and shift timelines vary based on the size of the system, data quality, integrations, and how much validation is needed. A simple migration may take a few weeks, while a complex enterprise migration can take several months.
Use lift and shift when you need to move quickly to a new environment with minimal disruption, especially for systems that are already fairly compatible with the target platform. It is also a good option when business continuity matters more than immediate redesign, or as a first step before later optimization.