Keep Your Data Safe with PRAKTIK

Adobe. Equifax. Marriott. These are major, global, well-known companies. What do they all have in common? They have all experienced major data privacy breaches that have left sensitive customer data exposed. These data breaches cost these companies millions of dollars to rectify: Adobe paid a $1 million settlement, Marriot faced a $124 million fine, and Equifax paid an over $650 million settlement.

As important as data security is to the customer, it is even more important for companies that store this sensitive information. One of the biggest questions that comes with using the cloud is, “Is it secure?” In response, cloud providers are as transparent as possible with their security and compliance portfolios. However, this still means that anyone transmitting or storing customer data must be up to date with regional regulations.

Globally, there are varying data residency and privacy regulations. Data privacy refers to a specific kind of privacy regarding personal data. Data residency regulations pertain to where this private data and metadata can be stored in the world, as well as how the data can travel across geographies. There are also different agencies and laws that enforce these regulations, from the European Union’s General Data Protection Agency (GDPR) to California’s Consumer Privacy Act (CCPA).

This feels a little overwhelming, right? Of course you want to protect your customer’s data, and you want to do it the right way. Luckily, PRAKTIK can do this for you. We are up-to-date on global data residency and privacy regulations affecting Azure DevOps so you don’t have to worry about it. Do you deploy to TEST and UAT environments that have customer data? Do you need to move your Azure DevOps instance across geographies? No problem – we can help, and make sure you remain compliant with data privacy regulations.

Want to learn more or get started? Contact our team of experts today for a consultation.




Migrate to Azure DevOps Services from Azure DevOps Server or TFS

Azure DevOps is the cloud-based sibling of Azure DevOps Server. Simply put, it’s everything you know and love about the on-premises solution with none of the maintenance. With Azure DevOps, you’ll have access to the latest features every three weeks. The features are scalable, reliable, and available wherever you need them. Furthermore, when you choose to make the switch from on-premises to the cloud, you can take your data with you – your work item numbers, Git commit IDs, and much more will remain exactly the same.

Azure DevOps Migration Process

With PRAKTIK in charge, the migration process takes place across a 2 to 6 week period. We will clone the on-premises instance, which allows us to work on the upgrade without any impact for your teams. We will then perform a dry-run migration so that you can run any tests and validate the migrated instance. The live migration will occur on a weekend, which means minimal downtime. We will also provide targeted user training to cover standard use cases of the new platform. Furthermore, we will work directly with Microsoft to resolve any issues that may arise with the migration.

Upgrade Support

One of the most important prerequisites for this migration is ensuring your database schema version is as close as possible to that of Azure DevOps. Therefore, if you are currently running a version of Team Foundation Server, you must first be upgraded to a supported version of Azure DevOps Server. PRAKTIK will take care of this for you, handling on-premises version upgrades from TFS 2005 and up.

Contact our team of experts to begin planning your migration today.

Cut costs with Azure DevOps License Management

An Azure DevOps license is an important tool in your developer’s toolbox. In fact, in some cases, it is the toolbox. To make sure your developers have this tool, they’ll need a Visual Studio Subscription or an Azure DevOps license. To ensure you’re not overpaying and that your developers are equipped to do their best work, PRAKTIK is offering an Azure DevOps License Management service.

Are you Overpaying?

Oftentimes, companies end up overpaying for their developer tools. This can stem from a variety of factors. Maybe paid users have left the company, but their subscription is still active and assigned to them. It is also possible some users have a higher license subscription than is needed, or they have unnecessary paid features. Or, maybe some users have licenses for each individual instance of Azure DevOps, as opposed to one license across the organization. For companies with hundreds of developers, any one of these factors can lead to spending thousands of dollars a month more than necessary.

Benefits of License Management

PRAKTIK can prevent these factors from affecting you by reviewing and updating the Azure DevOps licensing across your organization on a monthly basis. This can bring about major cost savings and cost avoidance for your company – up to 25%. With License Management, you will be able to identify actual software usage. This allows for the elimination of unused software and consolidation of software licenses. Better visibility into your license usage means you only buy what you need, rather than having too many licenses instead of repurposing existing unused licenses. For instance, in the below screenshot, there is a subscription that hasn’t been accessed since 2018. This is a perfect candidate for redistribution or deprovisioning.

Better visibility into software usage also means gaining better license coordination. Any license transfer, acquisition, or disposal becomes easy and efficient. You’re also ensuring your company doesn’t violate compliance terms. Furthermore, this insight into usage will allow for a more accurate IT budget moving forward.

For more information about Azure DevOps License Management, or to speak to an expert, contact us at PRAKTIK today.



Separation of Duties in Azure DevOps

DevOps is the union of people, process, and products to enable continuous delivery of value to our end users. One of the cornerstones of this concept is breaking down the walls between development and operations teams. This helps enable the teams to work together more efficiently to deliver value. However, this doesn’t mean that there is no separation of duties within DevOps. In fact, there are several scenarios in which this separation is vital. This can be a tricky balance to strike. Luckily, PRAKTIK can act as a third party to manage your Azure DevOps and ensure this separation of duties is maintained.

Development and Testing

On a DevOps team, both development and operations must work together to meet the acceptance criteria set by the product owner. For security purposes, development should not be able to release directly into production. Similarly, they should not have access to confidential production data. This is where separation of duties comes in. Operations teams are responsible for creating tests that allow aspects such as performance and security to be evaluated before code is released into the production environment. This can be automated using CI/CD for further fidelity in your deployments.

Management by PRAKTIK

It's important to maintain control over which responsibilities belong to whom. However, this can quickly become complicated. This is where PRAKTIK can step in. We can act as an independent third party to manage your pipelines and safeguard audit data for all releases. This pipeline management can be ensured using gates that must be approved by us before your code is released into the next environment of your pipeline.

It is important to get auditors working with your development and operations teams as soon as possible to ensure a seamless flow from the development, to testing, and all the way to your end product. For more information or to speak to an expert, contact us here at PRAKTIK.

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 (with a few exceptions) – 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 work item and GIT source code history, your build and release definitions, 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.