Migration approaches for BizTalk Server to Azure Logic Apps

This guide covers migration strategies and resources along with planning considerations and best practices to help you deliver successful migration solutions.

Strategy options

The following sections describe various migration strategies along with their benefits and disadvantages:

Big bang

A "big bang" or "direct changeover" is an approach that requires lots of planning and isn't recommended for organizations that are unfamiliar with Azure Logic Apps or that have large systems or solutions to migrate. When an organization implements a new technology stack, new learnings usually often result. By investing too early or too much, you won't have the opportunity to benefit from lessons learned and adjust without risking significant rework.

This approach might also take longer to reap or accrue value. If you've already completed some migration activities, but you haven't yet released them into production due to other pending or in-progress work, your migrated artifacts aren't generating value for your organization.

We recommend that you consider this approach only if you have small, low complexity BizTalk workloads, subject matter experts (SMEs) who know your BizTalk environment, and direct mappings between the BizTalk features that you currently use and Azure Logic Apps. Experience with Azure Logic Apps also considerably reduces the risks with following this approach.

Iterative or wave based (Recommended)

This approach provides the opportunity for your organization to incrementally achieve value, but sooner than they might otherwise. Your project team can learn about the technology stack early by using retrospectives. For example, you can deploy an existing BizTalk interface or project to production and then learn about the solution's needs, which include management, scalability, operations, and monitoring. After you gain this knowledge, you can plan sprints to optimize existing capabilities or introduce new patterns that you can subsequently use in future work.

Regardless of your approach, if you plan on moving to Azure Logic Apps or Azure in general, strongly consider refactoring your BizTalk Server solutions into serverless or cloud-native solutions before you decommission your server infrastructure. This choice is an excellent strategy if your organization wants to transform the business completely to the cloud.

BizTalk Server and Azure Logic Apps have different architectures. To further modernize your solutions, you can use Azure Integration Services to extend the capabilities in Azure Logic Apps that address core customer integration needs.

For a higher return on investment (ROI), we recommend that any BizTalk migration use the core native capabilities in Azure Logic Apps (Standard) as much as possible and extended with other Azure Integration Services as needed. This combination makes additional scenarios possible, for example:

• Cloud native hybrid capabilities with Azure Logic Apps (Standard) with hybrid deployment
• Stateful or stateless workflow capabilities in Azure Logic Apps (Standard)
• Native, built-in (in-app) mainframe and midranges integration with connectors in Azure Logic Apps (Standard)
• Pub-sub messaging using Azure Service Bus
• Advanced SOAP capabilities in Azure API Management

Deliver a BizTalk migration project

To complete such a project, we recommend that you follow the iterative or wave-based approach and use the Scrum process. While Scrum doesn't include a Sprint Zero (Sprint 0) concept for pre-sprint activities, we recommend that you focus your first sprint on team alignment and technical discovery. After Sprint 0, follow the execution of multiple migration sprints and focus on releasing features towards a minimum viable product (MVP).

Sprint 0

During this sprint, we recommend that you execute BizTalk Server Environments Discovery with Waves Planning. Understanding the project's breadth and depth is critical for success. The following list includes the specific areas to address during Sprint 0:

Area	Description
Discovery	Capture data about all your interfaces and applications so you can learn the number of interfaces and applications that you need to migrate. You also need to assign complexity to each interface or process. During this cataloging process, collect the following information to prioritize work: - Adapters in use - BizTalk Server features in use, such as Business Activity Monitoring, Business Rules Engine, EDI, and so on - Custom code, such as expressions, maps, and pipeline components - Message throughput - Message sizes - Dependencies - Application and system dependencies
Architecture design	Create the high-level architecture to use as the focal point for the migration. This design includes elements that address high-level functional and non-functional needs.
Minimum viable product (MVP) definition	Define the first wave features. In other words, the processes that need support after you complete the first wave.
Initial migration backlog	Define the first wave features and their work items with technical elaboration.

Discovery tools

To help you with migration discovery, you can use the Azure Integration Migrator command-line tool, also called the BizTalk Migration tool, which is a Microsoft open-source project. This tool uses a phased approach to help you uncover useful insights and strategies for migrating your solutions to the cloud. We recommend using the migrator tool only for discovery and report generation. You might also want to consider using other products for discovery from partners who provide solutions in this space.

For another way to generate an inventory with BizTalk Server elements, you can use The BizTalk Documenter, which is developed by Mark Brimble. This tool works with BizTalk Server 2020, despite stating that only BizTalk Server 2016 is supported.

1. Discover

   Pulls BizTalk Server resources and identifies the BizTalk artifacts to migrate. Reads the assemblies and binding file information.

   Requirements: The MSI for the Biztalk Server application and all referenced BizTalk Server applications

2. Parse

   Reads the BizTalk Server artifacts and builds a source data model for the BizTalk Server application.

3. Analyze

   Builds an Azure Integration Services target data model using the source data model from the Parse stage. Basically, the tool reviews the BizTalk Server resources, identifies which items can migrate, and builds a data model of the Azure Integration Services target. 

4. Report

   Generates a report that outlines the found BizTalk Server resources and the items that can migrate. The report also contains detailed information about the contents in the source and target applications along with details about any potential problems with the conversion.

5. Convert

   Generates Azure Manager Resource templates and Azure CLI scripts that you can use to build the applications in Azure by using the target data model.

6. Verify

   This phase isn't currently built into the tool, but you run the installation scripts to deploy your application to Azure. You can then assess whether the generated application provides the same functionality as your BizTalk Server on-premises application.

The following diagram shows the phases that the Azure Integration Migrator tool runs through:

Key team roles and skills for successful migration

To successfully migrate integration workflows from BizTalk Server to Azure Integration Services, establish a team that has the following important roles and skills, which span multiple disciplines:

Role	Skills
Project managers	Accountable for leading the overall project and delivers the agreed-upon scope within the boundaries for time and budget.
Scrum leader	Actively manages the backlog and facilitates prioritization for the project's activities.
Architects	Make sure that the project aligns with enterprise architectural principles and provide guidance about how to navigate uncertainty and roadblocks.
Developers	Actively work on migrating components from BizTalk Server to Azure Integration Services.
Quality assurance testers	Create test plans and execute testing against those plans. Track, communicate, and triage bugs and defects as part of project sprint planning.
User acceptance testers (UAT)	Provide the business stakeholders who help make sure no regressions are introduced by moving interfaces from an existing platform to a new platform.
Change management specialists	Assess the impact on existing processes and roles. Build a plan to help mitigate any perceived issues before they emerge.

To help provide some or all the resources previously described, consider partners who have experience with performing migrations. As team members, they can help reduce risk, improve time to market, and make the project more predictable with their skill sets and expertise.

Build process planning

For build planning, Microsoft recommends that you include sprints and work items to handle foundational services, such as authentication, logging, exception handling, and so on. This inclusion helps avoid rework later in development cycles caused by not addressing underlying needs. You also want to avoid blocked developers due to decisions that require other stakeholders to make.

The following list covers only some areas to consider:

Area	Description
Authentication	Address the following questions and others about authentication before you get too deep into development cycles. - Does your organization have any standards around authentication schemes? - Can you use managed identities and service principals in Azure? - Are basic authentication and API keys permitted or not? This activity can be a good opportunity to bring in your enterprise architects who can make sure to get clear agreements about which authentication schemes to use.
Logging	Consider collecting and store telemetry in a centralized data repository, which is a popular pattern that integration solutions use. For example, Azure Logic Apps (Standard) can push telemetry to Application Insights in Azure Monitor. Azure Logic Apps (Consumption) can push telemetry to Log Analytics, also in Azure Monitor. You can also include tracked properties so that developers can include more context as messages flow through the integration platform. For example, this data might include work order numbers, purchase order information, or anything else that might be useful, helpful, and relevant for your organization. Arguably, each organization's solution might differ, based on the organization's needs. For example, some organizations want full control over what and when data gets logged. In this scenario, you might create APIs or custom connectors, and then instrument your code based on specific milestones. Regardless which approach you choose, make sure that your developers clearly understand expectations to avoid future rework.
Exception Handling	Address having a strategy and consistent pattern early to handle exceptions and errors to avoid future rework. Make sure to create clarity around this area early before creating any logic apps. The following list includes some questions to answer when you address exception handling: - How will you use scopes and "Run after" settings to detect exceptions? - How can you use the result() expression to better understand where an exception happens in a workflow and to find more information about the underlying root cause? - After you choose how to catch exceptions, how do you want to log this data and communicate to stakeholders? Make sure these decisions align with your logging strategy as previously mentioned. Ideally, you've established a process that actively looks for new error events in your logging data store. From there, you can respond to these events and orchestrate an exception process. You might have to filter out or aggregate duplicate error events, log a ticket in your organization's IT Service Management solution, and choose how to send notifications. You might have different paths for notifications, based upon issue severity and time of day. You can achieve agility by building a workflow to manage this process.
Analytics	To demonstrate your solution's overall health and hygiene to your stakeholders, consider the different lenses that your stakeholders use to look through, for example: - Executives might be more interested in overall health, transaction counts or volume, and the business value that those transactions generate, but not overall technical nuances. - A frontline manager might be more interested in overall health but could also become interested in technical details, such as performance characteristics, to make sure that SLAs are met. - Support analysts are likely interested in overall service health, exceptions, and performance bottlenecks. While you put together your analytics strategy, consider your stakeholders and the type of data that interests them. This thought process helps you make sure that you track useful and helpful information and make that data accessible for reporting purposes. If you find coverage gaps, you might have to revisit your logging-related work items, and add appropriate tasks to address these gaps.
Cadence	When you ship your integration projects and learn from those experiences, make sure to capture the lessons that inevitably emerge. Plan remediation sprints or cycles early in your journey so you can correct course early, before the cost becomes too great. That way, you can avoid introducing too much technical debt into your new platform.

Deployment planning

When you anticipate and prepare a deployment plan, you increase your opportunities for a successful deployment. With BizTalk Server, after you created all the infrastructure and environments, you shifted focus to solution deployment.

With Azure, this experience differs with some activities to consider first, such as addressing infrastructure deployment between different environments, which can include different Azure subscriptions, Azure resource groups, or some combination, for example:

• Azure Key Vault: secrets and access policies
• Azure Service Bus: queues, topics, subscriptions, filters, and access policies
• Azure App Service: plans, networking, and authentication

You can then subsequently focus on solution deployment between different environments.

Test planning

To make sure that your stakeholders are satisfied with the solution that you're providing, testing is important to consider for any migration project. A new solution should provide more value compared to the previous solution, without any regressions that might impact the business.

Consider the following testing recommendations for your migration project:

• Establish your baseline by answering the following questions:

  1. Do you have existing tests?
  2. Do the tests run without errors?
  3. Are the test results accurate?

  To have confidence that your team hasn't introduced regressions, you need the capability to compare results from the new platform against reliable tests from your existing platform. So, if you don't have a baseline, make sure to establish one.

  Naturally, you don't want to spend many resources establishing tests against a platform that's retiring, but you need to answer the question, "How do I know everything works successfully?" If you're in this situation, start establishing your baseline based on priorities and create a plan to mitigate areas where you have gaps.

• Set up your test strategy for the new platform.

  Assuming that you're comfortable with your baseline, you can now think about how you to test on your new platform. If you had trouble establishing your baseline, take the opportunity to set up a strong foundation for your new platform.

  When you think about testing for your new platform, keep automation top of mind. Although having a platform allows you to quickly build interfaces, relying on manual tests erodes those productivity gains.

• Automate your tests.

  Azure Logic Apps (Standard) includes the capability to perform automated testing. The following list includes more information and resources that are freely available on GitHub:

  • Automated testing with Azure Logic Apps (Standard) from the Azure Logic Apps team

    With Azure Logic Apps (Standard), automated testing is no longer difficult to perform, due to the underlying architecture, which is based on the Azure Functions runtime and can run anywhere that Azure Functions can run. You can write tests for workflows that run locally or in a CI/CD pipeline. For more information, see the sample project for the Azure Logic Apps Test Framework.

    This test framework includes the following capabilities:

    • Write automated tests for end-to-end functionality in Azure Logic Apps.
    • Perform fine-grained validation at the workflow run and action levels.
    • Check tests into a Git repo and run either locally or within CI/CD pipelines.
    • Mock testing capabilities for HTTP actions and Azure connectors.
    • Configure tests to use different setting values from production.

  • Integration Playbook: Logic Apps Standard Testing from Michael Stephenson, Microsoft MVP

    The Integration Playbook testing framework builds on the Microsoft-provided test framework and supports additional scenarios:

    • Connect to a workflow in a Standard logic app.
    • Get the callback URL so that you can trigger the workflow from a test.
    • Check the results from the workflow run.
    • Check the operation inputs and outputs from the workflow's run history.
    • Plug into automated testing frameworks that logic app developers might use.
    • Plug into SpecFlow to support behavior-driven-development (BDD) for logic apps.

  Regardless which automation approaches or resources that you use, you're well on your way to having repeatable, consistent, and automated integration tests.

• Set up mock response testing using static results.

  Regardless whether you set up automated tests, you can use the static results capability in Azure Logic Apps to temporarily set mock responses at the action level. This functionality lets you emulate the behavior from a specific system that you want to call. You can then perform some initial testing in isolation and reduce the amount of data that you'd create in line of business systems.

• Run side by side tests.

  Ideally, you already have baseline integration tests for your BizTalk Server environment and established automated tests for Azure Logic Apps. You can then run tests side-by-side in a way that helps you check your interfaces by using the same data sets and improve overall test accuracy.

Release to production

After your team finishes and meets the "definition of done" for the User Stories, consider the following tasks:

1. Create a communication plan for your release to production.

2. Make a "cut-over" plan.

   A cut-over plan covers the details about the tasks and activities necessary to switch from the current platform to the new platform, including the steps that your team plans to execute. Include the following considerations in your cut-over plan:

   • Prerequisite steps
   • Dress rehearsal
   • People
   • Schedule estimates
   • Disabling interfaces in the old platform
   • Enabling interfaces in the new platform
   • Validation testing

3. Determine a rollback plan.

4. Run validation testing.

5. Plan for operations or production support.

6. Choose "go or no go" criteria for releasing to production.

7. Celebrate your team's success.

8. Hold a retrospective.

Best practices for a BizTalk migration

While best practices might vary across organizations, consider a conscious effort to promote consistency, which helps reduce unnecessary efforts that "reinvent the wheel" and the redundancy of similar common components. When you help enable reusability, your organization can more quickly build interfaces that become easier to support. Time to market is a key enabler for digital transformation, so a top priority is reducing unnecessary friction for developers and support teams.

When you establish your own best practices, consider aligning with the following guidance:

General naming conventions for Azure resources

Make sure to set up and consistently apply good naming conventions across all Azure resources from resource groups to each resource type. To lay a solid foundation for discoverability and supportability, a good naming convention communicates purpose. The most important point for naming conventions is that you have them, and that your organization understands them. Every organization has nuances that they might have to take into account.

For guidance around this practice, review the following Microsoft recommendations and resources:

• Abbreviation examples for Azure resources
• Azure Naming Tool, which generates Azure-compliant names, helps you standardize on names, and automates your naming process.

Naming conventions for Azure Logic Apps resources

The design for your logic app and workflow provides a key starting point because this area provides flexibility for developers to create unique names.

Logic app resource names

To differentiate between Consumption and Standard logic app resources, you can use different abbreviations, for example:

• Consumption: LACon
• Standard: LAStd

From an organizational perspective, you might design a naming pattern that includes the business unit, department, application, and optionally, the deployment environment, such as DEV, UAT, PROD, and so on, for example:

LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>

Suppose you have a Standard logic app in development that implements workflows for the HR department in the Corporate Services business unit. You might name the logic app resource LAStd-CorporateServices-HR-DEV, and use Pascal Case notation where appropriate for consistency.

Logic app workflow names

A Consumption logic app resource always maps to only one workflow, so you only need a single name. A Standard logic app resource can include multiple workflows, so design a naming convention that you can also apply to member workflows. For these workflows, consider a naming convention based on the process name, for example:

Process-<*process-name*>

So, if you had a workflow that implements employee onboarding tasks, such as creating an employee record, you might name the workflow Process-EmployeeOnboarding.

Here are more considerations for designing your workflow naming convention:

• Follow the parent-child pattern for workflows where you want to highlight some relationship between one or more workflows.
• Take into account whether a workflow publishes or consumes a message.

Workflow operation names

When you add a trigger or action to your workflow, the designer automatically assigns the default generic name for that operation. However, operation names must be unique within your workflow, so the designer appends sequential numerical suffixes on subsequent operation instances, which makes readability and deciphering the developer's original intent difficult.

To make operation names more meaningful and easier to understand, you can add a brief task descriptor after the default text and use Pascal Case notation for consistency. For example, for the Parse JSON action, you can use a name such as Parse JSON-ChangeEmployeeRecord. With this approach or other similar approaches, you'll continue to remember that the action is Parse JSON and the action's specific purpose. So, if you need to use this action's outputs later in downstream workflow actions, you can more easily identify and find those outputs.

To avoid later possible rework and problems around downstream dependencies, which are created when you use operation outputs, rename your operations immediately when you add them to your workflow. Usually, downstream actions are automatically updated when you rename an operation. However, Azure Logic Apps doesn't automatically rename custom expressions that you created before you perform the rename.

Connection names

When you create a connection in your workflow, the underlying connection resource automatically gets a generic name, such as sql or office365. Like operation names, connection names must also be unique. Subsequent connections with the same type get a sequential numerical suffix, for example, sql-1, sql-2, and so on. Such names don't provide any context, which makes differentiating and mapping connections to their workflows extremely challenging, especially for developers who don't know the solution space and have to maintain these workflows.

So, meaningful and consistent connection names are important for the following reasons:

• Readability
• Easier knowledge transfer and supportability
• Governance

Again, having a naming convention is critical, although the format isn't overly important. For example, you can use the following pattern as a guideline:

CN-<*connector-name*>-<*logic-app-or-workflow-name*>

As a concrete example, you might rename a Service Bus connection in an OrderQueue logic app workflow with CN-ServiceBus-OrderQueue as the new name. For more information, see the Turbo360 (Formerly Serverless360) blog post, Logic app best practices, tips, and tricks: #11 connectors naming convention.

Handle exceptions with scopes and "Run after" options

Scopes provide the capability to group multiple actions so that you can implement Try-Catch-Finally behavior. The Scope action's functionality is similar to the Region concept in Visual Studio. On the designer, you can collapse and expand a scope's contents to improve developer productivity.

When you implement this pattern, you can also specify when to run the Scope action and the actions inside, based on the preceding action's execution status, which can be Succeeded, Failed, Skipped, or TimedOut. To set up this behavior, use the Scope action's Run after (runAfter) options:

• Is successful
• Has failed
• Is skipped
• Has timed out

Consolidate shared services

When you build integration solutions, consider creating and using shared services for common tasks. You can have your team build and expose a collection of shared services that your project team and others can use. Everyone gains increased productivity, uniformity, and the capability to enforce governance on your organization's solutions. The following sections describe some areas where you might consider introducing shared services:

Shared service	Reasons
Centralized logging	Provide common patterns for how developers instrument their code with appropriate logging. You can then set up diagnostic views that help you determine interface health and supportability.
Business tracking and business activity monitoring	Capture and expose data so that business subject matter experts can better understand the state of their business transactions and perform self-service analytic queries.
Configuration data	Separate your application configuration data from your code so that you can more easily move your application between environments. Make sure to provide a unified consistent and easily replicable approach to access configuration data so that project teams can focus on solving the business problem rather than spending time on application configurations for deployment. Otherwise, if every project approached this separation in a unique way, you can't benefit from economies of scale.
Custom connectors	Create custom connectors for internal systems that don't have prebuilt connectors in Azure Logic Apps to simplify for your project team and others.
Common datasets or data feeds	Expose common datasets and feeds as APIs or connectors for project teams to use, and avoid reinventing the wheel. Every organization has common data sets that they need to integrate systems in an enterprise environment.

Next steps

You've now learned more about available migration approaches and best practices for moving BizTalk Server workloads to Azure Logic Apps. To provide detailed feedback about this guide, you can use the following form: