Leaving BizTalk? How to Pick the Right iPaaS Before Support Runs Out

BizTalk migration is more than replacing an integration platform. Learn how to assess your existing integration estate, decide what to retire or redesign, and choose an iPaaS that fits your future architecture.

Microsoft BizTalk Server has been a core integration platform for many enterprises for years, connecting applications, orchestrating business processes, transforming data, supporting APIs and EDI, and connecting systems that were never designed to work together.

But the modernization conversation is changing.

Microsoft lists BizTalk Server 2020 as the final BizTalk Server release, with mainstream support ending in April 2028 and extended support ending in April 2030. That gives organizations time to plan, but it also creates an important architectural question:

What should replace the integration capabilities that BizTalk currently provides?

The obvious answer is often: move to an iPaaS.

The better answer is:

First understand what your BizTalk environment actually does. Then decide what your future integration architecture should look like.

That distinction matters.

A BizTalk environment is rarely just a collection of workflows waiting to be moved to another platform. Over time, it can become deeply connected to applications, databases, APIs, trading partners, certificates, schemas, custom components, business rules, monitoring processes, and operational knowledge.

Replacing the platform without understanding those dependencies can simply move the complexity somewhere else.

BizTalk Migration is an Architecture Exercise, Not a Technology Replacement

A common migration assumption looks like this:

BizTalk orchestration → iPaaS workflow

BizTalk map → transformation

BizTalk adapter → connector

Technically, some workloads can be mapped this way.

Architecturally, that is not enough.

Microsoft's current migration guidance makes this distinction clear. Its approach to moving BizTalk workloads to Azure Logic Apps Standard is not intended to be a simple lift-and-shift. Organizations still need to validate business behavior, contracts, mappings, routing, ordering, retries, error handling, security, networking, performance, monitoring, and cutover.

The same principle applies regardless of which integration platform becomes the target.

Before selecting the platform, ask a more fundamental question: What integration capabilities does the business actually need five years from now?

That question changes the entire migration conversation.

Tellestia's BizTalk Modernization Framework

A successful BizTalk modernization program should follow a structured progression:

Discover → Assess → Classify → Architect → Pilot → Migrate → Optimize

The purpose is not to move every BizTalk artifact.

The purpose is to build a modern integration foundation while preserving the business capabilities that matter.

One of the most important steps is Classify.

For each workload, determine whether it should be:

Retire → Reuse → Rebuild → Redesign

This simple classification can prevent organizations from spending time and money reproducing integrations that should have been eliminated or redesigned in the first place.

What Should You Evaluate Before Choosing an iPaaS?

Choosing an iPaaS should come after understanding the integration estate, not before it. Here are seven areas enterprises should evaluate before selecting a target platform.

1. Understand Your Existing BizTalk Integration Estate

Start with discovery.

• BizTalk applications
• Orchestrations
• Schemas
• Maps
• Receive and send ports
• Adapters
• Pipelines
• Custom components
• Business rules
• EDI and B2B integrations
• APIs
• Databases
• File-based integrations
• External systems
• Certificates and security dependencies
• Monitoring and operational processes

Build an inventory of:

But an inventory alone isn't enough.

The more important question is: Which integrations are business-critical?

A low-volume integration supporting an internal process should not necessarily receive the same migration treatment as an integration responsible for orders, payments, customer onboarding, supply chain transactions, or regulatory reporting.

Assess each workload based on both technical complexity and business criticality.

This creates a much more useful migration roadmap than simply counting BizTalk applications or interfaces.

Questions to answer during discovery

• What systems does each integration connect?
• Which integrations are business-critical?
• Which applications are being replaced or modernized independently?
• Which integrations depend on custom code?
• Which interfaces use legacy protocols?
• Which integrations involve external partners?
• Where are certificates and credentials managed?
• Which workflows have strict sequencing or correlation requirements?
• Which integrations have significant operational history or recurring incidents?
• Which interfaces have little or no current business value?

The output should be an integration estate map, not simply a spreadsheet of BizTalk artifacts.

2. Decide What to Retire, Reuse, Rebuild, or Redesign

One of the biggest opportunities in a BizTalk modernization program is deciding what not to migrate. For each workload, consider four possible outcomes.

Retire

The integration no longer supports a meaningful business process.

If the underlying application or process is being retired, migrating the integration simply preserves unnecessary technical debt.

Reuse

The business process is still valid and the existing design remains appropriate for the target architecture.

Some integrations may require relatively limited redesign and can be migrated using equivalent capabilities.

Rebuild

The business capability is still required, but the implementation needs to be recreated using the target platform's native capabilities.

This may apply to workflows, transformations, APIs, or connectivity patterns that are still relevant but cannot be moved directly.

Redesign

The existing integration reflects an older architecture and should not be reproduced.

For example, a point-to-point integration that has accumulated years of transformation logic, exceptions, and dependencies may be better replaced by an API-led, event-driven, or other modern integration pattern.

The objective isn't to move every BizTalk artifact. The objective is to preserve the required business capabilities with a better integration architecture.

3. Evaluate Connectivity Beyond the Connector List

Modern iPaaS platforms provide extensive connector libraries. That does not automatically mean they can replace your BizTalk connectivity model. Look beyond the number of available connectors.

Evaluate:

• ERP and CRM connectivity
• Databases
• SaaS applications
• File systems
• SFTP
• REST and SOAP APIs
• Messaging systems
• EDI and B2B protocols
• Legacy applications
• On-premises systems
• Cloud services
• Custom protocols
• Partner-specific connectivity requirements

Then ask: How much custom development will be required where a native connector doesn't exist?

This distinction matters because a platform that looks straightforward during selection can become significantly more complex once custom connectors, networking, monitoring, security, and operational tooling are included.

The right question isn't: "Does the platform have a connector?"

It is: "Can the platform support this integration reliably, securely, and maintainably at the required scale?"

4. Identify the Business Logic Hidden Inside BizTalk

This is one of the areas that deserves particular attention during assessment.

Over time, integration platforms often become places where business logic accumulates. A BizTalk orchestration may contain much more than message routing. It may include:

• Conditional processing
• Transformation rules
• Validation
• Error handling
• Retry behavior
• Message correlation
• Sequencing
• Partner-specific logic
• Business rules
• Custom code
• Exception workflows

A direct technical conversion can reproduce the workflow while missing the intent behind it.

That's why migration teams should document not only what the integration does, but also why it does it.

The second question is often more important than the first.

A useful assessment question

Instead of asking: "How do we convert this orchestration?"

Ask: "What business capability does this orchestration provide, and what is the best modern architecture for delivering that capability?"

That shift can uncover opportunities to simplify the future state.

5. Design APIs, Events, Messaging, and Workflows at the Same Time

A BizTalk migration is an opportunity to reconsider how systems communicate. Not every integration should remain a synchronous application-to-application workflow.

Depending on the use case, the target architecture may involve:

• APIs
• Event-driven integration
• Message queues
• Pub/sub patterns
• Batch processing
• Workflow orchestration
• Data integration
• Hybrid connectivity

For example, a legacy point-to-point integration may be better represented as:

System A → API → Integration Layer → System B

rather than simply reproducing the original connection inside a new iPaaS.

Likewise, some business events may be better handled asynchronously rather than through tightly coupled synchronous integrations.

This is where migration becomes modernization.

6. Evaluate Security, Governance, and Operations Before Selecting the Platform

Security shouldn't be treated as a checklist after the platform has been selected.

For enterprise integration, evaluate three broad areas.

Identity and Access

Consider:

• Authentication
• Authorization
• Service identities
• Secrets management
• Certificate management

Network Architecture

Consider:

• Private connectivity
• VPN requirements
• Network segmentation
• Firewall rules
• Hybrid connectivity
• Data residency requirements

API and Integration Governance

Consider:

• API lifecycle management
• Policies
• Authentication
• Rate limiting
• Versioning
• Developer access
• Environment management
• Deployment controls

Operational Governance

Consider:

• Monitoring
• Alerting
• Logging
• Auditability
• Disaster recovery
• Error handling
• Performance monitoring
• Production support

The target platform should fit the organization's operating model, not just its development requirements.

7. Calculate the Total Cost of the Future Architecture

Platform licensing is only one part of the equation.

A realistic business case should consider:

Platform + implementation + infrastructure + networking + monitoring + support + development + migration + ongoing operations

Also consider the cost of maintaining the current environment during the migration.

For some organizations, the right answer may be a phased modernization where BizTalk and the new integration platform coexist for a period of time.

That can reduce migration risk, but it also introduces additional operational complexity.

The business case should therefore consider both the transition state and the future state.

Look beyond license cost

Evaluate:

• Implementation effort
• Developer skill requirements
• Training
• Support requirements
• Infrastructure
• Connector costs
• API management
• Monitoring
• Security tooling
• Disaster recovery
• Environment management
• Migration tooling
• Long-term maintenance

A lower platform license cost does not automatically mean a lower total cost of ownership.

Which iPaaS Should You Choose for BizTalk Migration?

There is no universally correct iPaaS for every BizTalk environment. Depending on the organization's requirements, the target architecture could involve platforms such as:

• Azure Logic Apps
• Boomi
• MuleSoft
• Workato
• WSO2
• Other iPaaS and integration technologies
• A hybrid combination of platforms and cloud services

The important question isn't: "Which iPaaS has the most features?"

It is:

"Which platform and architecture best fit our integration estate, operating model, security requirements, application landscape, and future roadmap?"

Platform selection should therefore be based on actual workloads rather than feature checklists alone.

A useful evaluation framework should compare platforms across areas such as:

This makes platform evaluation an architecture decision, rather than a product comparison exercise.

A Practical BizTalk Migration Roadmap

Once the target direction is established, migration can be executed through a structured sequence.

Stage 1: Discover

Build the integration inventory and identify dependencies.

Document applications, workflows, interfaces, data flows, APIs, partners, custom components, security dependencies, and operational requirements.

Output: Integration estate map and dependency inventory.

Stage 2: Assess

Classify each workload according to:

• Business criticality
• Technical complexity
• Dependency level
• Migration effort
• Modernization opportunity

Identify workloads that should be:

Retired → Reused → Rebuilt → Redesigned

Output: Workload-level migration assessment.

Stage 3: Architect

Define the target architecture before rebuilding individual integrations.

Determine where APIs, workflows, messaging, events, data integration, and other integration patterns belong.

The target architecture should also define:

• Security
• Networking
• Governance
• Monitoring
• Deployment
• Disaster recovery
• Operational ownership

Output: Target integration architecture and migration principles.

Stage 4: Pilot

Select representative workloads rather than simply migrating the easiest integration.

A good pilot should test the architecture against real requirements such as:

• Connectivity
• Transformation
• Error handling
• Security
• Monitoring
• Deployment
• Performance
• Resilience

The objective of the pilot isn't only to prove that an integration can be rebuilt.

It is to validate that the target architecture works in practice.

Output: Validated architecture and migration approach.

Stage 5: Migrate and Optimize

Move workloads in controlled waves.

Validate business behavior, reconcile dependencies, monitor production performance, and retire legacy components only after the replacement has been proven.

Microsoft's migration guidance similarly emphasizes validation, production hardening, monitoring, cutover, and coexistence rather than treating migration as a simple conversion exercise.

Output: Modernized integration estate with a controlled retirement of legacy workloads.

How Tellestia Approaches BizTalk Modernization

At Tellestia, we view integration modernization as an architecture and business continuity exercise, not simply a middleware replacement project.

Our approach starts with understanding the existing integration estate, identifying business-critical dependencies, and determining which workloads should be retired, reused, rebuilt, or redesigned.

From there, we help organizations evaluate the target architecture and integration platform against their actual requirements.

Our work can span:

• BizTalk assessment and migration planning
• iPaaS platform evaluation
• Integration architecture
• Application and system integration
• API integration
• Data integration
• Cloud and hybrid integration
• Migration implementation
• Testing and validation
• Integration monitoring and operational support

The objective is straightforward:

Don't move legacy complexity just because the platform is changing. Use the migration as an opportunity to build a better integration foundation.

For organizations evaluating a BizTalk modernization program, Tellestia can help assess the current integration estate, define the target architecture, evaluate iPaaS options, and build a practical migration roadmap.

Talk to Tellestia about your BizTalk modernization strategy →

The Right Time to Start Isn't When BizTalk Becomes Unsupported

The support timeline creates a deadline. It shouldn't create the strategy.

BizTalk Server 2020 remains supported for several years, but a meaningful enterprise migration can involve discovery, architecture, platform selection, pilot implementation, phased migration, testing, and coexistence.

Waiting until the deadline is close can turn an architectural program into a rushed replacement project.

Starting earlier gives organizations time to answer the questions that actually matter:

What should we retire?

What should we redesign?

What should the future integration architecture look like?

Which platform fits that architecture?

How do we migrate without disrupting the business?

That's the real BizTalk modernization conversation.

The goal isn't simply to leave BizTalk.

It's to build an integration architecture that is ready for what comes next.

Frequently Asked Questions About BizTalk Migration

What is BizTalk migration?

BizTalk migration is the process of moving integration workloads, business processes, interfaces, transformations, and related capabilities from Microsoft BizTalk Server to a modern integration platform or architecture. Depending on the environment, migration may involve rebuilding, refactoring, replacing, retiring, or redesigning existing integrations rather than performing a one-to-one conversion.

When should organizations start planning a BizTalk migration?

Organizations should begin planning well before their required migration deadline. BizTalk migrations can involve application discovery, dependency analysis, architecture design, platform evaluation, pilot implementations, testing, coexistence, and phased production migration. Microsoft currently lists BizTalk Server 2020 as the final release, with mainstream support ending in April 2028 and extended support ending in April 2030.

What should replace BizTalk Server?

There is no single replacement that fits every BizTalk environment. Depending on integration requirements, organizations may evaluate Azure Logic Apps, Boomi, MuleSoft, Workato, WSO2, or other integration technologies. The appropriate choice depends on application connectivity, integration patterns, APIs, data requirements, security, deployment model, governance, operational requirements, and total cost.

Can BizTalk applications be migrated directly to an iPaaS?

Some BizTalk capabilities can be mapped to modern iPaaS capabilities, but a direct one-to-one migration is not always appropriate. BizTalk implementations may contain orchestration logic, transformations, custom code, adapters, business rules, EDI processes, and operational dependencies that require refactoring or redesign. Microsoft's current BizTalk migration guidance similarly treats modernization as more than a simple lift-and-shift.

Should every BizTalk integration be migrated?

No. A BizTalk modernization assessment should determine whether each workload should be retired, reused, rebuilt, or redesigned. Migrating integrations that are no longer required can preserve unnecessary technical debt and increase migration cost.

How do you assess a BizTalk environment before migration?

A BizTalk assessment typically examines applications, orchestrations, schemas, maps, ports, adapters, pipelines, custom components, business rules, EDI/B2B integrations, APIs, dependencies, certificates, data flows, monitoring, security, performance, and operational requirements. The assessment should also identify business-critical integrations and migration dependencies.

How long does a BizTalk migration take?

The duration depends on the size and complexity of the BizTalk estate, number of integrations, custom components, external dependencies, business-critical workloads, target architecture, testing requirements, and migration strategy. A phased migration is often more practical for large enterprise environments than a single big-bang migration.

Is Azure Logic Apps the only option for BizTalk migration?

No. Azure Logic Apps is Microsoft's successor technology for BizTalk and Microsoft provides specific migration tooling and guidance for moving BizTalk workloads to Logic Apps Standard. However, organizations can also evaluate other iPaaS and integration platforms based on their architecture, application landscape, operating model, security requirements, and business needs.

What are the biggest risks in a BizTalk migration?

Common risks include incomplete dependency discovery, loss of business logic, incorrect transformation behavior, unsupported adapters or custom components, inadequate testing, security gaps, insufficient monitoring, performance issues, and attempting to reproduce legacy architecture rather than redesigning it.

How can organizations reduce BizTalk migration risk?

Organizations can reduce risk by beginning with an integration assessment, documenting dependencies and business behavior, defining the target architecture before migration, selecting representative pilot workloads, validating functional and non-functional requirements, and migrating in controlled waves rather than attempting a single large cutover.

Can AI help with BizTalk migration?

Yes. AI-assisted tools can accelerate parts of the migration process, including discovery, artifact analysis, code or workflow generation, and baseline implementation. However, AI-generated migration output still requires architectural review, functional validation, security assessment, testing, and production hardening. Microsoft's current BizTalk migration tooling includes AI-assisted capabilities while explicitly emphasizing validation and review of generated workflows and configurations.

Planning a BizTalk modernization?
Start with the architecture, not the platform.

Tellestia can help you assess your BizTalk environment, identify migration opportunities, evaluate iPaaS options, and build a practical modernization roadmap.

Talk to us today!

Shyam Sundar

Technical Architect

Share Blog Via:

Shyam Sundar is a Technical Architect at Tellestia, with a deep passion for building scalable and future-ready tech solutions. He shares insights on architecture, engineering best practices, and emerging technologies.

BizTalk modernization

BizTalk Server Migration

BizTalk to iPaaS

Microsoft BizTalk

trending