Agile PLM isn鈥檛 just nearing end-of-life; it鈥檚 already failing its users. Security risks are escalating. Support is vanishing. And the expert consultants who know Agile are a shrinking pool that鈥檚 only getting smaller.
To help companies prepare, we sat down with Keith Rust, a seasoned PLM expert with over 26 years of experience in product lifecycle management, enterprise systems, and digital transformation.听
As a former Agile PLM customer turned consultant, Keith has guided hundreds of organizations through complex transitions. He鈥檚 now an enterprise migration leader helping customers legacy systems like Agile and into modern, cloud-native platforms.
In this Q&A, Keith outlines the warning signs, pitfalls, best practices, and non-negotiables for any business planning to migrate off Agile.听
Q: What are the signs an Agile user should migrate to a new solution?
Keith:
鈥The simple answer is: if they are using Agile, they need to migrate.听
We鈥檙e really facing the end of days here. Customers need to get off the platform so they can have a supported, secure solution for the long term. That鈥檚 absolutely critical.
Just to give you a case in point: in January, the FBI reached out to us and said they were identifying bad actors actively trying to hack into Agile. The FBI flagged serious vulnerabilities, specifically in the WebLogic layer, that could allow attackers to gain control of the system. That鈥檚 a real problem.
We immediately notified our customers: upgrade now or you鈥檒l be removed from the platform. It鈥檚 that serious.
Agile 9.3.7 had been promoted as the long-term support platform, leveraging the latest version of WebLogic to stay protected. Oracle had a published roadmap and understood what to expect in the coming years. But then, one day, Oracle quietly removed 9.3.7 from the roadmap without any announcement.
That was it. No warning. Just gone. Agile is on December 31, 2027. And the security risks will only grow if you stay on the platform.
If you鈥檙e still on Agile, it鈥檚 time to get off.
鈥Q: What are some of the biggest mistakes companies make during a migration, and what are the smartest things you鈥檝e seen them do?
K: The biggest mistake is believing there鈥檚 a DMJB, a "Do My Job Button." The thought process of a lot of customers is, "I鈥檓 hiring a consultant; they鈥檒l do all the work for me, so I don鈥檛 even have to think about it or make decisions." That couldn鈥檛 be farther from the truth.
We assist in the process, but we can鈥檛 do all the work. Customers need to understand what they want, and that鈥檚 often the biggest challenge. They鈥檙e not always clear on their goals.
We can offer guidance, direction, and business consulting. We can walk through the pros and cons of various scenarios. But ultimately, they have to decide what they want from their system.听
Do they want to maintain the same processes? The same change types? The same item structures? Do they want to reorganize their data or clean it?
These are all critical discussions that need to happen early, so customers can properly own and manage their system going forward.听
We鈥檒l help them get there, but they need to know what鈥檚 right for them.
鈥Q: So would you say the smartest thing companies can do is to have a clear outline of what they want?
K: Most definitely. You need to come into this with an attitude of ownership over the process.
If I were the customer, I鈥檇 say: I know how my business operates. I know how I want things to work. And I know I need a tool to help me manage all the data, processes, collaboration, and so on.
That means creating a detailed list of user requirements: These are the things we need. System requirements: It must support X number of transactions per day, etcetera.
Customers need to have a clear understanding of what they want and write it down. Not just think about it. Write it down.听
That allows us to communicate clearly with vendors, choose the right solution, configure the system properly, and ultimately deliver a better user experience during implementation.
鈥Q: Where do companies most often underestimate time, budget, or resources, and how can they avoid that trap?
K: It goes back to the DMJB idea: 鈥淢y consultant will handle everything, and life will be wonderful.鈥 No software is a panacea. I see this over and over again, and I say it at every project kickoff: the more time you spend up front, the better the project will go. That鈥檚 how we get to a smooth go-live.
This is a common problem: users aren鈥檛 spending enough time up front, and they鈥檙e not truly owning their process. This isn鈥檛 something someone else can do for you.
To avoid that, there needs to be a clear time commitment from the start. We provide guidance on what we expect from users鈥攈ow much time is needed to support the project properly. But it鈥檚 really up to management to free up those resources so they can give the right feedback, perform proper testing, and make sure we鈥檙e building the right solution for them.
What鈥檚 even better, if it鈥檚 possible, is to have a dedicated hire to manage the implementation. Someone who owns the process end-to-end. They know the entire solution, they pull in the right people at the right time, and they act as the primary gatekeeper throughout the project.
We actually saw this on a recent implementation. A new hire came on board just two months before the project started, and it went great. It was so easy to ask questions and get answers. Everything flowed smoothly.
That鈥檚 the ideal scenario: having a dedicated person managing the project from start to finish.
鈥Q: What are the concerns Agile users have about migration that turn out to be less of a problem than expected?
K: One of the biggest concerns customers have is just the prospect of shifting my entire organization from one platform to another. That means new training for everyone, new SOPs, and impacts across the board: communications, integrations, supplier and customer collaboration. Everything gets touched.
But from the Propel perspective, the way the platform is designed and packaged is very similar to Agile. The training users have already gone through, the experience they鈥檙e used to, it鈥檚 largely transferable.听
There are definitely differences between the platforms, and yes, there will be some training involved. But the jump from Agile to Propel is dramatically smaller than what you鈥檇 experience with any other PLM system I鈥檝e worked with. It鈥檚 just to get used to.
So while customers often worry this will be a massive shift, the reality is that about 70% of what they know can be reused. Training with Propel takes less time than other solutions, and users are productive on day one.
A side benefit of less time required to implement Propel is that we can focus on business process automations, making the users even more productive.
鈥Q: How important is executive buy-in and cross-functional support? What do the best companies do to secure it?
K: It鈥檚 critical. We鈥檝e spent months working with teams who are excited about the new solution.
Then they take it to their executives, who respond with, 鈥淲hat are you doing? This isn鈥檛 budgeted. This isn鈥檛 a priority. I鈥檝e got other things to deal with. Don鈥檛 bother me.鈥
The best way to manage this is with a clear, reasonable ROI analysis. Not a pie-in-the-sky projection, something grounded. Even include assumptions like, 鈥淲hat if we only achieve half of these benefits?鈥 or 鈥淲hat if just a quarter of these savings are realized?鈥
And don鈥檛 just look at costs. Factor in risk, like the potential financial and operational impact of a .
Case in point: one of our large medical device customers recently suffered a data breach, and the result was ransomware that shut down their systems for months.
And by the way, the only platform across all of their business solutions that wasn鈥檛 impacted was Propel.听
The associated with that kind of loss of trust, from your customers and suppliers, is huge. That hits your top line, not just your IT budget. It鈥檚 the kind of risk that needs to be part of the business case from day one.
鈥Q: What internal governance or processes should companies have in place before migration begins?
K: Good communication. I鈥檝e run into a lot of situations where users weren鈥檛 properly informed鈥攏ot just about what decisions were being made, but why we were making them.
Sure, if Agile is going away, that鈥檚 an obvious decision. But users also need an incentive, a reason to want to work with the new solution.
Change is hard. It鈥檚 human nature. We get so used to running processes in a specific way that we don鈥檛 even have to think anymore. So yes, moving to a new solution requires training and adjustment, because things are different.
But avoiding change entirely? That鈥檚 the dinosaur philosophy. You either evolve, or you go extinct.
We have to communicate clearly with users. Explain what鈥檚 happening, why it鈥檚 happening, and help them connect the dots between Agile and Propel. That mental link that makes them say, 鈥溾奜h, this isn't gonna be as bad as I thought it was going to be.鈥
And yes, there are solutions out there with steep learning curves, but Propel isn鈥檛 one of them.
鈥Q: When should companies begin preparing their data, and how should they approach that process?
K: The earlier, the better. Know the state of your data: is it clean? Is it reliable? Is the shop floor building from what's documented?
If you know your data is messy, start cleaning it now, even before begins. If cleanup pre-migration isn鈥檛 possible, we may need to take it as-is and clean it post go-live.
If you're transforming data, like changing item numbers or descriptions, track that inside Agile now. We create legacy fields that carry over into the new system. That helps preserve traceability and supports downstream needs like marketing materials or websites that use old part numbers.
鈥Q: Do you have any concerns about how quickly Agile customers need to move?
K: Yes. We have a very short fuse, and I don鈥檛 think customers see it as clearly as consultants do.
There鈥檚 going to be a huge mad rush to the exit in two years.
We鈥檙e looking at 30 years of Agile implementations that need to migrate, and there simply aren鈥檛 enough skilled consultants to handle all of that at once.
The consultant base has been dwindling for years because Oracle wasn鈥檛 innovating. Now, there are fewer of us available, and the demand is already ramping up. It鈥檚 going to be a tsunami.
The earlier customers get started, the better chance they have of completing the migration before the 2027 deadline.
