Jira to Azure DevOps Migration

So you’ve decided to migrate from Jira to Azure DevOps. Where should you start? You’ve done some research on migration methods and tools, but haven’t yet found one that checks all the boxes for your organization. PRAKTIK has you covered: We’ve developed a custom solution to move your issues from Jira to Azure DevOps.


Our solution is tailored to your specific needs. It can handle migration of labels to tags, multi-choice fields, attachments, and links. There is also a smart filtering of unused field values; that is, only active field values are migrated. The solution supports batch processing to avoid resource overload, and it can be restarted from a failure point. Furthermore, it includes state workflow mapping from Jira to Azure DevOps, as well as separate rules for each issue type. You want to convert the newest Jira Fix Version into an ADO Iteration? We can do that, too.

Jira to Azure DevOps Migration


Because we aim for maximum flexibility, custom coding is a must. To do this, we work with you to create a set of migration rules – mapping Jira issue types, fields, states, and link types to Azure DevOps. Next, we code that in and execute a dry-run migration. Your team can then validate and sign off, all without any impact to the existing system. This approach will ensure the final migration will run without a hitch.

This solution is the only one on the market that has been designed with the express purpose of large-volume migration of 10,000 items or more. To get started today or to speak with one of our experts, contact us here at PRAKTIK.

How to Migrate Azure DevOps Projects to a Different Organization

The problem

At present, migrating projects from one organization to another is not supported in Azure DevOps. The workarounds can be arduous, with less-than-perfect results. For instance, if you just need to migrate your repo, you could simply use the built-in clone functions. You could also choose to export your data from Excel,but that option means you lose your history. Alternately, there are third-party tools such as Migration Tools for Azure DevOps and OpsHub, but these tools are not meant for a full, high-fidelity migration.

The solution

What you really need is a high-fidelity way to migrate all your project data – including all historical information – from one instance to another. Luckily, PRAKTIK has you covered.

By utilizing the Azure DevOps REST API, we’ve created a tool that will allow you to take all of your project data and move it from one organization to another. You can move one project, just a few, or all of your projects; the choice is yours. You’ll keep your history, your build and release definitions, your source code, test information, and everything in between. The only thing that will appear different is your work item IDs. However, the original IDs can still be viewed.

To implement this at your organization, we will run a full dry run so that you can run tests and complete any validation requirements. Migration options including moving projects from a collection on-premises to an organization in the cloud; from one organization to another in the cloud; from one collection to another on-premises; or from an organization in the cloud to a collection on-premises.

To get started with your own high-fidelity migration, or to speak with an expert, contact us at PRAKTIK today.

Integrate Microsoft Teams with Azure DevOps

Microsoft Teams is a tool for team collaboration in Office 365. It goes far beyond a simple chat or video call client. This tool also helps enable teamwork with application integration and file sharing. This has become especially important in today’s world with more and more people looking for ways to effectively work from home.

When Azure DevOps is integrated with Microsoft Teams, you have a comprehensive collaboration experience across the full development lifecycle. Team members will be able to stay on top of projects with an array of notifications on actions such as pull requests and commits.

Getting Started

To integrate your Azure DevOps with Microsoft Teams, you’ll need an Office 365 account. If you don’t have one, you can sign up for a free trial here. Additionally, only Azure DevOps organizations in the same AAD tenant can be used to integrate with your Teams account. You will also need to have a team created within Microsoft Teams. For a step-by-step walkthrough, check out this blog.



To get started with the integration, you’ll need to add a connector to your team channel. A connector allows your team to get content and updates from different services, including Twitter, GitHub, and, of course, Azure DevOps. After adding the connector, you’ll be prompted to configure it by selecting your organization, team, and project.

After your connector is configured, you can further customize how your Microsoft Teams channel shows Azure DevOps data. For example, you’re able to display your Kanban Board or even monitor your Azure Pipeline with a bot. This means you’ll be able to do more work from one single place instead of navigating through a bunch of different apps.

For more information, or to get started with your own Teams-Azure DevOps integration, contact us at PRAKTIK today.

Automated Oracle Integration Deployment with Azure DevOps

Oracle Integration is a service that allows you to integrate your cloud and on-premises applications, automate processes, and develop visual applications. This service is built to be integrated with other tools. This integration can be done using pre-built adapters, or by leveraging its API. Using this integration capability, PRAKTIK has developed a tool to help you export your data from the Oracle Integration Cloud to Azure DevOps to take advantage of source control.

The Flow

This tool uses actions you’re already familiar with. You’ll start by exporting your code from the Development environment in the Oracle Cloud to an Azure Repo to be committed and versioned. Then, you’ll get a notification for approval. After it is approved, the code is imported into your next environment within the Oracle Cloud. Before each import into a new environment, an approval notification will be sent. Finally, it is imported into your Production environment back in Oracle where it will run.


How It Works

This tool leverages the Oracle Cloud Infrastructure API to connect the Oracle Cloud to Azure DevOps. To use the tool, a developer will simply initiate a release. The data from Oracle Cloud is then pushed using Git to an environment in Azure DevOps as an IAR file. There, you can see the history of your application and compare changes more readily.

In Azure DevOps, your pipeline is fully customizable to your needs. You can even have an environment to roll back any unwanted changes.

Getting Started

The only pieces of information you need to begin are the URL to your Oracle Cloud and the login information for it. After that, the tool does the rest. For more information or to get started today, contact us here at PRAKTIK.

Azure Pipelines: YAML or Classic UI?

When creating an Azure Pipeline, you’re given the option to use YAML or to use the classic editor. YAML is a relatively new option, but should you choose it simply because its new? Which experience is truly the best choice for you?


YAML is a data serialization language that is designed to be human-friendly. That is, it presents data in such a way that people can read and understand it. YAML also works well with other programming languages. Full documentation on YAML can be found on its official site.

When using this option, you’ll define your CI/CD strategy and your Pipeline definition as code. Because the YAML file is just a text file, you’re able to take advantage of things like pull requests, history, and code reviews, just as you would with the rest of your application. Additionally, the fact that it is a text file makes it much easier to share between team members for collaboration. There is also an Azure Pipelines extension for VS Code. This extension can help you out by adding syntax highlighting and autocompletion for your YAML file.

Classic UI

The Classic UI is the graphic user interface we all know. Using this option, you’ll create and configure your build and release pipelines in the Azure DevOps web portal. Your build pipeline will create an artifact that can be used to run tasks such as deployment to staging or production environments.

The Classic UI is familiar, and less intimidating at first glance than YAML. It doesn’t require you to write, test, or debug a text file. There is no domain-specific language, which lessens the learning curve, especially for those not coming from a development background. The UI is being deprecated, but you do have the ability to convert to YAML.


Another factor that should be considered when deciding between YAML and the Classic UI is the features that are available with each method. For instance, the Classic editor does not support container jobs, but the YAML editor does. Similarly, the Classic editor supports gates, but the YAML editor does not. For a full list of pipeline feature availability, see the Docs.

To get started, or for more information about Azure Pipelines, contact our experts here at PRAKTIK today.

Automated BizTalk Deployment

BizTalk Server, otherwise referred to simply as BizTalk, is a middleware product used to connect various systems. For example, you might be using a different system for your HR, your finances, and your CRM system. BizTalk sits in the middle of everything, making sure each tool is able to communicate and work together.

Deployment Framework for BizTalk

The deployment framework for BizTalk, or BTDF, is an Azure DevOps extension that facilitates the deployment and configuration of BizTalk applications. The tasks available in this extension include deployment, undeployment, and installing an MSI. BTDF does not build BizTalk applications, but it does eliminate all manual steps and human intervention in your deployment. The deploy/undeploy tasks in this extension require artifacts built using the BTDF Visual Studio extension. This VS extension can also help increase developer productivity with tools such as binding file management.

Automatic Deployment

Historically, deploying BizTalk solutions has been somewhat of a pain. The Deployment Framework for BizTalk extension for Azure DevOps and Azure DevOps Server will enable automatic deployment of your solution into all the environments in your release pipeline. These automated deployments can be made into a native part of your BizTalk development lifecycle.

To get started, or for more information on the Deployment Framework for BizTalk extensions, contact us here at PRAKTIK today.

Azure DevOps Server 2019 Update 1.1

Update 1.1 for Azure DevOps Server 2019 is a roll up of bug fixes and security patches. This includes any patches put out prior to this update. Three major pain points that have been fixed in this release are Elasticsearch failures, high memory usage and collection sorting.

Collection Sorting

Prior to Update 1, project collections were sorted alphabetically. However, the sorting appeared to be random after the update. This made it difficult for teams with multiple collections to find what they were looking for. Update 1.1 put out a fix for this, bringing back the alphabetical sorting.

High Memory Usage

After installing Update 1, many noticed that Azure DevOps Server appeared to slow down significantly. This affected processes such as the web portal and even simple folder navigation. Those experiencing this problem noticed the slowdown was due to very high memory usage. One user noted that their memory usage was over 90%. For some, this also presented a financial problem: adding memory to cope with this higher usage would come at a cost. Fortunately, Update 1.1 has remedied this issue.

Elasticsearch Failures

Elasticsearch is an open-source, distributed search and analytics engine. It has many use cases, including for application search, enterprise search, and log analytics. Prior to this update, some received an error when setting up Elasticsearch: "User not authorized." Still others experienced indexing and query failures when upgrading from TFS 2018 Update 2 or newer. Update 1.1 resolved both of these issues.

For more information on Azure DevOps Server Update 1.1, or to speak to an expert about troubleshooting or installation, contact us here at PRAKTIK today.

Azure DevOps Services vs. Azure DevOps Server

Azure DevOps Services and Azure DevOps Server – formerly called Visual Studio Team Services and Team Foundation Server, respectively – are two separate but similar development tools. They can help with planning, versioning, and even deploying your code. Azure DevOps Services is a cloud offering. It is scalable, reliable, and globally available. It is also backed by a 99.9% SLA and is monitored around the clock. Azure DevOps Server is the on-premises sibling of Azure DevOps Services. Companies choose this option when they need to keep their data within their own network, or to take advantage of SQL Server reporting services. While both tools offer the same necessary resources, there are a few fundamental differences to consider when deciding which is right for you.

SQL Server Reporting

One difference between the cloud and on-premises versions of Azure DevOps is SQL Server Analysis Services. This data reporting service supplies data models for business reports and applications such as Power BI and Excel. SSAS is installed as an on-premises server instance and supports tabular models at all compatibility levels. At the time of this writing, SQL Server Analysis Services are only available in Azure DevOps Server.


Scope and Scale

Azure DevOps Services scales in two ways: by organization and by project. Organizations have their own unique URL, and they all have one project collection. Each method has scenarios in which they are more successful. For instance, having one organization with many projects is useful when different efforts require different processes. On the other hand, Azure DevOps Server scales in three different ways: by deployments, by project collections, and by projects. For more about the methods of scale and how to plan your organizational structure, see the documentation.


When using Azure DevOps Services, authentication is done over the public internet with Microsoft account credentials or Azure Active Directory credentials. If using Azure AD, you can also require multi-factor authentication or IP address restriction. When using Azure DevOps Server, you connect to an intranet server. You can use Windows Authentication and AD domain credentials for authentication.

These are just a few differences between Azure DevOps Services and Azure DevOps Server. Additional details and examples can be found here.

For more information, or to get started with a migration, contact our team here at PRAKTIK.

GitHub Actions

Earlier this year, GitHub announced that Actions were publicly available. Actions in GitHub are individual tasks that interact with your repository. This interaction can be anything, including integrating with a public API to sending SMS alerts when urgent issues are created. Actions can be combined to create jobs and customize workflow. Furthermore, you can create your own actions, or you can customize actions created and shared by others in the community, like these for Azure.

Types of Actions

There are two types of actions: Docker container actions and JavaScript actions. A Docker container allows you to specify OS versions, dependencies, and tools. Therefore, for actions that require a specific environment configuration, Docker is ideal. JavaScript actions, on the other hand, can run directly on a machine. Using a JavaScript action simplifies the action code and thus executes faster than a Docker container action.

Understanding Differences

Understanding the differences between various tools is key to being efficient and effective in your efforts. GitHub Actions and GitHub Apps, for instance, both provide ways to build automation, but each has qualities that make them efficient in differing scenarios. GitHub Actions provide automation to enable CI and CD and can run directly on a runner machine or in a Docker container. They also don’t require you to deploy code. Conversely, GitHub Apps perform well when persistent data is needed and are best suited to API requests that aren’t time-consuming. Additionally, they run on a server or infrastructure provided by the user.

To get started with GitHub Actions or to speak with an expert, contact us here at PRAKTIK.

Easy SQL and SSIS Deployments with Azure DevOps

If you’ve ever tried to jump into using Git, you know how steep the learning curve is. With terms like “rebase,” “branch,” and “fork,” it can be overwhelming. In fact, this learning curve sometimes dissuades teams from migrating to Azure DevOps or even using Git at all. Git can be extremely powerful, but that power is lost if you simply don’t know how to use it. That’s where our custom deployment tool comes in. This tool takes out the Git learning curve and allows you to take advantage of the power of Git and Azure DevOps with the push of a button.

For instance, let’s say you’re on an IT team that does database deployment. There are 40 DBAs deploying SQL and SSIS package changes into production on demand. Additionally, you have developers that do not combine changes into one release; they simply release into production on their own without any kind of release schedule. Clearly, there needs to be a way to audit what goes into production.

You’ve been tasked with configuring a third-party application for your development team, and you want to do this using SQL. In the past, deployments have been handled via emails between analysts and DBAs.

Now, things have changed. After our tool is installed and customized, all you’ll need to do is upload your SQL scripts to Git using the UI. To do this, select the script you wish to upload, and decide where you want to deploy it.

Then, give it a release description in the text box and click submit. This action opens up Azure DevOps, where you can see the release. 

That’s it! You’ve successfully released your change into the environment of your choosing. You can also enable pre-deployment approvals so that releases don’t move into production unchecked.

This custom deployment tool allows you to take advantage of Git concepts and traceability without having to become an expert. The Azure DevOps Audit Trail is also augmented with copies of every script that ran in every environment. The purpose of Git is to manage a project as it changes over time, and this extension helps you do just that.

To get started, or for a free consultation of our other services, contact us here at PRAKTIK today.