Building a migration factory: how to structure a large BizTalk migration 

Most large BizTalk migrations start with good intentions and a detailed plan. Then reality sets in. Key specialists get pulled in multiple directions, knowledge sits in people’s heads rather than documentation, and each new integration feels like starting from scratch. The program slows down, costs increase and the delivery model that worked for the first wave struggles to scale. 

Structuring the program as a repeatable factory from the start changes that outcome significantly, and it is one of the most important decisions a migration program can make. 

Why one-off migrations struggle at scale 

A traditional migration program relies heavily on individual expertise. One architect understands the landscape, a few developers know the tricky integrations and a handful of specialists hold the institutional knowledge about why things were built the way they were. This typically includes integrations that have grown in complexity over the years, custom components that were never fully documented and business logic that only a few people fully understand. 

This can work for a limited scope. Across a large enterprise estate with hundreds of integrations, it becomes a structural bottleneck. When knowledge is concentrated in individuals, delivery slows whenever those individuals are unavailable. Patterns get reinvented for each integration rather than reused across them, quality varies between workstreams, and when the program ends, much of what was learned leaves with the people who did the work. 

The migration factory model 

A migration factory is a delivery model where the program becomes more efficient as it progresses. The key is front-loading the architectural decisions, such as defining target patterns, establishing Azure reference architectures, aligning on naming conventions, monitoring standards and governance policies, so that subsequent waves can move faster with less rework and more consistent output. 

Over time, the team builds a pattern library that captures how specific BizTalk scenarios map to Azure Logic Apps Standard, which integration types can follow standard migration paths, which need redesign and where custom .NET local functions are required to replace pipeline components without direct equivalents. Each wave benefits from the decisions made in the previous one, and the factory improves with every iteration. 

Wave 0: scoping, sequencing and de-risking the program 

The first wave in a well-structured migration program is focused on building the foundation for everything that follows. In practice, this means running an AI-assisted discovery of the current BizTalk environment. The agent scans project files, extracts orchestrations, schemas, maps, pipelines and bindings, builds a dependency graph and classifies the full integration estate by complexity, business criticality and architectural similarity. 

The output of Wave 0 is a realistic migration roadmap: sequenced waves with effort estimates, a validated target architecture, defined patterns for the most common integration types and a clear picture of where the standard path ends and redesign begins. Starting with complex, business-critical integrations before the delivery model is proven is one of the most common causes of delays and rework in large migration programs. Wave 0 is the investment that makes everything else more predictable. 

How to sequence migration waves 

Lower-risk integrations with standard patterns go early. They prove the approach, validate the reference architecture and allow the team to refine the factory before higher-stakes work begins. File-based transfers, simple request-reply patterns and straightforward message routing are good candidates for early waves. Complex orchestrations, custom pipeline components, BAM-dependent flows and integrations with tightly coupled external systems belong in later waves, once the team has established confidence in the delivery model. 

Sequencing decisions should account for business criticality, technical complexity, dependency profile and architectural similarity. Grouping integrations with similar source patterns in the same wave reduces context-switching and allows the team to build and reuse components more efficiently across the wave. 

How AI enables the factory model 

The Logic Apps Migration Agent changes the economics of the factory model by making the repetitive parts of migration faster and more consistent. Discovery and dependency mapping that previously required weeks of manual work from senior architects can now be completed in hours, freeing those architects to focus on sequencing decisions, gap analysis and target architecture rather than artifact archaeology. 

First-draft generation gives developers a consistent, structured starting point for every integration. The agent produces a Logic Apps Standard workflow that reflects the source artifact and the migration plan, ready for review and refinement rather than created from a blank page. Test case generation produces coverage based on the discovered integration logic, giving QA teams a better baseline to validate against. Documentation is generated alongside delivery rather than reconstructed after the fact. 

Preserving knowledge before it disappears 

Many BizTalk environments carry knowledge that was never fully documented and exists only in the minds of a small group of specialists. People move on, change roles or simply become unavailable, and when they do, that knowledge goes with them. The longer migration is delayed, the greater the risk that critical understanding of the environment becomes impossible to recover.  

AI-assisted migration helps capture and structure that knowledge while it is still accessible. By analyzing artifacts, mapping dependencies and generating first-draft documentation, teams can systematically rebuild understanding of the legacy platform in a form that transfers to the new environment. The goal is a modern Azure integration platform that is documented, observable and easier to operate than the one it replaces, rather than a cloud-hosted version of the same black box. 

Governance as a structural property 

A migration factory only works if governance is built into how it operates rather than managed as a separate oversight function. Having a clear Definition of Ready before each wave ensures that integrations are properly classified, scoped and sequenced before build begins. This means the target pattern is defined, dependencies are documented and the Azure components are provisioned and ready. And having a Definition of Done that closes each wave confirms that delivery, testing, documentation, runbooks and operational readiness are all in place before the team moves on.  

Quality gates between waves catch problems before they compound across the estate. Runbooks, monitoring configuration and knowledge transfer are part of every wave’s Definition of Done, not activities reserved for a final handover at the end of the program. 

The Epical Migration Accelerator 

Epical’s structured approach to BizTalk migration is built on the Epical Migration Accelerator, a Microsoft-audited delivery model covering strategy, architecture, delivery and operations. It provides five clear modernization phases, a repeatable migration factory with reusable templates and patterns, and AI-assisted delivery that reduces manual effort without removing governance or business validation.  

Combined with the Logic Apps Migration Agent, the Migration Accelerator gives organizations both the tooling and the proven methodology to structure a large BizTalk migration as a controlled, scalable program. 

Curious about what a BizTalk to Azure migration looks like with Epical?