From BizTalk and MuleSoft to Azure iPaaS — with a Spec in the Middle

How we built SpecForce, a multi-agent GitHub Copilot workflow that migrates legacy integration platforms to Azure Integration Services without losing the business logic on the way

By Sharmishtha Sarkar & Roshan Menon

Every enterprise I’ve worked with has the same skeleton in the closet: a fleet of BizTalk orchestrations or MuleSoft flows that quietly run the business — orders, invoices, inventory syncs — written years ago by people who have long since moved on. The platforms are aging out: BizTalk Server 2020 is the final major release of the product, and MuleSoft licensing costs push many teams to re-evaluate every renewal cycle. Meanwhile, Azure Integration Services (Logic Apps, Service Bus, API Management, Azure Functions) has matured into a genuinely capable iPaaS.

So the destination is clear. The problem is the journey.

The problem with code-to-code migration

Every migration tool I’ve evaluated goes code → code. Feed it an .odx file, get a Logic App definition out. It sounds efficient, but there's a fatal flaw: the specification never exists.

When you translate legacy code directly into new code:

• ❌ No human can validate what was migrated. The only people who could review the output are the ones who understood the original — and they’re gone.
• ❌ Business logic gets lost silently. A correlation set that enforced “one order per customer session” becomes a subtle race condition nobody notices until production.
• ❌ There’s no audit trail. Regulated industries need to prove what was migrated and why decisions were made.
• ❌ There’s no documentation for the next team. You’ve traded one undocumented system for another.

The insight behind SpecForge is simple: make the human-readable specification the product, not a stepping stone. Legacy code becomes a spec. The spec gets reviewed — by multiple specialized reviewers. Only an approved spec becomes Azure artifacts.

What SpecForge does

SpecForge is a repository of agents, skills, and context files that runs entirely inside GitHub Copilot’s agent mode in VS Code. No custom runtime, no orchestration server, no deployment. You clone the repo, open it in VS Code, and the agents are available in Copilot Chat.

The pipeline has four stages:

BizTalk / MuleSoft source files
 ↓
 ① PARSE - Platform expert agent extracts business intent
 ↓
 ② SPEC - Spec writer turns the parse report into a formal, reviewable spec
 ↓
 ③ REVIEW - Review coordinator fans out to three specialist reviewers in parallel
 ↓
 ④ FORGE - Azure architect generates Bicep, Logic Apps, and Service Bus artifact

A full run against a BizTalk orchestration looks like this in Copilot Chat:

@biztalk-expert /analyze-biztalk samples/biztalk/order-processing.odx
@spec-writer /create-spec
@review-coordinator
@azure-architect /generate-bicep

Four prompts. The output is a parse report, a versioned integration spec, a consolidated multi-agent review with an explicit APPROVED/REJECTED decision, and a set of deployable Bicep templates.

The architecture

SpecForge uses six specialized agents rather than one monolithic “migration agent”:

The stages hand off through files, not chat context: parse reports land in parse-reports/, specs in specs/, generated artifacts in outputs/. Every intermediate product is a Markdown or Bicep file you can diff, review in a pull request, and keep as an audit trail. That's a deliberate design choice — the artifacts are the interface between agents.

How it’s built: agents, skills, and instructions

Everything lives in the .github/ folder, using GitHub Copilot's customization model:

.github/
├── copilot-instructions.md          # Repo-wide rules for every interaction
├── agents/                          # Agent personas
│   ├── biztalk-expert.agent.md
│   ├── mulesoft-expert.agent.md
│   ├── azure-architect.agent.md
│   ├── security-reviewer.agent.md
│   ├── spec-writer.agent.md
│   └── review-coordinator.agent.md
├── instructions/                    # Platform-specific parsing rules
│   ├── biztalk-parse.instructions.md
│   ├── mulesoft-parse.instructions.md
│   └── ais-generate.instructions.md
└── skills/                          # Granular, reusable procedures
    ├── analyze-biztalk/SKILL.md
    ├── analyze-mulesoft/SKILL.md
    ├── create-spec/SKILL.md
    ├── review-architecture/SKILL.md
    ├── review-security/SKILL.md
    └── generate-bicep/SKILL.md

The three layers do different jobs:

Agents define who is talking — a persona with a domain, a mission, and known failure modes. Here’s a condensed excerpt from the BizTalk expert:

# BizTalk Expert Agent

You are a BizTalk Server expert with 15+ years of experience in
enterprise integration. You specialize in parsing BizTalk
orchestrations, maps, pipelines, and schemas — extracting business
intent for Azure migration.

## Your Mission
1. Parse the XML structure to extract ports, messages, shapes, logic
2. Identify the business process being implemented (not just the code)
3. Document all correlation sets (critical for async patterns)
4. Flag complex functoids and custom pipeline components as ⚠️
5. Map BizTalk constructs to equivalent AIS components
6. Warn about BizTalk features with no direct Azure equivalent

Skills define how a task is done — a repeatable, step-by-step procedure with a defined output format. Skills carry YAML frontmatter binding them to agents:

---
name: analyze-biztalk
description: >
  Parse BizTalk orchestrations (.odx), maps (.btm), and pipelines
  (.btp) to extract business intent, message flows, and integration
  patterns. Generates a BizTalk Analysis Report.
agents: biztalk-expert
---

The skill body then walks through the steps: identify the file type, extract core elements (ports, correlation sets, exception handlers), translate technical shapes into business steps (“Decide shape” → “Route based on order value > $1000”), classify the integration pattern (sync-request-reply, pub-sub, orchestration, ...), and — crucially — flag ambiguities like unbound ports and custom functoids with ⚠️ markers so a human knows exactly where to look.

Instructions define path-specific rules — parsing conventions for each platform and generation standards for Azure output (every generated Bicep template uses Managed Identity, no secrets outside Key Vault, compliance tags enforced).

The multi-agent review: where the value concentrates

The review stage is what separates this from “ask Copilot to convert my file.” The @review-coordinator fans out to three reviewers in parallel, each with a different lens:

              Integration Spec (DRAFT)
                        │
              @review-coordinator
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
 @azure-architect  @security-      @biztalk-expert
 /review-          reviewer        /review-legacy-
 architecture      /review-        mapping
                   security
        └───────────────┼───────────────┘
                        ▼
        Consolidated Review → APPROVED / CHANGES REQUIRED

• The Azure architect validates the target design: is Logic Apps Standard the right tier? Should this queue be a topic? Is the error handling pattern idiomatic AIS or a literal transplant of BizTalk thinking?
• The security reviewer audits for compliance blockers: connection strings that should be Managed Identity, missing Key Vault references, over-broad RBAC. Security findings can block approval — this is not advisory.
• The platform expert returns in a reviewer role, validating the legacy→Azure mapping against the original parse report. This closes the loop: the agent that read the source code verifies nothing was dropped in translation.

Running the three reviews in parallel keeps wall-clock time at max(T) instead of 3×T, and — more importantly — keeps each reviewer’s context small and focused.

Context engineering: why six small agents beat one big one

The obvious alternative is one mega-agent with all the knowledge: BizTalk + MuleSoft + Azure + security + spec templates. I deliberately avoided that, and the reason is context control:

Each agent loads only its domain. In practice this means faster responses, lower token cost, and — most noticeably — better accuracy. A spec writer that can’t see Bicep patterns doesn’t hallucinate implementation detail into a requirements document. A BizTalk parser that isn’t thinking about Azure yet reports what the code actually does instead of what it assumes the target should be.

If you’re building any multi-agent Copilot workflow, this is the transferable lesson: the architecture of your agents is really the architecture of your context.

The knowledge base: encoding migration expertise as context

The agents are only as good as the domain knowledge behind them. The docs/ folder carries the reference material the agents draw on:

• migration-mapping.md — explicit legacy → AIS mapping tables. This is where hard-won migration knowledge lives, for example the BizTalk gotchas every migration hits:

• ais-patterns.md — idiomatic Azure Integration Services architecture patterns, so generated designs look like an Azure architect built them, not a transliterator.
• spec-template.md — the contract for what a complete integration spec must contain.

Encoding this as versioned Markdown means the knowledge base improves with every migration: hit a new edge case, add a row to the mapping table, and every future run benefits.

What comes out the other end

For an order-processing orchestration, the final /generate-bicep step produces a deployment-ready folder:

outputs/order-processing/
├── main.bicep              # Orchestration of all resources
├── parameters.bicepparam   # Environment parameters
├── logicapp.bicep          # Logic App (Standard) workflow
├── servicebus.bicep        # Queues/topics incl. sessions where needed
└── README.md               # Deployment and operations notes

Generation follows the repo’s non-negotiable rules: Managed Identity everywhere, secrets only via Key Vault references, mandatory compliance tags. Because the spec was approved before generation, the Bicep review is a formality — you’re checking the code matches the spec, not re-deriving the requirements.

I validated the pipeline end-to-end against real production BizTalk and MuleSoft applications from two enterprise engagements (which I can’t share here for confidentiality reasons). The pattern held up: the parse stage surfaced correlation sets and custom components the original teams had forgotten existed, and the spec review caught mapping decisions that a direct code-to-code conversion would have silently gotten wrong.

Extending to TIBCO, IBM ACE, and beyond

Because platform knowledge is isolated in per-platform agents, instructions, and mapping sections, adding a new source platform is additive — nothing existing changes:

.github/agents/tibco-expert.agent.md — the persona
.github/skills/analyze-tibco/SKILL.md — the parsing procedure
.github/instructions/tibco-parse.instructions.md — parsing rules
A new section in docs/migration-mapping.md

The spec format, review process, and generation stage are platform-agnostic — they operate on parse reports and specs, never on legacy source directly. TIBCO BusinessWorks and IBM IIB/ACE instructions are already drafted.

Takeaways

1. Put a spec between legacy and target. It’s the difference between a migration you can audit and one you have to trust.
2. Small, specialized agents outperform one omniscient agent — because context is the real architecture.
3. Hand off through files, not chat. Markdown artifacts in the repo give you diffs, PRs, and an audit trail for free.
4. Make review adversarial and parallel. An architect, a security reviewer, and the original parser checking each other catches what any single pass misses.
5. Encode migration expertise as versioned context. Mapping tables and pattern docs compound in value with every project.

None of this requires anything beyond a GitHub Copilot subscription and VS Code — the entire “platform” is Markdown files in a repo. That’s perhaps the most interesting part: serious multi-agent engineering workflows are now something you author, not something you build.

Want the repo?

SpecForge isn’t publicly listed. If you’d like insights to the repository — the agents, skills, instruction files, and end-to-end examples — leave a comment here

If you’re staring down a BizTalk sunset or a MuleSoft renewal and wondering how AI-assisted migration could work for your estate, I’d love to compare notes.