Migrating from IPSoft Amelia to Amazon Lex V2: a field playbook

Most Amelia-to-Lex programs stall for the same reason: teams start with the new bot instead of the old estate. A legacy virtual agent that has run for years accumulates undocumented behavior — escalation rules living in configuration, business logic hidden in integration middleware, and flows nobody has owned since the original vendor team rolled off.

Start with a behavioral inventory

Before designing anything in Lex, extract what the legacy agent actually does: every intent, every slot equivalent, every backend call, and — critically — the escalation and failure paths. Transcripts are the ground truth; configuration exports are the map. We build a traceable inventory sheet that every migrated flow is checked against in UAT.

Design for Lex's shape, don't transliterate

Lex V2 is not a one-to-one target. Bot, locale and intent quotas reward modularization: shared-intent bots for common tasks (authentication, policy lookup) composed behind a Lambda orchestration layer, rather than one monolithic bot per line of business. This is also where you fix ten years of intent sprawl — merging near-duplicate intents while the regression suite still runs against legacy behavior as the oracle.

Cut over in waves, verify in parallel

Phased releases with parallel runs — legacy and Lex serving traffic side by side per flow — turn a terrifying big-bang into a routine release calendar. Conversational regression tests (utterance sets replayed per release) catch intent drift before customers do. The steady state we aim for is a two-week release cycle: small waves, boring deployments.

The payoff isn't just retiring a license. A modular Lex estate with an orchestration layer is the substrate for what comes next: retrieval-grounded answers and agentic tool-calling on Bedrock, added per flow rather than re-platformed again.