In this video, we will show how OpsHub Azure DevOps Migrator. OpsHub migrates data from ADO Cloud to ADO Cloud. Here, we have the ADO source instance on the left and the ADIO target instance on the right. Currently, the target instance is empty. OADOM will seamlessly migrate the project from the source to the target instance with zero downtime and no data loss. Here, you can see, we have created a source instance by the name, “OpsHubDemoMigration” and several projects under this organization. You can find more information regarding the source incidents from the Organization settings option.
To create a project in cloud-to-cloud migrations, we first need to create a process template. OADOM will support the migration of all process templates. The “Web Development Project” is created under this custom process template, “AgileInherited”. Based on these process templates, we will create the projects in the target. Let’s go back to the web development project, which we will migrate from source to target. By clicking on the Project, you can view details added under the same as the description and members associated with it under project settings. In the Team section, you can view the list of teams created. You can create as many teams as you need. You can also assign members to the teams. This, too, can be customized as per your requirement.
Under the Project configuration option, we have created a hierarchy of iterations. Under Iterations, we have created several sprints, and under this sprint, we have created a child. Under the Areas configuration, we can see multiple parent-child hierarchies created. You can click on the Team configuration option to view iterations and areas.
Now let’s take a look at the project configurations. Under the Wiki section, we can see two kinds of options, Project wiki and Code wikis. Under the project wiki, we have created the “Web-Development wiki”. We have configured the web-development wiki with different configurations like meta links, hyperlinks, a table which includes the link reference and user mention, and inline image and screenshot. Let’s take a quick look at the Code wikis.
Moving to the work items to be migrated, we can see a list of work items which have been created by different teams. These are the work item types. OADOM will migrate all the data under the work items like the title, description in rich text formatting, inline image, links, attachments etc. In near to real-time, under Boards, we can see the Web Development Board and the UI Dev Board have been configured with settings related to boards like custom stream lanes, color-coded card rules and columns.
These other advanced settings in both, OADOM will migrate boards with all the configured settings from source to target. Under Sprints, we can see the capacity assigned to members of different teams. Under the Backend Dev team, all four members have been assigned per day capacity. Under the Repository option, we have created two repositories, pointing to the web development project with the name, Web Development and Backend Data. As of now, we will migrate only the Web Development repository to target. Here is the data regarding this web development repository.
Navigating to commits, the information regarding the commits will be reflected in this Commit tab. Under the Branches tab, you can see two branches that have been created. Under the web development repository, you can create custom branches as per requirement. OpsHub will migrate all repositories along with branches to the target. Under Pull Request, you can view information regarding the same.
We have also created a CI / CD pipeline in the source by the name Web Development CI under the Web Development project. By clicking on the edit button, you can see the information related to the Web Development CI pipeline like the name agent specification, agent job, etc. We can also create a custom variable related to the pipeline. Information regarding triggers is available under the Trigger section. You can customise the schedule trigger as per need. OADOM’s High fidelity migration will migrate all the data from source to target without any loss of context or downtime with full traceability. This completes part one of the demo where we showed all the information in the source system which will migrate to the target system using OpsHub Azure DevOps Migrator.
OADOM migrates data in 5 simple steps on the OADOM homepage. The first step is to provide the source end point and destination endpoint details. In the second step, you need to provide the migration details. Here, you can select the boxes, the data for which you want to migrate. In the third step, you need to select the projects which you want to migrate from source to target. Here, we will select the Web development project which was created in the source as shown in part one of the demo. You can select multiple projects at a time but make sure to have the same project name and template at both endpoints.
In the fourth step, you need to provide users for mapping. OADOM will map the users automatically where the display names are the same between the two systems. You can map the default user in the source with any user in the destination as per your project requirement. By clicking Next, you will navigate to the fifth step to view the migration validation summary and start the migration. The OADOM tool will validate the difference between the source and target process templates.
In the migration summary, we can see the project web development has been found in the target, and therefore, we can successfully migrate the data. Once the validation is complete, we will click on finish and the tool will automatically create the configuration. The configuration may take some time. Once the configuration is complete, we will click on Yes on the pop up to begin the migration.
The migration for meta entities is done, and therefore, the status is reflected as completed. The work items have started to migrate from source to target. You can see the status is running and the number of work items which have migrated successfully. The entire migration may take a few minutes. Finally, we can see the migration process has been completed in all the stages.
Now, let’s move to the target instance to verify the migrated data. With the source instance, we can see the web development project created in the source has migrated to the target. Let’s see if the custom process template created in the source has migrated to target. In the Organization setting under Process, we can see the Agile inherited process template in the source and target. The web development project under the custom process template has also migrated to target. We saw the recently migrated web development project.
Now, let’s check if all the details added under it have also been successfully migrated. We can see the exact description has migrated to target and so have the members assigned to the project. Under the wiki section, we can see both the wikis created in source have migrated to target.
The Web development Wiki created under the Project Wiki is successfully reflected in the target with the same details as the source. Here, we can see the migrated meta links, tables with link reference and user mention as well as the inline image, and screenshot. Similarly, we can see the code wiki has migrated from source to target with all its details.
Navigating to the work items which have migrated, the list of work items with the respective teams is available in the target. All the formatting and additions made to the work items in the source including the title, description in rich text formatting like bold and italics, inline image link, an attachment has migrated successfully.
Under Boards, we can see the UI Development Board with configured settings like custom stream lanes, color-coded card rules and columns have migrated from sourced to target under sprints. The capacity assigned to the backend dev team in the source is successfully reflected here in the target under the repository section. The web development repository has migrated with all the data added under it.
The information regarding the comments is also visible in the target. All the branches created in the source have also migrated successfully navigating to pipelines. The web development CI pipeline created in the source has migrated to target and so has all the configured information related to it like the name, agent specification, agent job, etc. The custom variables added to the pipeline in the source are also visible in the target. The information regarding triggers has also migrated to the target from the source.
The advanced configurations which have migrated from source to target are also visible under the Options tab under Project Settings in the Team section. The list of teams created in the source are visible now in the target post the migration under the team configuration option, we can see the migrated hierarchy of iterations and the area.
This completes the migration from Azure DevOps Services to Services using OpsHub Azure DevOps Migrator. OADOM also provides a flexible cutover by allowing users to sync additional delta to target after the migration is complete.
Thank you for watching this video.
