A UK team that built its phone agents on Bland has a dated job on its list this autumn. Bland's migration guide says the company updated its application in September 2026, and that conversational pathways and personas, the two ways agents were built on the old dashboard, must be migrated to a new architecture called Bland Agents. The documentation banner says the same thing more briefly: Bland is getting a major upgrade, and users are transitioning in the coming weeks. For a contact centre in Manchester or a collections desk in Glasgow, a forced rebuild is also the natural moment to ask a wider question. Migrate inside Bland, or move platform.
This guide is written for the Head of Customer Operations who owns those calls, with the CIO as co-reader. It covers what the deadline does and does not do, which of Bland's three migration paths fits which kind of agent, what can quietly change when a pathway becomes an agent, and how to judge a move on its merits. It deliberately cedes three neighbouring topics. Pricing belongs to our Dilr Voice vs Bland comparison and the best AI voice agent 2026 guide, the PECR and Ofcom duty teaching belongs to the Vapi alternative guide, and the international transfer rules belong to the Synthflow alternative guide. The wider context is familiar: McKinsey's State of AI 2025 found 88% of organisations use AI in at least one function, but only 33% have it in production. A Bland agent that already takes live calls is a production system, which is why a vendor-set rebuild deserves a plan rather than a rushed weekend.
This guide is shipped by the team behind Dilr Voice, a multi-agent voice AI platform that chains specialised agents into a single phone call. Or see DATS, our five-stage method for placing AI where the operating numbers move.
What is Bland changing before 15 November 2026?
Bland is replacing conversational pathways and personas with a new architecture called Bland Agents. Its migration guide says every production agent needs to move to the new architecture by 15 November 2026. A pathway's node graph becomes a pathway inside an agent, a persona's skills become Prompts, and the global prompt becomes the agent's system prompt. Accounts created after 18 September 2026 already run on Bland Agents only.
Bland puts the requirement in one line: "All production agents need to be migrated to the new agent architecture by November 15." The migration guide then maps every old screen to its new home. Call logs, call history and messaging fold into a single Conversations view. Triage becomes Issues. Citations and outcomes become Dispositions, configured on the agent. Phone numbers, SIP, triggers and batches move under a Dispatch area. Evals and scorecards become Evaluations, and scenarios are split between test cases and judges.
Two things are genuinely new rather than renamed. Environments pin a version to staging and production, so shipping becomes a deliberate act rather than a save. Evaluations score an agent's behaviour and can gate that shipping. Both are useful disciplines, and our voice agent QA and testing framework covers release testing in more depth. One thing goes the other way: Bland's guide says boards, reports and analysis presets have no Bland Agents equivalent. If your operations reporting depends on a saved board in the old Analytics page, export what you need before you rely on the new dashboard alone.
This is the third vendor-set platform change in this market this year. Retell users were given notice that multi-prompt agents are being retired, which our Retell AI alternative guide works through, and Synthflow enterprise users were asked to choose a new data region. The pattern is worth naming for a steering group: a platform you rent can change under you on the vendor's timetable, and the testing effort for each change lands on your team.
Does the 15 November deadline stop your calls?
No. Bland's migration is additive, so it only creates new agents and leaves existing pathways, phone numbers, tools and live traffic untouched until you choose to switch. Bland's guide says that after 15 November, pathways still handling traffic are migrated for the customer and the rest are moved into an archive. On Bland's own description, the deadline changes who does the migration, not whether your pathways and numbers survive it.
That distinction matters for how a UK team plans the next three weeks. The real risk is not a dead line on 16 November. It is an agent migrated on your behalf that nobody on your team has tested, because Bland's guide does not say which method it uses for those automatic migrations. Bland's guide says plainly that it recommends not waiting until the deadline, so there is time for testing and promotion. We agree, and we would put it more bluntly for a regulated contact centre: a migration you did not test is a change you did not approve, and your change log should be able to show who signed it off.
Enterprise accounts sit on a different footing. Bland's guide says enterprise customers do not need to run the migration themselves, because their Bland partner runs it with them. If that describes your contract, the planning question shifts from "how do we migrate" to "what evidence do we need before we accept the migrated agent". That evidence list is the same either way: parity on prompts and routing, a clean test run on every call lane, and an agreed rollback. Our AI execution office can run that acceptance step with teams that want an independent pair of hands on the sign-off.
Which of Bland's three migration paths fits your agent?
Bland offers self-serve users three migration paths: migrate on your own with a coding agent, migrate and upgrade, or migrate as is. Migrate as is copies a pathway step for step and is the most predictable. Migrate and upgrade rebuilds the agent and checks it against simulated conversations. Migrate on your own hands the work to a coding agent through Bland's Norm plugin, with a parity audit before anything is written.
The choice is a trade between fidelity and improvement, and it should follow the kind of agent you run. Bland's migration guide describes each path in detail. Here is how we would map them.
Migrate as is suits a regulated script. If your agent reads a disclosure, takes consent, or follows a call flow that a compliance team approved line by line, a copy is what you want. Bland says this path carries a few call-level settings, such as voice, language and maximum duration, from the number bound to the pathway, and reports anything it cannot place rather than dropping it silently. It is quick, but it cannot be cancelled once it starts.
Migrate and upgrade suits an agent you were going to rework anyway. Bland says it runs simulated conversations through the pathway, tests how calls perform, and uses the results to build an optimised agent: "an upgrade, not a copy", in its words. That is also its weakness for a regulated workload, because an upgraded agent is a new agent and needs the same approval as one built from scratch.
Migrate on your own suits a team with an engineer who wants control of every step. The guide describes the Norm plugin carrying a deterministic snapshot builder, a byte-level parity audit of prompts and routing, and a simulation loop that will not report success until its checks pass. It still asks before the first write to your account. The same discipline applies to any platform move, and our AI placement diagnostic is where we would scope that kind of check before any rebuild.
What can break when a pathway becomes an agent?
Bland's own migration guide flags four risks worth testing. Migrate as is keeps End Call nodes hanging up only when every exit from the pathway is an End Call. Running it twice creates two agents, because nothing is deduplicated. Migrate and upgrade simulations call the endpoints your pathway already uses, so they can create real bookings or messages. And migrate as is drops a few smaller settings, each reported as a warning.
Each of these deserves a line on your test plan. Take them in turn.
Call endings. Bland's migration guide warns that if some exits end the call and others fall out of a component, the two cannot be told apart at the exit, so the whole flow returns to the agent instead of hanging up. For a caller, that can mean an agent that keeps talking after the conversation should have ended. The import flags it when it happens, and the fix is to add an End Call node at the agent level. Test every exit, not just the happy path.
Duplicates. Because the migration has no memory of having run, a hesitant second attempt leaves two agents. That is safe, since nothing is overwritten, but it is exactly how the wrong agent gets promoted. Name agents with the date and method before you start.
Live side effects. This is the one we would brief to a COO. Bland warns that migrate and upgrade simulations "can create real bookings, send messages, or update records in your own systems." A simulated caller booking a real appointment slot, or texting a real customer, is an operational incident even though no person dialled in. Before choosing that path, list every webhook and tool the pathway calls, and point any that write data at a test environment. Our guide to warm transfer and context handoff covers the same inventory for transfer endpoints.
Smaller losses. Bland says migrate as is drops three smaller things, each reported as a warning: a pathway's own global prompt when you migrate a persona, exit pointers on fanned-out components, and tool overrides on a persona's skills. Read the warning banner rather than dismissing it, and treat every flagged item as a test case.
How do promotion and API changes move live traffic?
Promotion is the only step that moves calls. Bland's guide says a migrated agent takes no call from anyone until it is promoted to production, and that promotion moves traffic all at once. Teams that place outbound calls through Bland's API must also change their requests, replacing the pathway or persona ID with the new agent ID. Until both happen, phone numbers and integrations keep reaching the old pathway.
Bland's own advice on promotion is short: "Treat it as a switch rather than a dial." The migration guide explains that production is the only environment a real call can reach, and that an agent built and saved but never promoted is the most common reason a new agent appears not to answer. Because there is no gradual ramp in this step, the verification has to happen before the switch, on an agent nobody is calling yet. Bland does offer canary deployments to enterprise customers, but its infrastructure documentation describes those for new releases of the Bland runtime on dedicated infrastructure, not as a way to ramp a migrated agent.
For outbound integrations, Bland's programmatic calls guide says the change is usually small: keep the same endpoint and API key, replace pathway_id or persona_id with agent_id, and remove any pathway_version. If your systems read outcomes or citations after each call, the result parser needs updating too, because citations and outcomes now arrive as Dispositions. Find every place your CRM, dialler or workflow tool calls Bland before promotion day, not after.
Triggers need their own check. Bland's guide notes that triggers created before the agent existed stay in the organisation-wide list and still start the pathway they were pointed at. A team that promotes the agent but forgets an automation can end up running two versions of the same conversation, one on the old pathway and one on the new agent. The cure is boring and effective: a single change ticket listing every number, trigger and integration that must move together. If you want help with that kind of cutover governance, our AI operating model consulting covers it.
Should a UK team migrate inside Bland or switch platform?
In our view, most UK teams on Bland should migrate inside Bland unless the rebuild exposes a problem they already had. Bland's migration is additive, enterprise accounts get partner help, and the new environments and evaluations are real improvements. Switching makes sense when the agent needs rebuilding anyway, when the team wants telephony it controls, or when reporting and integrations would have to be redone regardless.
The useful test is whether you were about to pay most of a platform move's cost anyway. If migrate and upgrade is the right path for your agent, you are already accepting a rebuilt agent that needs fresh approval and testing. If your boards and reports have no equivalent in Bland Agents, you are already rebuilding reporting. If your integrations parse outcomes and citations, you are already changing them. Each of those is work that a move to another platform would also require, so in our view the marginal cost of looking elsewhere is lower this quarter than it will be once the migration is done.
Equally, there are clear reasons to stay. A team on an enterprise contract with a Bland partner running the migration has very little marginal effort to spend. A team with a regulated script that migrates as is, passes parity and promotes cleanly has done its job. And a team that needs deployment options Bland lists, such as running inside its own cloud account or on its own hardware, may not find them elsewhere. Our build, orchestrate or buy guide sets out how that choice looks across the market, and our explainer on orchestration versus a voice platform covers why the layer you buy matters more than the brand.
The decision is cleaner when it is priced in effort, not features. Our voice AI ROI framework gives the method: baseline cost per resolved call today, model the one-off transition effort honestly, and compare it with the effort the Bland migration already demands. Where the two are close, we would stay. Where the migration is already a rebuild, it is worth a second quote.
What does a move off Bland involve for numbers and data?
A move off Bland has two practical threads: where your phone numbers sit and where your call data sits. A team that connected its own Twilio account to Bland starts from numbers held in that account, so a move can begin there. Numbers bought through Bland raise a separate question to put to Bland in writing. On data, Bland says EU data residency is configurable per customer, so confirm in writing where UK call data is processed.
Start with the numbers, because they decide the timetable. Bland's custom Twilio documentation describes a bring-your-own-Twilio option, in which a team connects its own Twilio account and imports numbers that are active there. For a team set up that way, the numbers sat in its own Twilio account before they reached Bland, which is likely to shorten the critical path. Dilr Voice runs its telephony on Twilio or Vobiz, and outbound campaigns use the customer's own Twilio or Vobiz account, so a Twilio-held number is a natural starting point. Confirm with both vendors how each number is configured before you assume it is a simple repoint.
Numbers bought from Bland itself are different. Bland's SIP documentation gives 7 to 14 business days as a typical time for porting numbers into Bland, which is a useful reminder that number moves are carrier processes with paperwork and lead times. The same documentation does not cover porting out, so ask Bland in writing whether and how its numbers can move to another carrier, and ask the gaining provider for its timetable before setting a cutover date.
On data, Bland's trust and security page says EU data residency is available and configurable per customer, and describes per-call regional pinning in which "EU data stays on EU GPUs". The page talks about the EU; it does not name a UK region. For a UK controller that is a question for the contract, not a reason to leave. Our Synthflow alternative guide covers the ICO's international transfer rules in detail, and the same questions apply to any platform you shortlist, including ours. Dilr Voice runs on Google Cloud Platform, encrypted at rest and in transit, with dedicated tenancy and regional data residency options for enterprise customers.
The cutover itself should mirror the discipline Bland asks of its own migration. Build the new agent, run it against recorded scenarios and a shadow period, move one number or one campaign first, and keep the Bland pathway ready to take traffic back until the new line has a clean week. Our enterprise voice AI agents guide covers first deployments in more depth.
If you are weighing a move, our Dilr Voice platform is a multi-agent system where each specialised agent has its own prompt, model and tools and passes context to the next on handover.
What is the best Bland AI alternative for UK teams in 2026?
The best Bland AI alternative for a UK team in 2026 depends on why the team is leaving. For hosted inbound and outbound calls with compliance rules built in, Dilr Voice is a strong candidate. Bland remains the better choice for teams that need self-hosted, private-cloud or air-gapped deployment, or the attestations it publishes. Developer teams may prefer an orchestrator such as Vapi or Retell AI.
We would score any alternative on five criteria. First, call control: can each stage of the call have its own prompt, model and tools, so that a disclosure or consent step stays fixed while a knowledge step adapts? Dilr Voice chains specialised agents, such as greeter, qualifier, knowledge, customer care and action agents, into a single phone call, and passes context on each handover. Second, compliance defaults: Dilr Voice ships per-country rules for recording consent, DNC registry checks, opt-out recognition and permitted calling hours, with full audit trails on every call. Third, telephony: Dilr Voice runs on Twilio or Vobiz, and outbound campaigns use the customer's own Twilio or Vobiz account. Fourth, integrations: HubSpot, Salesforce and Google Calendar are named live, with post-call CRM, email, SMS and Slack updates without code. Fifth, speed: Dilr Voice has a response time under 500 milliseconds on DILR's own on-platform measurement, and supports 30+ languages.
Now the concessions, because they are real. Bland's trust page lists deployment in Bland's cloud, inside a customer's own cloud account, on-premise and air-gapped, and lists attestations including SOC 2 Type II and ISO 27001:2022. Our Dilr Voice FAQ is explicit that Dilr Voice does not hold SOC 2 or HIPAA certification. If your security review requires either of those, or requires the model to run on your own hardware, Bland is the better home and the right move is to migrate inside it. Bland also says it runs its own model and speech rather than wrapping third parties, which can shorten a supplier review.
Developer-led teams have a third route. Orchestrators such as Vapi and Retell AI give engineers raw building blocks, and other platforms such as Synthflow, PolyAI and ElevenLabs suit different buyers again. Our voice AI procurement framework explains how to score them, and the best AI voice agent 2026 guide lays out the market side by side, including pricing. If you want to test Dilr Voice against your own call scripts, the free trial needs no credit card, and our Dilr Voice product page explains the agent types in detail.
Do enterprise Bland customers have to run the migration themselves?
No. Bland's migration guide says enterprise accounts do not need to migrate their pathways and personas themselves, because their Bland partner runs the migration with them. Self-serve accounts choose one of three paths in the dashboard. Either way, the deploying business still owns acceptance: it should check parity, test every call lane and agree a rollback before the migrated agent is promoted to production.
If you would like a second opinion on that acceptance step, contact our team and we will walk through it with you.
Will a migrated Bland agent keep my phone numbers?
Yes, the numbers stay with your organisation, but they do not move to the new agent on their own. Bland's guide says phone numbers belong to the organisation rather than to any one pathway, and that migrate as is does not attach the number to the new agent. Your number keeps ringing the old pathway until you attach it to the agent and promote that agent to production.
That is why a number inventory belongs at the top of the migration plan, whichever platform you end up on. Our voice AI category hub collects the wider buying and compliance reading.
Want to see this in production? Try Dilr Voice live, compare Dilr Voice and Bland side by side, see our DATS methodology, or read about our approach to placing AI inside enterprise systems.
Decide the Bland move on evidence, not the deadline.
30-min scoping call · No deck · Confidential. We will tell you whether to migrate inside Bland or move platform, and what either route costs your team in effort.
Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.