Staying on BizTalk has no line item, so in a budget meeting it reads as free — but the real cost is a compounding one: a shrinking pool of specialists whose rates rise every year, Software Assurance and hardware refresh on a platform that will not get another release, and every integration you did not build because the current one takes six weeks. A migration is expensive in a way you can see, and the number is driven by artifact count, not calendar ambition. The move that survives a budget cycle is not a single funded project; it is an assessment, then one funded wave, then waves that pay for themselves out of what the previous wave decommissioned.
Every BizTalk migration business case runs into the same wall, and it is not a technical one.
The finance question is “what does this cost”, and there is a competing option that appears to cost nothing: keep running what is already running. It has no invoice. It needs no approval. It fits in this budget cycle without a conversation. Against a number with six digits in it, “not yet” wins — and it wins again next year, and the year after, until the deadline stops being a plan and becomes a procurement emergency.
The way out of that argument is not urgency. It is arithmetic. Below is the cost of the option with no invoice, the cost of the option with one, and the funding shape that lets the second beat the first inside a normal budget cycle.
01 / The invisible column
What “do nothing” actually costs
Four costs accrue whether or not anyone books them. None of them arrives as a bill with BizTalk written on it, which is precisely the problem.
The specialist market moves against you, every year
BizTalk expertise is not being replenished. Nobody is learning it, the people who know it are retiring or moving to Azure work, and 2020 is the final version — so the supply curve only points one way. The rate you pay for a BizTalk contractor in 2029 is not the rate you paid in 2026, and it is highest exactly when you have the least room to negotiate.
The version of this that actually bites
It is rarely a rate card. It is that one person understands the orchestrations, and the migration cannot start until they are available — so the project slips to their calendar, not yours. That dependency gets more expensive the longer it exists, and it is uninsurable.
You keep paying maintenance on a platform with no roadmap
Software Assurance, SQL Server licensing, Windows Server, the hardware refresh when the hosts age out — all of it recurs, and none of it now buys you a future version, because there will not be one. It buys you the same platform for another year. That is a defensible spend in 2026 and a harder one to defend in 2029.
The integrations you did not build
This is the largest number on the page and the only one nobody measures. When onboarding a trading partner takes six weeks, the business stops asking. Acquisitions integrate slowly. Partner deals get scoped around what integration can absorb. That is not an IT cost — it is revenue timing — and it is the number a CFO actually responds to.
How to put a figure on it without inventing one
Do not model it. Count it. How many integration requests were declined, deferred or descoped in the last 24 months, and what was each one attached to? A list of real requests with the business initiative attached to each is more persuasive than any modelled figure, and it takes an afternoon with your own ticket queue.
The risk becomes an audit finding before it becomes an outage
Mainstream support for BizTalk Server 2020 ends April 11, 2028, and extended support runs to April 2030. Extended support means security fixes only, and then it ends. For regulated estates — healthcare payers, banks, anyone with an auditor — running business-critical message flow on an unsupported platform stops being a technical risk and becomes a finding with a remediation date attached. At that point the timeline is set by someone else.
Deferral is not the cheap option. It is the option whose cost lands in a year when you have no leverage over it.
The whole argument in one line
02 / The visible column
What actually drives the migration number
The honest answer to “what does a BizTalk migration cost” is that it is a function of artifact count and artifact complexity, not of calendar ambition or estate age. Five inputs move the number, in roughly this order of impact:
| Driver | What moves the number | How to reduce it |
|---|---|---|
| Live artifact count | Ports, orchestrations, maps, pipelines and adapters that still carry traffic. Not the count in the admin console — the count that moved a message this quarter. | Inventory first. Half the estates we assess carry artifacts nobody would miss. Retiring them is the single cheapest thing you can do. |
| Map complexity | Functoid graphs and custom scripting functoids do not lift and shift. Complexity per map matters more than map count. | Automated conversion handles the bulk; budget human time for the tail of genuinely hard ones rather than for all of them. |
| Custom components | Pipeline components written years ago, sometimes without source control and without the author. These are reverse-engineering work, which is the least predictable line in any estimate. | Find them early. A component with no source is a scoping risk you want in the assessment, not in month four. |
| Trading-partner surface | EDI party configuration, envelopes, acknowledgements and the per-partner quirks that live in nobody’s documentation. Each partner is a test cycle with an external dependency. | Sequence partners by volume and by how forgiving they are, and get the forgiving ones through the parallel run first. |
| Reversibility requirement | Running both platforms during a parallel run genuinely costs more than a big-bang cutover. It is the price of a cutover anyone will sign. | Do not remove it. Shorten it, per wave, by making the comparison automatic rather than manual. |
This is the shape of the estimate, not a price list. Two estates with the same artifact count can differ by a factor of three on the middle three rows, which is why we size from an inventory rather than from a headcount or a revenue band.
03 / The line nobody budgets
Yes, you pay for both platforms for a while
During a parallel run, both platforms process the same messages and the outputs are compared message-for-message before anything cuts over. That means, for the duration of each wave, you are running BizTalk and its replacement.
Teams discover this halfway through a business case and treat it as a flaw in the plan. It is not. It is the entire reason the plan gets approved.
The alternative — a single weekend cutover with no way back — is cheaper on the spreadsheet and is the reason so many of these projects stall. Nobody signs a cutover they cannot reverse, so the approval never comes, so the money is never spent, so the estate is still there in 2029. A slightly more expensive plan that is actually approvable beats a cheaper one that is not.
04 / The funding shape
Three tranches, not one business case
The reason a single large migration business case fails is that it asks for the whole number before anyone can see the whole scope. Break it into three asks, each of which is justified by the one before it.
Fund the inventory, not the project
An artifact inventory is small, fast and produces the number everything else depends on: what is actually live. It converts “migrate BizTalk” from an unfundable blob into a scoped list. It is also the tranche that most often reduces the total, because retiring dead artifacts is free scope reduction.
Fund one wave, and pick it for evidence
Choose the first wave for what it proves, not for what it saves — a real integration with a real trading partner, small enough to finish inside a cycle. What you are buying is a completed parallel run and a cutover that worked, which is the evidence tranche three is approved on.
Let decommissioning pay for the rest
Every wave that cuts over retires capacity — cores, SQL, hosts, and eventually whole servers with Software Assurance attached. From wave two onward the programme has a self-funding component, and the business case stops being a request and starts being a schedule.
The six numbers that make the case argue itself
05 / Scope
What this post is not
This is the programme side of the cost question: what deferral costs, what drives the migration number, and how to phase the spend so it survives a budget cycle. It deliberately does not price platforms against each other.
If what you need is the platform bill — BizTalk’s per-core licensing and the SQL Server line behind it, next to what an Azure-native ESB costs per month — that comparison lives on the product side: what BizTalk costs to keep running, and what iQBus costs instead.
06 / Next
Start with the inventory
You can do it yourself with the BizTalk admin console and a couple of days — and if you have the time, do. The output is what matters, not who produced it: every port, orchestration, map, pipeline and adapter, and which of them still carry traffic.
If you would rather have it done and sized, our assessment produces the inventory, a target-state map for each artifact, and a wave plan with a parallel-run gate before every cutover. Twenty years running BizTalk in enterprise production, Microsoft V-TSP recognized for BizTalk Server.
Book a migration assessment, or talk it through with an integration architect first.
Call (678) 203-0800 — or send the artifact counts and we will tell you what the shape of the number looks like before anyone books a meeting.
Frequently asked questions
What does it cost to stay on BizTalk until support ends?
There is no single invoice, which is why it is usually underestimated. The recurring costs are Software Assurance, SQL Server and Windows Server licensing, host capacity and the operations time attributable to the platform. The compounding costs are a shrinking specialist market whose rates rise every year, the hardware refresh on a platform that will not receive another version, and the integration work the business stopped asking for because the current platform is slow to change.
How much does a BizTalk migration cost?
It is a function of artifact count and artifact complexity rather than calendar ambition. The five drivers are the number of artifacts still carrying traffic, map complexity, custom pipeline components without source or authors, the trading-partner surface, and whether you require a reversible parallel run before each cutover. Two estates with the same artifact count can differ by a factor of three, which is why the number comes from an inventory rather than from a headcount or revenue band.
Can a BizTalk migration be funded in stages?
Yes, and it is the funding shape most likely to be approved. Fund the artifact inventory first, then a single wave chosen for what it proves rather than what it saves, then let the capacity retired by each completed wave — cores, SQL licensing, hosts and Software Assurance — offset the waves that follow.
Do we pay for both platforms during a parallel run?
Yes, for the duration of each wave. Both platforms process the same messages and the outputs are compared message-for-message before cutover. That overlap is bounded and per wave rather than across the whole programme, and it is what makes each cutover reversible — which is usually the difference between a plan that gets approved and one that gets deferred.
What is the cheapest way to reduce a BizTalk migration estimate?
Retire what is no longer live. Most estates carry orchestrations, maps and ports that have not moved a message in years, and removing them from scope costs nothing. That is why the inventory is the first tranche of funding rather than a task inside the project.
How long does a staged BizTalk migration take?
It depends on artifact count and on how many waves the estate divides into. Large estates typically run several quarters with a parallel-run gate before each cutover. The assessment sizes it; a date set before the inventory exists is a guess.
Can you support our existing BizTalk estate while we plan?
Yes. We have run BizTalk in enterprise production for twenty years and are Microsoft V-TSP recognized for BizTalk Server, including support and extension of existing estates on end-of-life versions while a migration is planned and sequenced.
Jorge Pastorini · Cerebrum City
Cerebrum City is a Microsoft V‑TSP–recognized BizTalk specialist in Atlanta, Georgia, with two decades running BizTalk Server in enterprise production for clients including Humana, Deloitte, JetBlue, and U‑Haul.
Want this mapped against your BizTalk estate?
We inventory your ports, orchestrations, maps, and adapters, flag the interfaces most likely to break, and hand back a staged Azure roadmap. No obligation.
