Agile PLM isn’t just nearing end-of-life; it’s already failing its users. Security risks are escalating. Support is vanishing. And the expert consultants who know Agile are a shrinking pool that’s 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’s now an enterprise migration leader helping customers move off 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’re 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’s 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’s a real problem.
We immediately notified our customers: upgrade now or you’ll be removed from the platform. It’s 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 officially end-of-life on December 31, 2027. And the security risks will only grow if you stay on the platform.
If you’re still on Agile, it’s time to get off.
Q: What are some of the biggest mistakes companies make during a migration, and what are the smartest things you’ve seen them do?
K: The biggest mistake is believing there’s a DMJB, a "Do My Job Button." The thought process of a lot of customers is, "I’m hiring a consultant; they’ll do all the work for me, so I don’t even have to think about it or make decisions." That couldn’t be farther from the truth.
We assist in the process, but we can’t do all the work. Customers need to understand what they want, and that’s often the biggest challenge. They’re 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’ll help them get there, but they need to know what’s 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’d 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: “My 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’s how we get to a smooth go-live.
This is a common problem: users aren’t spending enough time up front, and they’re not truly owning their process. This isn’t 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—how much time is needed to support the project properly. But it’s really up to management to free up those resources so they can give the right feedback, perform proper testing, and make sure we’re building the right solution for them.
What’s even better, if it’s 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’s 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’re used to, it’s 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’d experience with any other PLM system I’ve worked with. It’s just a lot easier 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’s critical. We’ve spent months working with teams who are excited about the new solution.
Then they take it to their executives, who respond with, “What are you doing? This isn’t budgeted. This isn’t a priority. I’ve got other things to deal with. Don’t 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, “What if we only achieve half of these benefits?” or “What if just a quarter of these savings are realized?”
And don’t just look at costs. Factor in risk, like the potential financial and operational impact of a security breach.
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’t impacted was Propel.
The market cost 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’s 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’ve run into a lot of situations where users weren’t properly informed—not just about what decisions were being made, but why we were making them.
Sure, if Agile is going away, that’s an obvious decision. But users also need an incentive, a reason to want to work with the new solution.
Change is hard. It’s human nature. We get so used to running processes in a specific way that we don’t 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’s the dinosaur philosophy. You either evolve, or you go extinct.
We have to communicate clearly with users. Explain what’s happening, why it’s happening, and help them connect the dots between Agile and Propel. That mental link that makes them say, “ Oh, 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’t 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 migration planning begins. If cleanup pre-migration isn’t 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’t think customers see it as clearly as consultants do.
There’s going to be a huge mad rush to the exit in two years.
We’re looking at 30 years of Agile implementations that need to migrate, and there simply aren’t enough skilled consultants to handle all of that at once.
The consultant base has been dwindling for years because Oracle wasn’t innovating. Now, there are fewer of us available, and the demand is already ramping up. It’s going to be a tsunami.
The earlier customers get started, the better chance they have of completing the migration before the 2027 deadline.
