Jira vs. VersionOne
With any migration, it's important to have a solid understanding of why an organization might want to move from one to the other, how the data is structured, and key configuration elements. VersionOne is an Application Lifecycle Management tool used for tracking and reporting business projects. It is also known for its utilization of agile methodologies to simplify processes in planning and tracking projects. What this means is essentially that it supports common agile processes such as Scrum, Kanban, etc. How well does it stack up next to Jira with its implementation of these processes and reports? Jira Software is an Agile Project Management tool used for planning, tracking, and reporting issues across projects in Scrum or Kanban. If both tools do similar things, why make the change? There are a number of features available in Jira that outclass or are simply not available in VersionOne. Items like Workflow Customization, Board Customization, Dashboards, Customizable Portfolio Roadmaps, a large online presence, and thousands of available add-ons are just some of the areas where Jira provides significant value to users and managers alike. Let's take a look at a few of the differences mentioned:
Workflows - VersionOne workflows are simply the statuses available on the Board. Jira allows for different workflows by issuetype which can then be mapped to a Jira Software Scrum or Kanban board in the same or different columns. These workflows can be simple, or they can contain heavy amounts of customization including requirements for users who can transition issues through a workflow, fields that need to be filled before a workflow can be moved, or even updating issues automatically after a transition occurs.
Boards - In VersionOne, A board shows the status and the issues are listed under that status column. In Jira, multiple boards can be created for each project allowing for teams to filter out issues easily so that only the issues they need to work on appear on their board. The feature allows flexibility for customized views, advanced workflow usage, and scalability across teams. Additionally, issue filters and swimlanes can be added and customized to further organize the issues users need to see.
Dashboards - VersionOne has reporting but not dashboards. Jira allows users to filter out issues into dashboard "gadgets" that will display information neatly in different ways. For example, it can display issue breakdown in a Pie Chart, or a two-dimensional chart with the chosen values on the X and Y axis, or maybe you want to see the Sprint Burndown in real-time without having to pull a report. Dashboards allow users to see important project details at a glance, providing not only a time-saving value but also an ease of access value for checking on project progress. It is important to note that Jira also provides Reports separate from dashboards that are part of each project and Scrum or Kanban board.
Portfolio Roadmap - VersionOne has a very basic roadmap feature that displays project information across a timeline fashion. Jira Advanced Roadmaps is highly customizable and allows you to plan based on capacity, track dependencies, manage competing priorities, and explore alternative scenarios with synchronization with the data in selected Jira projects. Jira Advanced Roadmaps allows for many different views to display information in many different ways. These displays also allow for issue updates on a high level that can be reviewed and changed in bulk. It provides the capability to display estimation statistics on a sprint or release (version) level, displaying the progress of the sprint or version by issues completed within their respective timeline. If teams are incorporated properly and tickets are estimated with story points, it is possible to see how many story points have been allocated to a sprint and whether the team that assigned the issues in the sprint will be able to complete that number of story points or if the work would need to be split into a new sprint. Another option could be to reassign some issues to another team to meet the deadline.
Large Community Support - Since Jira is so widely used, it has a very large community that provides updates, support, and local get togethers to enhance Atlassian usage. There is a vast amount of information posted by the community regarding various features and assisting users in need. In addition to user help, there are countless knowledge base articles provided by Atlassian and partners containing best practices and use of the tools. Atlassian also provides free online courses that offer exceptional advice allowing users to start off on the right foot.
Preparing for the Migration
Now that we know a bit about why organizations are moving to Jira, there are a few areas where VersionOne differs greatly from Jira and preparations will need to be made ahead of time before starting your migration.
Project Configurations - It is recommended to have standard project configurations for all projects being migrated, so that each Jira project can apply the appropriate standard configuration and map data items. Not all projects may want to follow the same standards (permissions, issue security, screens, etc) but the configurations should remain consistent across migrated projects in preparation for the import. After the migration of the project is complete, the standards can easily be updated at scale across projects.
Statuses and Workflows - Statuses are contained within the workflow and will need to be mapped during the import. Building a "standard" workflow containing the essential statuses for the business and getting project management to sign off on how issues would be mapped to the workflow is the ideal situation. The majority of projects should be able to follow a single workflow standard. Alas, getting all projects to a single workflow is not always possible (and isn’t often recommended). In this case, building out workflows for the projects that require deviations from the standard will need to take place before those projects are migrated. During the migration, the statuses will be mapped to their corresponding status in the Jira workflow. Make sure that the mappings from one status to another are documented for each project since you will need to reference them during the import process and for validation post migration. If a standard workflow cannot be established or the project managers have not had time to decide on a workflow, then a single workflow applied to the project containing each of the statuses that exist in VersionOne will get the job done. The imported issues will maintain the same status they had in VersionOne and a new workflow/mapping can be done in Jira at a later date. Something additional to note is that, if the mapped status does not exist on the workflow assigned to the issuetype, that issue will fail to import.
Projects and Child Projects - VersionOne has the ability to Create Child Projects or "sub-projects" which allows for projects to be nested under other projects. Jira does not have a project hierarchy and only allows for single projects, not child projects. While an issue hierarchy can be established in Jira Software with Advanced Roadmaps, it will be important to also have a plan for the VersionOne sub projects for your migration. Will these sub-projects be listed as components in Jira? Or possibly a custom field with a context set for each "parent" project containing the sub-project values? Or perhaps the child project needs to become its own project. This will be an early hurdle that will require stakeholder discussion. Creating the Projects ahead of time in Jira is an important first step since you will need a destination for your import.
Custom Fields - Any custom fields in VersionOne that contain data that needs to be migrated will also need to be created in Jira and mapped for import and validation.
Issuetypes - VersionOne Epics are called Portfolio items and Sub-tasks are called Tasks. Additional issuetypes such as Requests and Issues are also available and considerations will need to be made as to whether those items should be mapped to an existing issuetype in Jira or if those issuetypes need to be created and mapped to the projects. Keep this in mind with the child project hierarchy in VersionOne and the Issuetype hierarchy in Jira Software.
Linking - Linking takes place in multiple sections in VersionOne, whereas it falls under a link type in Jira. These can be customized in Jira but it is generally recommended to stick with the already established link types and definitions.
Test Cases - Jira does not natively handle test cases, so if your VersionOne instance is executing test cases, an addon will also need to be configured on the Jira Instance if the Testing data needs to be migrated also. There are many addons available that are capable of handling test management and integrate seamlessly with Jira. As a result, your import of these items may look different depending on the addon chosen.
User Mapping - User accounts are similar between the two platforms. If the user account on the issue does not exist in Jira, then Jira will create the account on import. It is easier to run a report of users that do NOT exist in Jira and to create them without giving them access. This will create an Atlassian UserID for their account which can then be used in later steps.
Things to look out for
The migration itself will need to be done via CSV import. In order to do this, an export of data in CSV format by project is required.
Simple Export - VersionOne has limited capability with exporting issues and some of the information can only be gathered utilizing the API (like comments and attachments). Something to note is that the name of the field in the API is not necessarily the name of the field in UI. Some testing may be required to ensure you are gathering the intended data due to the naming differences. For example, the name of an Epic (or portfolio item in the UI) is actually called "Super.Name" in the API.
Links - Since projects are imported one at a time, some issues that are linked to other issues may not work because the other project does not exist yet. After the import of the other external project is complete, the linking can be done as an update import.
Comments - VersionOne comments are called "Conversations" and allow for threaded comments. Jira does not handle threaded comments, so this will be something to be aware of. For example, if a response to a thread appeared after a new thread was started, the comments are imported into Jira by date and time the comment was made, not necessarily keeping the threads together. So, while all conversations are imported into the comments in Jira, they may appear differently.
Attachments - VersionOne allows for Attachments with the same name to be present on an issue. Jira CSV importer may generate errors related to this, so a number will need to be appended to the file name of any attachments that share the same name on an issue. VersionOne also allows for "embedded images" in description and other fields. In Jira, if an image is pasted into a description, it will also be added as an attachment. This is not the case in VersionOne, and if embedded images exist, they will need to be pulled separate from standard attachments.
Comments and Attachments export - The export of comments and attachments will need to be modified slightly to accommodate Atlassian's import wizard. The UserID tied to the link in the CSV will need to be updated to the Atlassian UserID tied to the Jira account. This will ensure that the proper user is listed as the commenter or person who attached the file.
Assigning Issue Keys - This is by no means a necessary requirement, but can assist in simplifying the process greatly. By Adding an issue key to the CSV, issues can be easily identified for additional mappings. This will also aid in the process of adding Comments and Attachments since the issue that needs to be updated will already be identified.
Import in Phases - This isn't required but can greatly reduce the time it takes for an import to complete. Import the Issues and their mappings first, followed by their Comments, and lastly Attachments. It will provide a cleaner log to sift through and the ability to make adjustments. A file that only needs to map the Summary, Issue Key, and Attachments will be much smaller and easier to manage than one that needs to import everything. One important note with CSV import is that they need to be done one at a time, the ability to queue up another import after one completes is not available.
Automation - Automation Rules may need to be created to handle exceptions from the migration. For example, if a VersionOne project wasn't using resolutions and has closed issues, then updates may need to be made to ensure a clean set of data that is properly represented in Jira reports and dashboards.
Ready for Migration
After all of the preparations have been made, the steps to a successful migration are:
- Gather an Export of the project being migrated
- Confirm Atlassian UserIDs
- Map to the project
- Map issue fields and values
- Import the issues
- Save the Configuration file so that time can be saved for future mappings
- The configuration file will save ALL of the configurations (including intended project, statuses, resolutions, etc). It is useful for maintaining the mappings, but still needs to be reviewed before import begins.
- Review the logs for errors
- Import the comments
- Import the attachments
- Repeat if necessary
Conclusion
The migration of data from VersionOne to Jira is a large effort initiative that will require a good deal of work in terms of planning, preparation, and extraction of data. While the effort involved is great, the end results will prove to be a worthwhile investment. Once the migration is complete, users will have a tool that is easier to use, flexible, and allows greater visibility to data. Additional features in Jira are seen with improved performance, the ability to configure reporting, dashboards, boards, and overall save time by easily identifying the issues important to users will provide great value to the teams. Since this is a new tool for many VersionOne users, we recommend training to help the teams quickly adopt and leverage the Atlassian platform.
If you're looking for assistance in beginning your migration from VersionOne to Jira, look no further. Praecipio is an Atlassian Platinum Solution Partner with extensive knowledge and expertise with the Atlassian Product line and would be happy to help.
