Why Do We Need a Product Migration Tool?
Organizations rarely stay static. Business units are acquired or divested, consulting engagements come to an end, projects move between hosting environments, and teams sometimes need to consolidate multiple Spira installations into a single enterprise platform. In all of these situations, moving the data is only part of the challenge. The real requirement is to move the complete working environment - including its artifacts, configuration, workflows, custom fields, users, and business processes - without having to reconstruct everything manually at the destination.
To make these scenarios much easier, Inflectra has released a completely new generation of the Spira Product Migration Tool, designed to migrate complete products between different instances of SpiraTest, SpiraTeam, and SpiraPlan.
Unlike traditional import/export tools that focus primarily on moving individual records, the new Product Migration Tool is designed to preserve the structure and configuration that gives those records meaning. The September 2026 2.0 release adds the ability to back up an entire product's data alongside its product template, as well as product membership information and the creation of users when necessary on the destination system.
Moving More Than Just the Data
A Spira product is much more than a collection of requirements, test cases, defects, and tasks. Over time, organizations configure Spira to reflect the way their teams actually work. They create custom artifact types and statuses, add custom properties, build custom lists, configure workflows, establish priorities and severities, and define the processes that artifacts follow throughout their lifecycle.
The new migration capability is designed with this in mind. When a product is backed up, Spira can preserve the product template information that controls how the product operates. This includes the configuration associated with requirements, releases, documents, test cases, incidents, tasks, and risks. Depending on the artifact, this can include its types, statuses, priorities, severities, custom properties, workflow steps, and workflow transitions. Custom lists and their values are also included.
This is particularly important because simply transferring an artifact without its configuration can fundamentally change its meaning. A requirement that was previously governed by a specific approval workflow, for example, should not arrive on the destination system with a completely different lifecycle. Similarly, a defect that relies on organization-specific severity levels or a test case containing important custom properties should not lose that information merely because it has moved to a new Spira instance.
The Product Migration Tool therefore approaches migration as the movement of a complete working product rather than as a simple data export.
Preserving Your Workflows
Workflows are one of the most important elements to preserve during a migration because they encode how an organization manages its processes.
In Spira, workflows can determine which statuses an artifact can transition between, which transitions are available to different users, and whether fields should be visible, hidden, disabled, or required at different stages of the lifecycle. Organizations frequently customize these workflows to represent approval processes, quality gates, regulatory controls, development processes, or internal governance requirements.
The migration tool backs up the workflow steps and transitions contained within the product template for the artifact types that support workflows. This means that when the template is recreated on the destination Spira instance, the organization does not have to manually rebuild those processes from screenshots, documentation, or memory.
This can represent a significant saving for heavily customized Spira implementations, where years of process refinement may be embedded within a product template.
Custom Properties and Custom Lists Come With You
The same principle applies to custom fields.
Many organizations extend Spira using custom properties to capture information specific to their industry, methodology, organization, or customer. A pharmaceutical organization might capture validation information that a commercial software company does not need. An aerospace organization might have additional verification fields, while a consulting organization might use custom fields to track customer-specific deliverables.
These properties are part of what makes the information inside Spira useful to the organization, so leaving them behind during a migration would significantly reduce the value of the transferred data.
The Product Migration Tool includes custom properties associated with the major Spira artifact types, along with custom lists and their values. The template backup functionality covers custom properties for requirements, releases, documents, test cases, test steps, test sets, test runs, automation hosts, incidents, tasks, and risks.
As a result, organizations can move their configured data model together with the artifacts that depend upon it rather than having to recreate fields and manually map values after the migration.
Migrating the Product Artifacts
Of course, configuration is only half of the equation. The new 2.0 Product Migration Tool now supports backing up the entire product's data in addition to its template.
That means the working information contained within the product can move with its configuration. Instead of recreating a product on the destination instance and then using separate spreadsheets, APIs, scripts, or individual artifact exports to rebuild its contents, administrators can use the migration process to move the product as a coherent whole.
For a typical Spira implementation, that product data represents the interconnected lifecycle information that teams have built up over time: requirements and releases, test cases and test execution information, incidents, tasks, risks, documents, and the other artifacts used to plan, develop, test, and deliver the product.
This is especially valuable because Spira's strength comes from the relationships between these artifacts. Requirements can be linked to test cases, tasks, releases, incidents, and risks, creating an end-to-end picture of the lifecycle rather than a collection of unrelated records.
A migration therefore needs to preserve the product as a usable environment, not simply produce disconnected copies of its records.
Bringing Product Membership Along as Well
Products are also defined by the people who work on them.
The new migration tool includes product membership information in product backups. When users referenced by the migrated product do not already exist on the destination Spira instance, the migration process can create the necessary users.
This is important because product membership in Spira determines who has access to a particular product and associates each user with a product role. Those roles are then used throughout Spira to control artifact access and other product-level permissions.
Including membership in the migration significantly reduces the amount of administrative cleanup required after a product has been transferred and helps make the destination environment much closer to the original working environment.
A Simple Backup-and-Migrate Process
The migration process is intentionally designed around a portable backup.
An administrator first connects the tool to the source Spira instance and selects the product that needs to be backed up. The tool creates a local backup containing the information needed for the migration. That backup can then be opened by the migration tool and migrated into a destination Spira instance.
Because the backup exists independently of either Spira server, organizations can also separate the export and import stages. For example, one organization can create the backup, securely transfer the file to another organization, and allow an administrator of the receiving Spira instance to complete the migration.
The migration tool also tracks the progress of an operation. If a backup or migration is interrupted, the operation can be resumed rather than having to restart the process from the beginning. The tool records progress and creates logs that can be used to diagnose any problems encountered during the operation.
That makes the tool suitable not just for small demonstration projects, but for real-world products where migrations may involve substantial amounts of configuration and data.
Supporting Mergers, Acquisitions, and Divestitures
One of the clearest use cases for the Product Migration Tool is organizational change.
Consider a company that sells one of its business units. That business unit may have spent years managing its requirements, testing, development planning, defects, risks, and compliance information in the parent company's Spira environment. As part of the divestiture, that information may need to become part of the new company's independent IT environment.
Rather than attempting to reconstruct the project manually, the relevant Spira products can be backed up and migrated to the destination organization's Spira instance.
The opposite scenario is equally common. Following a merger or acquisition, an organization may want to consolidate previously independent Spira environments. Individual products can be moved into the strategic enterprise instance while retaining the processes and historical information associated with them.
Handing a Completed Project From a Consulting Firm to Its Customer
Another common scenario involves consulting firms and systems integrators.
A consulting organization may use its own Spira instance while designing, building, and testing software for a customer. During the engagement, the Spira product can accumulate requirements, tests, defects, documents, risks, release information, workflows, and other valuable project history.
At the end of the engagement, the customer may want to take ownership of that information rather than leaving the project's lifecycle history inside the consultant's systems.
The Product Migration Tool provides a much cleaner handover mechanism. The consulting firm can package the completed Spira product and transfer it to the customer's own Spira environment, giving the customer a working project environment that can continue to be used for maintenance, future releases, regression testing, audits, or subsequent development.
Moving Between Hosting Environments
The migration tool is also useful when organizations change how their Spira environments are hosted.
For example, a product may need to move from one independently managed Spira instance to another as part of an infrastructure reorganization, regional consolidation, business-unit separation, or broader application modernization initiative.
It can also help organizations that maintain multiple Spira environments for different divisions, customers, or operating units and periodically need to move products between those environments.
Instead of treating those movements as database-level infrastructure projects, administrators can work at the logical Spira product level and transfer the information that belongs to the product itself.
Creating Portable Product Environments
There are also interesting possibilities beyond one-time corporate migrations.
Organizations with standardized methodologies can use the underlying template migration capabilities to move carefully configured Spira environments between installations. A consulting company, for example, might maintain a specialized template for medical-device development, aerospace engineering, or Agile software delivery and migrate that configuration into environments where the methodology is needed.
Similarly, product backups can provide organizations with a portable representation of important Spira products that can be retained independently from the live system.
The result is greater flexibility in how organizations manage and distribute both their lifecycle data and the processes they have developed around it.
Making Spira Data Truly Portable
Software lifecycle data increasingly represents valuable organizational knowledge. A mature Spira product can contain not only the individual requirements, tests, defects, tasks, and risks associated with a project, but also years of decisions about how that work should be structured and governed.
The new Spira Product Migration Tool is designed to make that complete body of information substantially more portable.
Whether you are separating a business unit following a divestiture, consolidating systems after an acquisition, handing a finished project from a consulting company to its customer, reorganizing your Spira infrastructure, or simply moving a product to a different Spira environment, the goal is the same: move the product without having to rebuild the product.
By combining product data migration with product templates, workflows, custom properties, custom lists, and product membership, the new tool provides administrators with a much more complete way to transfer Spira products between independent instances.
The new Product Migration Tool is compatible with the Spira family of products, including SpiraTest, SpiraTeam, and SpiraPlan.
