Dialogflow ES vs Dialogflow CX: When to Migrate and Why

Every few months someone asks me the same question: "We built our bot on Dialogflow ES years ago — should we migrate to CX?" The honest answer is: it depends on how complex your conversation has actually become, not on how old ES is. Here's how I actually make that call.

The Core Difference, in Practice

ES and CX aren't just two versions of the same product — they're built on different mental models:

• Dialogflow ES is intent-centric. You define intents, contexts pass state between them, and the conversation flow emerges from how contexts activate and deactivate. It's fast to start, but contexts become fragile as the number of intents grows.
• Dialogflow CX is flow-centric. You explicitly design pages, states, and transitions as a visual state machine. It's more upfront work, but the conversation logic stays legible even as it scales.

The short version: ES conversations are implicit and can get tangled; CX conversations are explicit and stay traceable — at the cost of more design effort per flow.

Where ES Still Makes Sense

I wouldn't tell every team to migrate. ES is genuinely still the right call when:

• The bot handles a small, stable set of intents (FAQ-style bots, single-purpose lookups).
• You don't need branching multi-turn flows with lots of state.
• The team is small and needs to ship fast without investing in flow design.

If this describes your bot, migrating to CX is often just added complexity for no real gain.

Signs You've Outgrown ES

These are the patterns that, in my experience, reliably predict an ES project is about to become painful to maintain:

• Context sprawl. You're juggling more than a handful of input/output contexts per intent, and debugging "why didn't intent X trigger" eats real time every sprint.
• Multi-step processes. Bookings, applications, or anything with a clear sequence of steps benefits enormously from CX's explicit pages and transitions.
• Multiple teams editing the same agent. CX's page-based structure isolates changes much better than ES's global context soup.
• You need built-in state machine visualization for stakeholders. CX's flow diagrams double as documentation that non-technical stakeholders can actually follow.

What Actually Changes When You Migrate

A few things worth knowing before you commit:

• There's no automatic migration tool that gets you all the way there. Google provides some tooling to bring over training phrases and entities, but flow logic has to be redesigned, not copy-pasted. Budget real design time, not just "porting" time.
• State management changes. ES contexts become CX parameters and page transitions — conceptually similar, but you'll rebuild the logic rather than translate it line by line.
• Webhook fulfillment structure changes. If you have custom fulfillment logic, expect to rewrite the request/response handling for CX's format.
• Pricing model differs. CX is priced per session rather than per request, which changes cost dynamics depending on your conversation length and volume — worth modeling before migrating, not after.

How I Approach the Decision

When a team asks me this, I look at three things before answering:

1. Complexity of the current flow — count real branching paths, not just intents.
2. Rate of change — how often does the conversation design itself change? CX's structure pays off faster if you iterate often.
3. Team size and ownership — more than one or two people touching the agent is a strong vote for CX's isolation.

If two of the three point toward CX, migrating is usually worth it. If none do, I'd rather see the team invest that effort in making the ES bot's intents cleaner than in a migration.

Update: CX Is Now Part of "Conversational Agents"

Since this post was first written, Google has been positioning Dialogflow CX as part of a broader Conversational Agents platform. Alongside deterministic flows, you can now build with generative playbooks, data stores and tool-based actions in the same agent. That strengthens the case for CX on any new project that needs generative features, since those capabilities live on the CX side. If you land on CX, the next decision is where to use flows and where to use playbooks, which I cover in Playbooks vs Flows in Dialogflow CX.

Bottom Line

CX isn't strictly "better" — it's built for a different level of conversational complexity. Migrating a simple FAQ bot to CX adds overhead with no payoff. Leaving a genuinely multi-step, multi-team conversational flow on ES, on the other hand, is how projects quietly become unmaintainable. The right call comes from looking at your actual flow complexity, not the calendar age of your ES agent.

---

I'm a Solution Architect and Full Stack Developer working across React, Node.js, and Google Cloud's conversational AI stack (Dialogflow ES/CX, Vertex AI, ADK). If you're weighing a migration and want a second opinion on your specific flow, feel free to reach out.