Considerations For Chatbot Migration from Amazon Lex to Rasa

Considerations For Chatbot Migration from Amazon Lex to Rasa

And Using The Migration Process As An Opportunity for Chatbot Improvement


Migration of a chatbot or any Conversational AI/UI environment is not something which will happen often. Invariably during the initialization of the chatbot process, organizations opt for a familiar and mainstream solution technology.

With user and functionality growth, impediments to scaling are often encountered, these might include:

Image for post
Amazon Lex Listed Under The Machine Learning Services on AWS.
  • Cloud hosting cost.
  • Some cloud providers charge per functionality added.
  • Lack of collaboration tools.
  • Waiting & being dependent on cloud providers to roll out required features and functionality.
  • Introduction of languages and vernacular.
  • Difficulty in offsetting cost with savings or revenue from the chatbot.
  • The challenge with the big cloud NLU/NLP solutions will always remain the issue of protection of personal information and control of data.

Lex Architecture

There are two general approaches to chatbot architecture. The first being a situation where the elements are combined and cannot be decomposed.

The second is where the components are decomposable and can be used separately.

Image for post
Rasa architecture with the Amazon Lex approach overplayed. With the script being the notable exception.

For instance, with Rasa, the chatbots NLU component can be made available as an API.

Lex follows very much the same approach, where provision is made for intents, entities and the script component. Some of the script can also vest in a Lambda function, but more about that later.


Image for post
Amazon Lex: Adding A New Intent

With Lex, the idea of intents are inline with what IBM and Microsoft (LUIS and Power Virtual Agent) are doing.

Lex allows for the creation of intents for which a range of invocation phrases can be added.

Based on these invocation phrases, an intent can be detected based on user input. Once the journey has entered into a specific intent, the process of collection entities start.

Image for post
Amazon Lex: Sample Utterances Can Be Added For Intents


Firstly, if intents are the verbs, entities are the nouns. In the case of a travel chatbot, entities will be dates, places, modes of transport etc. Lex does not refer these nouns as entities; but rather slots.

If intents are user verbs, then entities can be seen as user nouns. These entities are then closely linked to the intent. Multiple entities can be detected, with each assigned to a different role, or subset. Read more detail on this here.

Image for post
Entity slots are color coded and contextually defined.

Lex does a good job of making sure the slots are all filled, you can set the priority of these slots, if they are mandatory and also configure follow-up prompts to ensure they are filled.


The script for the chatbot will mostly be defined within Lex, and ample provision is made for confirmation prompts, follow-up prompts, and final prompts.

Image for post
Testing basic dialog within the Amazon Lex console.

It is also possible to formulate a customer response, or prompt, within an AWS Lambda Python service, and pass this script or dialog back to Lex.

Dialog Management

The dialog flow (also known as state management or dialog management) is analogous to how Microsoft LUIS fits into the Microsoft bot framework.

Image for post
The Business Logic Required To fulfill the User’s Intent

Lex allows for the configuration of the NLU environment; a NLU API. But for session variables, dialog management and state machine related tasks, you need to connect to a Lambda function. Or, merely use Lex as a NLU API and write your bot framework in another language; like C#, Python, or use an framework like Django.

Chatbot Using Amazon Lex & Lambda Functions

The demo application I wrote was in Python and made use of Lambda for the state management, conditions, decision trees and the like. Lex expects the Lambda function to receive a JSON payload.

Subsequently the Lambda function needs to return a JSON payload to Lex. The connection can be tested via the text console and the JSON payload is visible during testing.

The fact that this leg of the architecture sits outside of the Lex environment can be seen as a strength and also a weakness.

IBM Watson Assistant has a very neat built-in dialog manager with advanced configuration options.

But there are those who prefer to have a programmatic or code environment where it can be developed. Should the chatbot become large, it might become hard to manage and somehow it will have to be segmented.


Let’s look at the migration process in two parts:

  • NLU
  • Dialog


Before you export the Amazon Lex bot, you need to ensure that it is built and published within the console. If not, the elements you see in the console might not reflect in the JSON export file.

So be sure to click on Build and then Publish.

Image for post
Ensure the bot is built and published to ensure all changes are reflected in the exported JSON

When exporting your chatbot from the Lex interface, you have the option to select the appropriate version. Take note there are two platform options; Amazon Lex and Alexa Skills Kit (ASK).

Image for post
Exporting Amazon Lex bot from the AWS console

The SDK option yields a more generic and useable format from a Rasa perspective. JSON queries can be used to extract the data of interest.

Below is an extract from the Lex ASK export… The format is very convenient and similar to the Rasa file.

   "I am getting the car in {PickUpCity} on {PickUpDate} and dropping at George.  I am {DriverAge} and I want {CarType}",   

"I will be getting the car in {PickUpCity} on {PickUpDate} and dropping at George. I am {DriverAge} and I want {CarType}",   

"I will pick up the car in {PickUpCity} on {PickUpDate} and return it at George. I am {DriverAge} and I want {CarType}",   

"I am getting the car in {PickUpCity} on {PickUpDate} and dropping at Cape Town."],

And here is another example from book hotel intent.

   "Book a hotel",   

"I want a make hotel reservations",   

"Book a {Nights} night stay in {Location}"],

Creating intents will be a straight-forward process from the examples. It is convenient that the entity name is defined in the user utterance example denoted with curly brackets.

The only drawback is that entity examples are not included within the utterance examples. So for this step possible manual intervention is required. With file manipulation, entity values can be extracted.

Below is an example of entity/slot names and values. Again, with JSON queries these can be extracted.


{"name":{"value":"full size","synonyms":[]}},

Amazon really encourages developers to use built-in slot types. When exported these are empty, and hence will demand manual intervention to complete.

On entities, Lex have specific prompts and confirmation prompts settings which will lost. Or at least have to be rebuilt.

Dialog Management

The chatbot elements which falls outside of NLU will have to be approach based on the methods employed. It can be assumed that for an Amazon Lex chatbot, the dialog, context and integration portions will most probably vest in a AWS Lambda function.

Each chatbot solution will have to examined to see how these elements can be best migrated to Rasa.

Slots & Forms

With Amazon Lex, slots/entities can be set to mandatory and individual prompts can be set to solicit a response from the user. It all depends on how these individual prompts are employed in your Lex bot.

Should it be used extensively, you might want to to consider using Forms in Rasa.


The upside is that intents and training examples can easily be migrated to Rasa. From an entity perspective, the data is available, with some effort it can also be migrated.

The problem lies with the Amazon specific entities, and Lex specific entity prompt and confirmations; this functionality will have to be instituted.

And obviously the dialog, state management and integration elements will have to be assessed.

Read More Here

Cobus GreylingHi, I’m Cobus… Currently I conceptualize, mock-up, wire-frame, prototype and develop final products. Primarily…

Cobus Greyling – MediumRead writing from Cobus Greyling on Medium. NLP/NLU, Chatbots, Voice, Conversational UI/UX, CX Designer, Developer…

Rasa as Open Source Alternative to Amazon Lex – Migration TipsThere is no support for Amazon Lex yet. However, there seems to be a way to export data into JSON from Lex. If you’re…

Amazon Lex – AWS Chatbot AIConversational AI for Chatbots Amazon Lex is a service for building conversational interfaces into any application…

FormsTo use forms with Rasa Open Source you need to make sure that the Rule Policy is added to your policy configuration…