Introduction to the Topic: Moving Off Windchill RV&S
Hi everybody, and welcome to this SPK and Associates vlog entitled The Top Five Pitfalls to Avoid When Moving Off Windchill RV&S.
My name is Michael Roberts. I’m the Vice President of Sales and Marketing here at SPK and Associates.
Today, we’re talking about a topic that’s coming up more and more with engineering and product teams: what to watch out for when moving off Windchill RV&S.
Many organizations are reaching a point where they’re evaluating more modern tools, consolidating systems, or shifting to more open-source or modern platforms to better support their development and compliance teams.
But these transitions aren’t simple, and there are risks. Those risks are very real.
To help unpack this, I’m joined by one of my colleagues, Colin Doyle, Senior Process Architect at SPK and Associates.
Colin, thanks for being here. Please introduce yourself.
Colin Doyle’s Background and Expertise
Hi there, folks. I’m Colin Doyle. As Michael mentioned, I’m a Senior Process Architect here at SPK, and I’ve worked with numerous clients on both RV&S and Codebeamer, as well as other tools.
Before we get started, I want you to share more of your background with the audience so they can understand your experience and the types of migrations you’ve been involved in.
Sure.
I have over three decades of experience working with application lifecycle management tools.
For 10 of those years, I was the Senior Product Manager of Windchill RV&S, which was originally known as MKS Integrity.
I’m also an expert in Codebeamer.
I’ve worked with most of the other major tools, including Jira, Perforce, and DOORS. For those who remember, ClearQuest and ClearCase as well.
I’ve seen them all. I have extensive experience in this space.
Why Migration Expertise Matters
Because of that, Colin has been involved in many different migration strategies.
I’m happy to have him here today to walk through some of the potential pitfalls.
Let’s start with one of the most common issues.
When teams try to replicate their RV&S setup exactly in a new tool, why can that approach create problems—especially when it comes to source control?
Why Replicating RV&S Exactly in a New Tool Can Cause Problems
Absolutely.
Every tool has a different approach and a different feature set. There is always going to be some level of mismatch when moving from one tool to another.
In RV&S, Source Integrity—the source control component—was designed to be a very sophisticated and powerful configuration management tool.
This differs significantly from modern version control tools.
Git, for example, is essentially a version control tool, and it is a common destination for organizations migrating from RV&S.
However, Source Integrity has several features that are fairly unique.
Unique Capabilities of RV&S Source Integrity
One key difference is how projects and subprojects are structured.
In RV&S, in addition to the top-level project, every folder inside a Source Integrity project can itself be a project.
These subprojects can:
- Be shared across other projects
- Be branched independently of other projects in the hierarchy
- Be reconfigured to point to different branches independently
This level of flexibility is not something that most modern version control systems provide.
These capabilities are very specific to RV&S.
Challenges When Migrating to Git
When migrating to Git, organizations need to carefully consider how to map these capabilities to Git’s structure.
Git has the concept of shared modules, which can sometimes be used to represent shared subprojects.
However, Git does not have an equivalent capability for reconfiguring individual subprojects to reference different branches dynamically within the same hierarchy.
This creates a fundamental architectural difference.
Key Migration Decisions Organizations Must Make
Because of these differences, organizations must make important decisions about how to structure their new environment.
For example, they must decide whether to:
- Proliferate projects so that each branch structure is represented as its own project, or
- Consolidate and simplify the project structure into a more standardized model
Both approaches have trade-offs.
This is an area where migration strategy is critical.
We’ve worked with many clients to help them make these decisions so their migration is as smooth as possible and aligns with their long-term goals.
Understanding the Complexity of Source Control Migration
There’s a lot of complexity there, which leads to the next question.
What are the likely areas of friction or impedance mismatch between RV&S and newer, more modern tools?
Major Differences in Document and Workflow Architecture
There are several areas where friction can occur during migration.
One of the most important areas is workflows and document management.
RV&S has a full document model.
What that means is that within a given project, you can have multiple instances of the same document type.
This is different from many modern tools.
In RV&S, an item type doesn’t just represent individual pieces of content. It can represent an entire document structure.
Each document has its own container, or cover page, which is represented as its own item.
This container can have its own fields and metadata, separate from the individual content items within the document.
Unique Document Capabilities in RV&S
RV&S also allows documents to be shared across different projects or contexts.
This enables reuse and modular document structures.
These capabilities are fairly unique to RV&S.
When migrating, it’s critical to understand how these document structures will be represented in the new system.
Codebeamer’s Approach Compared to RV&S
Codebeamer, for example, has different strengths.
One of its biggest strengths relative to RV&S is its modern user interface.
It is entirely web-based, which improves accessibility and usability.
However, while Codebeamer has document views, it does not have first-class document objects in the same way that RV&S does.
This creates architectural differences that must be addressed during migration.
Migration Strategy Decisions: Projects vs Trackers
When migrating documents, organizations must decide how to represent multiple instances of the same document type.
There are several possible approaches.
One option is to create multiple projects in Codebeamer to represent different document instances and organize them hierarchically.
Another option is to create multiple trackers that represent each document instance within a project.
Both approaches are valid.
The best approach depends entirely on the organization’s structure, workflows, and long-term goals.
Migration is not just a technical process. It is a strategic decision.
Organizations must carefully evaluate how their existing document architecture aligns with the capabilities of the new platform.
Migration Requires Strategic Planning, Not Just Technical Conversion
Exactly.
These document and workflow differences represent one of the most important considerations during migration.
Understanding how document models differ between systems is essential for ensuring a successful transition.
Preserving History, Traceability, and Migration Risk
Why Traceability and History Preservation Are Major Migration Concerns
I feel like with this question, we’re opening an even bigger part of Pandora’s box.
Many of the companies using RV&S today operate in highly regulated industries, such as medical device organizations.
Traceability is usually one of the biggest concerns in those environments.
Where do migrations tend to go wrong when it comes to preserving history?
First Migration Decision: Do You Need to Preserve History?
That’s a very important question.
One of the first decisions organizations need to make during migration is whether they actually need to preserve historical data in the new system.
Based on my experience, the vast majority of clients decide that they do not need full historical migration.
Instead, they typically:
- Keep their existing system in read-only mode, or
- Archive the historical data separately
They then start the new tool with the current baseline.
This approach significantly simplifies migration.
However, if history must be preserved, migration becomes much more complex.
Understanding Change Packages vs Checkpoints
When preserving history, you need to decide how that history will be represented in the new system.
On the source control side, RV&S uses change packages and checkpoints.
A useful analogy is a banking system:
- Change packages are like your transaction history
- Checkpoints are like your account balances
Some organizations want to preserve every change package as individual commits in the new system.
This approach recreates the full commit history.
However, this is a very complex migration strategy.
Recommended Approach: Migrating Baselines Instead of Full History
Most organizations choose a simpler and more practical approach.
Instead of migrating every individual change package, they migrate checkpoints.
Checkpoints can be used to create baselines in the new system.
This preserves meaningful historical milestones without introducing excessive complexity.
This approach significantly reduces migration risk.
Document History Migration and Traceability Reconstruction
Document migration presents similar challenges.
RV&S allows baselines of documents to be preserved.
These baselines can be migrated into the new system.
However, traceability relationships must be rebuilt during migration.
This process involves:
- Migrating a baseline
- Rebuilding traceability relationships
- Migrating the next baseline
- Updating traceability relationships
- Verifying correctness at every step
This process must be done carefully and systematically.
Why Validation and Testing Are Critical During Migration
Verification is essential.
At SPK, we typically develop automated test suites alongside migration scripts.
These test suites verify that traceability and relationships have been correctly recreated.
This is critical because once history is migrated, correcting errors afterward is extremely difficult.
Most tools do not allow historical data to be easily modified after migration.
Mistakes in migration can permanently affect traceability.
Migration Strategy Often Changes Based on History Requirements
The complexity involved in preserving history often changes migration strategy decisions.
Organizations frequently adjust their migration plans after fully understanding the effort and risk required to migrate historical data.
Careful planning and validation are essential for success.
Final Migration Recommendations, Training, and Organizational Readiness
Migration Is an Opportunity to Improve, Not Just Replicate
Last area, Colin. What are the main things teams should consider if they’re planning to move off Windchill RV&S in the next year?
There are a couple of key considerations.
First, organizations need to think carefully about why they are moving off RV&S.
If the goal is to move to a web-based solution, and RV&S is not fully web-enabled, that is a valid reason.
However, if the reason for migration is that certain aspects of the current solution are no longer fit for purpose, simply migrating the existing configuration as-is will carry those problems forward into the new system.
Migration is not just a technical transition. It is an opportunity.
It is an opportunity to revisit the current solution.
Organizations should evaluate:
- What they want to keep
- What they want to change
- What they want to improve
Migration provides a chance to modernize workflows and optimize processes.
This is the ideal time to make those improvements.
User Training and Adoption Are Critical for Success
Another critical factor that many organizations overlook is training.
Users become accustomed to working in RV&S.
When they move to a new tool, their natural instinct is to expect it to behave the same way.
However, it will not behave the same way.
Each tool has different workflows, interfaces, and operational models.
Without proper training, users may struggle to adapt.
Providing training ensures users understand how to work effectively in the new system.
Training helps ensure a smooth transition and improves long-term adoption.
Migration Requires Strategic Planning and Long-Term Focus
There is a lot to consider when planning a migration.
Understanding potential risk areas is incredibly valuable.
Colin, thank you again for sharing your experience and insights.
You’re welcome.
Moving off Windchill RV&S is a significant step.
It involves many components, including:
- Thoughtful planning
- The right migration strategy
- A focus on long-term adoption
Migration success depends not just on the technical transition, but on how well the organization adopts and utilizes the new platform.
SPK’s Migration Expertise and Call to Action
If your organization is considering a migration in the next year, we encourage you to speak with our team.
Whether it involves discovery, migration planning, implementation, or ongoing application management, Colin and our team of experts can help guide you to a successful outcome.
If you’d like to continue the conversation or explore what migration would look like for your environment, please reach out through SPK and Associates’ social channels or website.
We would be happy to help.
Thank you everyone for joining us today.
Until next time.
