Tag Archive for: Software Migration


As a modern alternative to traditional legacy platforms like IBM DOORS®, Jama Connect® enables digital transformation with a more efficient and user-friendly approach to managing risk and compliance. And although the benefits are innumerable, some organizations hesitate to migrate to a modern platform because they believe it’s a painful, slow process.  

In our recent webinar, attendees heard directly from one of our customers, Rockwell Automationabout why they decided to migrate from IBM DOORS and how they were able to successfully move to Jama Connect.  

In this session, the Rockwell Automation team answered the following questions, and more: 

  • Why was now the right time to switch tools? 
  • How easy was it to switch environments while preserving IP? 
  • How did the Jama Software team assist you in making the migration process as smooth as possible?
  • What are the drivers for continued and expanded use of Jama Connect? 
  • What are the key benefits you have realized since the migration? 

Below you’ll find a recording of the webinar and an abbreviated transcript.

Sheila King: 

Sheila King: Rockwell Automation has some business units that have functional safety products with the 61508. And although it’s not widely used Rockwell teams have solved their traceability and requirements management at the business unit level using Classic DOORS. Other teams were using homegrown requirements tools and traceabilities including Doxygen and yet other teams were using Word documents and Excel spreadsheets and doing the manual brute force way of doing traceability in requirements.

Sheila King: But then when the security landscape changed and we realized the vulnerabilities of industrial automation, the 62443 cybersecurity specification was invented and we decided that we needed to use it. Qw needed a site certification and in the process we adopted the IBM CLM product with the DOORS Next, RTC for planning, and RQM for test management.

Richard Watson: What led you to consider making a switch away from the tools that you were using and why was that change needed?

Sheila King: Well, we were already in the throws of adopting the CLM D and D tools and developing our product life cycles in order to meet the 62443 certification. And we decided in that process that we really needed to up our game. We needed better tools for planning tools, for our test integration and continuous integration and delivery and we needed better tools for requirements management that included the ability to move data widely between products because that’s real life. And in the current tools, the DOORS Next tools we needed to use the ReqIF which was really an administrative thing as opposed to people being able to move their own data.

Sheila King: We also had the solution for DNG and RQM and RTC and we hired a third party, or we contracted a third party vendor to manage that and we decided we needed a better integration for that for our vendor. We also, for the tools themselves, we needed variant and configuration management and native real-time traceability.

Richard Watson: Can we spend a few minutes looking at the primary considerations you have for selecting Jama Connect as opposed to DOORS Next Generation?

Sheila King: We actually created a grassroots working group to evaluate tools and we evaluated several. Our top two were of course, Jama Connect and Helix, the tiebreakers where these. Jama Connect had functional safety-ready certification, and anybody who goes through functional safety knows how much value that is for your audit. We needed a strong review center and Jama Connect has that. We needed baselines in order to be able to not have to use SAP for saving our documents. We like the rational database and the ability to configure different item types.

Sheila King: We not only use Jama Connect for our requirements but we use it for our threat models and our fault models. And we also like a lot the structure, the permission structure that allows you to specify all the way down to requirement if you need to how you’re going to protect your data in the tools, and with our fault and models are designed for security and threat models, that is our business risk or business restricted setting.

Richard Watson: Thank you. We know that the value of an organization’s environment is their data. You spend a lot of money buying tools and maintaining tools but the real value is the data that you have inside the tools. Can you share some of the concerns Rockwell had going into migration?

Sheila King: Yeah. First of all, we were going to having all our data in the cloud. And so we had our CISO team get involved in that and they did an evaluation because not only were we now putting requirements in the cloud, we were putting our source in the cloud. We were putting our planning, our tests in the clouds, our anomalies in the cloud, some kind of scary stuff to have in a cloud, and so we had a CISO audit and they decided that it was very safe to do that. Secondly, when it comes to actually keeping our data safe, the truth is we asked Jama Software to explain to us how they were going to keep it safe and they convinced us that they could and so they’ll tell you that they kept our data safe.

Richard Watson: Maybe that’s a good transition to the next question. This is just a discussion around were there any specific steps you took to protect your data and IP?

Sheila King: Yeah. Because we had such a short window for moving all the content over, we made backups as it was in our current tools and then moved them into the tools and we use the ReqIFs, the collections and all that stuff from DNG and just about every other way you can export data out of that and backed it all up. And then once we moved it into Jama Connect, actually just handed it over to the Jama Software team, Alisa and the Jama Software team, and they imported it and then we migrated the data once we had it inside.

Richard Watson: Maybe we can bring Alisa into this as well. And so can you and Alisa share some of the details around the migration approach?

Sheila King: Just as I mentioned we had six months to do it, so we had three phases that we started with. We worked with our stakeholders to identify all the content to be migrated and then we again had the extremely tight window. We elected, like I mentioned, to adopt to bring it over into Jama Connect as is. So we had everything brought in in the format that it was in DNG and then Alisa was on site within a week of our purchase to help us with the migration.

Alisa Eikanas: I remember that I arrived in Ohio on April 1st and I remember hoping that it wasn’t a bad omen, which of course it wasn’t, this wound up being one of the most rewarding and enjoyable projects I’ve ever had the pleasure of supporting. The sign that’s being presented now basically illustrates the standard migration approach utilized by the solutions team here at Jama. Every migration is going to have unique elements, needs, but in the case of Rockwell’s migration this template married very well, as Sheila is taking care of the planning and we transitioned seamlessly into analysis and discovery.

Alisa Eikanas: During the discovery and proof of concept stages we did come across a few issues that required some customized tool development, but once we had validated the integration tools and approach the execution of the final stages was a fairly straightforward process. Sheila was generating all of the extracts from the legacy systems. She would transfer those files to me and then I would load them into Jama.

Alisa Eikanas: And as Sheila said, in some cases we go through a cleaning of the data prior to migration but again given the short window we elected just to bring all of the data from DNG, which in some cases we had some modules that had over 170 attributes. But again with a short timeframe we just elected to bring everything in as is and clean it up afterwards because at the end of our migration window Rockwell was losing to their DOORS instance, so really for us a critical item was making sure that we got done on time.

Richard Watson: That sounds pretty comprehensive. Sheila, now that you’re at the other end, how would you rate your experience around migration and user satisfaction?

Sheila King: Well, the team was just great to work with. Again, Alisa, she just worked really hard to integrate and migrate our data. Anytime we ran into an issue we would tell the software group and they’d come in and they would write some code to add to their data exchange to manage the data that was coming out of the tools and it just worked really very well. And she worked with our team, like she mentioned, the classic DOORS group had 100 and I can’t remember seven fields and we were able to talk them down into just, I think it’s 10 now. Is that right, Alisa?

Alisa Eikanas: Yes, it is. Yeah, from 170 to 10.

Richard Watson: Wow. Is there any advice for teams hesitating making a similar move due to migration concerns?

Sheila King: No. I think it’s the water is warm, just hop in. And let me add to this, because we’ve been giving teams the ability to decide when they switch over to the tools, find a perfect time or find a space between projects and stuff like that. And the truth is there’s never a good space to migrate. And so we’re actually encouraging people to just go ahead and start because they will see efficiencies right away. And so it’s not just to get involved and to find a good spot because you won’t but you will find efficiencies right away.

Data Migration to Modern Requirements Management

This post on moving away from IBM DOORS® is part of a series. You can find Part II on legacy software pains here, Part III on enabling innovation here, Part IV on the difficulties of compliance here, and Part VI on migration solutions here

IBM® Rational DOORS® has been around since the early ‘90s and has served many teams well in the past. But in today’s web-based, interconnected world, if you’re still using DOORS, your requirements are likely stuck in a siloed Windows application. It’s time to retire DOORS and move to a modern requirements management solution. Here is a hands-on guide for a painless data migration from a legacy requirements management solution like DOORS to Jama Connect®.

Software Migration Prep Work: Start by Taking Inventory

Before you begin your software migration, start by screening your DOORS data to get a rough overview of the work ahead of you. Collect key metrics of your current system:

  • How many DOORS modules do you have?
  • How many objects (items) reside in each module? Average? Maximum? Minimum?
  • How many attributes do your modules have, and how complex are they? Again, look at average, maximum, minimum, and also whether you use DXL attributes.
  • How many DOORS projects and folders?
  • How consistent is your data? Do all modules of a certain type (e.g. “User Needs”) have the same attributes?
  • Do you use any special DOORS features, like DOORS Tables, DXL scripts, or OLE objects?

Decide What to Migrate Where

It is rarely necessary to migrate all your data to Jama Connect. Your data migration typically only needs to include active data, not completed projects. It’s usually not necessary to migrate the history of your data, only the latest version.

Of course, completed projects and version history must not simply be discarded. Rather, you want to keep this information accessible somewhere, at least as long as legally required – this needs to be part of your software migration strategy.

You have the following options for your data migration, and you can mix and match them as you see fit:

  • You should always make a regular DOORS backup and properly archive it. This data is inaccessible, unless you reactivate DOORS
  • Active data should migrate to Jama Connect
  • Completed data should be exported in a format that can be processed without DOORS. This could be a simple PDF (or Office) export
  • Alternatively, you can export the data using the Requirements Interchange Format (ReqIF). ReqIF is an open standard for exchanging requirements. As Jama Connect supports ReqIF, you could always import that data if needed at a later time
  • Lastly, you can decide to keep DOORS around on a single license, and ensure all data is accessible

See how IBM DOORS customers can migrate to Jama Connect by viewing our datasheet.

Invest in Jama Connect Configuration

There is always the temptation in a software migration to simply move what you have from point A to point B; from DOORS to Jama Connect.

However, migrating to a new solution is a great opportunity for optimizing your processes and taking advantage of the capabilities of the new solution. This does not mean that you should throw everything out that you built so far. It simply means that you should revisit what you have, remove what did not stand the test of time, and reflect on the underlying use cases to ensure that the underlying problem is solved instead of blindly copying a mediocre solution.

In Jama Connect, this means that you should carefully analyze your existing data to configure frameworks for the various types of projects that you have. For instance, you may have a framework for complex, safety-critical development that follows the V-Model, and another lightweight Agile framework for app development.

A framework in Jama Connect is a configuration consisting of project structure, trace rules, workflow, and permissions that can be used as a template for new projects, as shown in the figure below. You should have frameworks that fit the data you intend to import. After the migration, all projects in DOORS that were “similar” will then follow the framework in Jama Connect, creating improved alignment and consistency.

Data is Easy, Customization is Hard

There is also a good chance that your DOORS system was customized significantly over the years. This is mainly due to the fact that DOORS can be programmed with a scripting language called DXL. While it is tempting to quickly solve a software migration problem by writing a little script, this can create long-term liabilities and maintenance nightmares.

It’s important to understand that no other requirements management tool supports DXL. Therefore, if you migrate to another solution (Jama Connect or otherwise), you will leave DXL behind.

So, rather than providing a scripting language, Jama Software provides an open Application Programming Interface (API). This allows you to perform customizations if necessary, without the liabilities that comes with scripting.

RELATED: Legacy Sunset: Scalable Migration Solutions for Jama Connect

Migrating to Jama Connect

Now that the Jama Connect frameworks are configured and the data identified, it’s time to migrate. We would not recommend your data migration happens all at once, but instead unfolds in three phases:

  • Phase One: In the preparation phase, you’ll perform a few test imports to ensure the data migrates across correctly.
  • Phase Two: When ready, you can migrate one pilot project. After evaluating the results (or even better, working for a few weeks in production), you can fine-tune and optimize the import process for subsequent projects.
  • Phase Three: At this point, you’re ready to migrate the remaining data. It is generally a good idea to keep the overlap — with both DOORS and Jama Connect in production — as small as possible.

The Software Migration Process

Jama Software provides four different facilities for data migration. Whichever one you use depends on your specific situation and the amount of data you need to migrate. All data migration options will maintain formatting and traceability:

  • Jama Connect ships with a built-in DOORS importer. To use it, you export views in DOORS to HTML, which are then imported. Every module has to be processed by hand, so this path is useful for test imports and small quantities of data (a few dozen DOORS modules).
  • You can also use Jama Software’s Data Exchange, which works with ReqIF, the Requirements Interchange Format. You can export data in DOORS and subsequently import it into Jama Connect. This scales better as you can process whole projects at a time.
  • You can also use Jama Software’s DOORS Migration Engine, a set of configurable tools that we tailor to your specific situation, which makes bulk migration possible.
  • If none of these options works for whatever reason, you can build your own scripts that import data into Jama Connect using our REST API.

RELATED: Legacy Sunset: Why Jama Connect is a Proven Alternative to Legacy Requirements Management Tools

Learn more about requirements traceability by downloading our eBook, The Jama Software Guide to Requirements Traceability.”


DOORS has been a faithful requirements management tool that has served the product development community well for almost 30 years. But in order to stay competitive, it’s necessary to switch to a modern requirements management solution like Jama Connect.

Software migrations are rarely fun. However, when you migrate from DOORS to Jama Connect, it is a rewarding experience, as you end with an intuitive, user-friendly, and team-friendly environment. Plus, as your data gets aligned to the Jama Connect framework during the software migration process, your requirements data will be consistent and synchronized to your team’s processes.

See how Jama Connect can transform your requirements management process for legacy software customers in our whitepaper, “Jama Connect: A Modern Requirements Management Alternative to IBM DOORS.”