Microsoft’s lifecycle team made an announcement most BizTalk customers either missed or chose to. They extended mainstream support for BizTalk Server 2020 from January 2024 to April 11, 2028. On the surface, a three-year reprieve that lands in inboxes like good news.

Read the same announcement again, slower. Buried in the second sentence, Microsoft writes: “While customers are encouraged to consider cloud solutions in Azure as an alternative to BizTalk, we are committed to supporting our existing customers.”

That’s not a reassurance. It’s a recommendation. Microsoft’s own lifecycle team is telling you to leave, and giving you three more years to do it properly. The BizTalk customers who treat 2028 as a fresh expiry date are the ones who’ll be doing this badly in 2027.

What three years of doing nothing actually costs

For any financial services firm, or any other regulated business, running BizTalk on-prem today, the real costs of letting it ride don’t show up on the support contract. They show up in three places.

Adapter rot. Your BizTalk install almost certainly depends on adapters that won’t see another major release. SAP, MQ, SWIFT, the file and database connectors that keep settlement and reconciliation moving: they aren’t getting new features and most aren’t getting security parity with Azure-native equivalents. Every quarter you wait, the integration debt compounds, and the eventual migration gets more expensive, not less.

Operational resilience under DORA. The Digital Operational Resilience Act took effect on 17 January 2025 for financial services firms across the UK and EU. DORA requires critical ICT third-party risk to be documented, tested, and remediable. A BizTalk Server 2020 install that exits mainstream support in 2028 is a critical ICT dependency on a sunset product. That conversation lands on the audit committee’s desk well before April 2028, typically two or three audit cycles ahead. If your auditors haven’t asked yet, they will.

The talent cliff. The senior BizTalk engineers who built these estates have largely moved on or retired, and almost no junior engineer has been trained on it for years. Every BizTalk-specialist contractor on the UK market today is a finite resource, and rates have climbed accordingly. By 2028 you’re not buying expertise, you’re paying scarcity premiums to people who’d rather be doing something else.

None of these costs are theoretical. We see them in every BizTalk health check we run, and they get worse on a quarterly cadence, not annually.

The three migration paths CTOs get pitched (and which one fails)

Open the BizTalk migration conversation and three doors get held open. Two of them are bad ideas dressed up as easy ones.

Door 1: Lift and shift to BizTalk Server 2020 on Azure VMs

This is what most consultancies sell because it’s the easiest engagement to scope. You move the BizTalk install from on-prem hardware to Azure IaaS, you tick a “we’re in Azure” box, and you start the same conversation again in 2030. The lift-and-shift buys time. It loses none of the legacy debt. Over a five-year horizon it’s the most expensive option, because every Azure-native service the business eventually needs has to be bolted onto a BizTalk monolith that the rest of your platform team won’t touch.

If you’ve been told a BizTalk Azure VM migration “buys you time to think,” ask the same consultancy what their plan is for the eventual migration off it. The silence is the answer.

Door 2: Direct rebuild on raw Azure services

Logic Apps Standard, Azure Functions, Service Bus, API Management, Event Grid, Data Factory. Each one a real product. None of them, individually, a replacement for what BizTalk did for you implicitly. The CTO gets handed an architecture diagram with twelve boxes and a stitching plan.

Six months in, someone notices nobody owns the orchestration layer that BizTalk handled for you for free. Twelve months in, the team is rebuilding correlation, dehydration, retry policies, and the dead-letter pattern in YAML and C#, badly. Eighteen months in, the budget conversation gets reopened.

If your team has fifteen senior integration engineers, a multi-year runway, and an organisational tolerance for ground-up rebuild, this route is defensible. Most financial services firms don’t have all three of those things.

Door 3: Migrate to a platform that already encodes the BizTalk mental model in Azure

Orchestrations stay orchestrations. Send and receive ports stay connectors. Schemas and maps still exist as first-class objects. Correlation, retries, and dehydration are handled by the platform, not by code your team has to write twice. The migration becomes a translation exercise, not an architectural rebuild.

This is the route the ARRT Brain is built for, and it’s the route we recommend to every financial services client we run a health check for, because in nine out of ten cases the maths only works one way.

What a BizTalk-to-ARRT-Brain engagement actually looks like

The ARRT Brain is deployed inside your own Azure tenant. Not a SaaS instance. Not someone else’s multi-tenant cluster. Your security team owns the network boundary. Your platform team owns the resource group. ARRT consultants build inside it.

Foundations and the first end-to-end process (something like Create Customer, Onboard Broker, or Settle Trade) typically run around £100k. Each subsequent process sits between £20k and £60k depending on complexity. The financial services estates we work on usually contain dozens of integration processes rather than a handful, which puts a full migration in a defensible commercial range before anyone on your side has to defend a number to the board.

The work runs in three phases.

Phase 1: Inventory

A senior ARRT consultant (we don’t deploy juniors; that’s a deliberate commercial choice, not a marketing line) sits with your integration team for two to four weeks and produces a full inventory of every BizTalk artefact in the estate. Orchestrations, send and receive ports, pipelines, schemas, maps, custom .NET assemblies, BAM activities, business rules, and the adapters glueing it all together.

Each artefact gets classified three ways: business criticality (top, mid, low), migration complexity (clean rebuild, refactor, retire), and destination on the ARRT Brain (process, connector, schema, transform).

This isn’t novel methodology. What’s novel is doing it with senior consultants who’ve genuinely run BizTalk migrations in financial services, not analysts running through a vendor template.

Phase 2: Sequence

The output of Phase 1 is a sequencing decision, not a technology decision. The technology is fixed: the ARRT Brain is the destination. The real question is which process gets migrated first, and what the parallel-run period looks like for each.

The right first process is rarely the most critical one. It’s the one that proves the migration pattern with the least blast radius: typically a high-volume, low-stakes process like reference data sync or a daily reconciliation feed. Once that’s running in parallel against BizTalk for two to four weeks and the numbers match line-for-line, the trust is earned and the harder migrations move faster, with audit-grade evidence behind them.

For DORA-regulated firms, this parallel-run period is also where your operational resilience evidence comes from. We run it as a documented exercise so the audit trail exists by design.

Phase 3: Cut over

Once the inventory is complete and the sequence is agreed, deployment runs incrementally. Each process is built on the ARRT Brain, run in parallel against BizTalk for an agreed window, validated against production data, and then cut over with a documented rollback path.

In our experience the early processes take longer than the later ones, because the migration pattern is being established the first time through. Once the pattern is set, every subsequent process is faster, cheaper, and lower-risk. ARRT consultants stay embedded until your team is self-sufficient. That’s how the engagement is contractually structured, not aspirationally.

Why the ARRT Brain beats stitching native Azure services together

The strongest argument against the ARRT Brain is “we’ll do it ourselves on Logic Apps Standard.” We respect that argument. Some IT teams should do exactly that.

The maths only goes the other way for most financial services firms because of three constraints they all share: a finite integration team, a non-negotiable regulatory deadline, and an internal political appetite for one big migration project rather than a rolling rebuild that overruns. Every IT director who’s done a Logic Apps direct-rebuild has the same stories about month nine: someone has to own the orchestration model BizTalk used to give you for free, someone has to write retry and dehydration logic, someone has to design correlation IDs and dead-letter queues. The ARRT Brain exists because we got tired of writing those primitives by hand on every client.

The commercial argument is simpler. For a 30-process financial services estate, the ARRT Brain lands the migration in a £700k–£1.8M range, based on ARRT’s published per-process pricing of £100k for foundations plus £20k–£60k per additional process. A direct rebuild on raw Azure services for the same estate typically runs into seven figures of consultancy plus a sustained tour of duty from your internal team, because the orchestration, retry, and dead-letter primitives that the ARRT Brain gives you out of the box have to be built and maintained one process at a time.

If a competing consultancy quotes you significantly less than that for a direct-rebuild on Azure-native services, ask what’s missing. The honest answer is usually orchestration, dead-lettering, monitoring, and the parallel-run discipline that DORA needs.

What to do this quarter

If your BizTalk Server 2020 install touches an internal audit cycle in 2026 or 2027, the right action this quarter isn’t a migration plan. It’s a three-week health check. The health check produces the artefact inventory, the criticality scoring, and a sequencing recommendation. It’s the only honest way to size the migration before anyone commits to a number.

ARRT runs these as fixed-fee engagements. The output is yours to shop around, and we mean it. Several of our health checks have been used to scope work that the client eventually delivered with another partner. We’d rather you make the decision with full information than pretend the inventory is proprietary.

If you’d rather start with a conversation, book one here. We’ll tell you in twenty minutes whether the ARRT Brain is the right fit, or whether your team falls in the small minority that should go direct on Azure-native services.

Three questions we get asked every week

Is BizTalk dead? No. Microsoft has committed to mainstream support for BizTalk Server 2020 until April 11, 2028, and extended support until April 9, 2030. What’s dead is the future roadmap. Microsoft has explicitly recommended Azure alternatives, and there is no BizTalk Server 2022 or 2025 in the pipeline. BizTalk is a product in maintenance mode with a published exit path.

What happens if we miss the 2028 deadline? Extended support runs to April 2030, which keeps you on security updates without new features. The real deadline isn’t a Microsoft date, it’s whichever audit cycle, M&A event, or platform refresh hits first. For most financial services firms, that’s well before 2028.

Can we run the ARRT Brain and BizTalk in parallel? Yes. That’s the design. The ARRT Brain is deployed alongside BizTalk during migration, processes are cut over one at a time, and BizTalk gets decommissioned once the last process moves. The parallel-run period is also where your DORA resilience evidence gets generated.

Author: ARRT Integration. We migrate BizTalk estates for financial services firms onto the ARRT Brain, deployed inside our clients’ own Azure tenants. Read more about our approach or book a BizTalk health check.