End of support notice: On September 15, 2025, AWS will discontinue support for Amazon Lex V1. After September 15, 2025, you will no longer be able to access the Amazon Lex V1 console or Amazon Lex V1 resources. If you are using Amazon Lex V2, refer to the [Amazon Lex V2 guide](https://docs.aws.amazon.com/lexv2/latest/dg/what-is.html) instead. . 

# Migrating a bot
<a name="migrate"></a>

The Amazon Lex V2 API uses an updated information architecture that enables simplified resource versioning and support for multiple languages in a bot. For more information, see the [Migration guide](https://docs.aws.amazon.com/lexv2/latest/dg/migration.html) in the *Amazon Lex V2 Developer Guide*. 

To use these new features, you need to migrate your bot. When you migrate a bot, Amazon Lex provides the following:
+ Migration copies your custom intents and slot types to the Amazon Lex V2 bot. 
+ You can add multiple languages to the same Amazon Lex V2 bot. In Amazon Lex V1 you create a separate bot for each language. You can migrate multiple Amazon Lex V1 bots, each using a different language, to one Amazon Lex V2 bot.
+ Amazon Lex maps Amazon Lex V1 built-in slot types and intents to Amazon Lex V2 built-in slot types and intents. If a built-in can't be migrated, Amazon Lex returns a message that tells you what to do next.

The migration process doesn't migrate the following:
+ Aliases
+ Amazon Kendra indexes
+ AWS Lambda functions
+ Conversation log settings
+ Messaging channels such as Slack
+ Tags

To migrate a bot, your user or role must have IAM permission for both Amazon Lex and Amazon Lex V2 API operations. For the required permissions, see [Allow a user to migrate a bot to Amazon Lex V2 APIs](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-migrate).

## Migrating a bot (Console)
<a name="migrating-a-bot"></a>

Use the Amazon Lex V1 console to migrate the structure of a bot to an Amazon Lex V2 bot.

**To use the console to migrate a bot to the Amazon Lex V2 API**

1. Sign in to the AWS Management Console and open the Amazon Lex console at [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/).

1. From the left menu, choose **Migration tool**.

1. From the list of bots, choose the bot that you want to migrate and then choose **Migrate**.

1. Choose the version of the bot that you want to migrate, then enter the name of the bot to migrate to. If you enter the name of an existing Amazon Lex V2 bot, the Amazon Lex V1 bot is migrated to the language shown in the details and overwrites the Draft version of the language.

1. Choose **Next**.

1. Choose the IAM role that Amazon Lex uses to run the Amazon Lex V2 API version of the bot. You can choose to create a new role with the minimum permissions required to run the bot, or you can choose an existing IAM role.

1. Choose **Next**.

1. Review the settings for migration. If they look OK, choose **Start migration**.

After you start the migration process, you are returned to the migration tool start page. You can monitor the progress of the migration in the **History** table. When the **Migration status** column says **Complete** the migration is finished. 

Amazon Lex uses the `StartImport` operation in the Amazon Lex V2 API to import the migrated bot. You'll see an entry in the Amazon Lex V2 console import history table for each migration.

During the migration, Amazon Lex may find resources in the bot that can't be migrated. You get an error or warning message for each resource that can't be migrated. Each message includes a link to documentation that explains how to resolve the issue. 

## Migrating a Lambda function
<a name="migrating-lambda"></a>

Amazon Lex V2 changes the way that Lambda functions are defined for a bot. It only allows one Lambda function in an alias for each language in a bot. For more information on migrating your Lambda functions, see [Migrating a Lambda function from Amazon Lex V1 to Amazon Lex V2](message-lambda.md).

# Migration messages
<a name="migrate-messages"></a>

During migration, Amazon Lex may find resources, such as built-in slot types, that it can't migrate to the equivalent Amazon Lex V2 resource. When this happens, Amazon Lex returns a migration message that describes what happened and provides a link to the documentation that tells you how to fix the migration issue. The following sections describe the issues that might arise when you are migrating a bot and how to fix the issue.

**Topics**
+ [

# Built-in intent
](message-built-in-intent.md)
+ [

# Built-in slot type
](message-built-in-slot-type.md)
+ [

# Conversation logs
](message-logs.md)
+ [

# Message groups
](migrate-message-groups.md)
+ [

# Prompts and phrases
](message-prompts-phrases.md)
+ [

# Other Amazon Lex V1 features
](message-features.md)

# Built-in intent
<a name="message-built-in-intent"></a>

When you use a built-in intent that is not supported in Amazon Lex V2, the intent is mapped to a custom intent in your Amazon Lex V2 bot. The custom intent doesn't contain utterances. To continue using the intent, add sample utterances.

# Built-in slot type
<a name="message-built-in-slot-type"></a>

Any migrated slot that uses a slot type that is not supported in Amazon Lex V2 won't be given a slot type value. To use this slot:
+ Create a custom slot type
+ Add slot type values that are expected for the slot type
+ Update the slot to use the new custom slot type

# Conversation logs
<a name="message-logs"></a>

Migration doesn't update the conversation log settings of the Amazon Lex V2 bot. 

**To configure conversation logs**

1. Open the Amazon Lex V2 console at [ https://console.aws.amazon.com/lexv2 ](https://console.aws.amazon.com/lexv2).

1. From the list of bots, choose the bot whose conversation logs you want to configure.

1. From the left menu, choose **Aliases**, and then choose an alias from the list.

1. In the **Conversation logs** section, choose **Manage conversation logs** to configure conversation logs for the bot alias.

# Message groups
<a name="migrate-message-groups"></a>

Amazon Lex V2 supports only one message and two alternative messages per message group. If you have more than three messages per message group in an Amazon Lex V1 bot, only the first three messages are migrated. To use more messages in a message group, use a Lambda function to output various messages.

# Prompts and phrases
<a name="message-prompts-phrases"></a>

Amazon Lex V2 uses a different mechanism for follow up, clarification, and hang up prompts. 

For follow up prompts, use context carryover to switch to a different intent after fulfillment. 

For example, suppose that you have an intent to book a car rental that is configured to return a output context called `book_car_fulfilled`. When the intent is fulfilled, Amazon Lex sets the output context variable to `book_car_fulfilled`. Since `book_car_fulfilled` is an active context, an intent with `book_car_fulfilled` as an input context is considered for recognition, as long as the user utterance is recognized as an attempt to elicit that intent. You can use this for intents that only make sense after booking a car, such as emailing a receipt or modifying a reservation.

Amazon Lex V2 does not support clarification prompts and hang up phrases (abort statements). Amazon Lex V2 bots contain a default fallback intent that is invoked if no intents are matched. To send a clarification prompt with retries, configure a Lambda function and enable the dialog code hook in the fallback intent. The Lambda function can output a clarification prompt as a response and the retry value in a session attribute. If the retry value exceeds the maximum number of retries, you can output a hang up phrase and close the conversation.

# Other Amazon Lex V1 features
<a name="message-features"></a>

The migration tool supports only migration of Amazon Lex V1 bots and their underlying intents, slot types, and slots. For other features, see the following topics in the Amazon Lex V2 documentation.
+ Bot aliases: [ Aliases ](https://docs.aws.amazon.com/lexv2/latest/dg/aliases.html) 
+ Bot channels: [ Deploying an Amazon Lex V2 bot on a messaging platform ](https://docs.aws.amazon.com/lexv2/latest/dg/deploying-messaging-platform.html) 
+ Conversation log settings: [Monitoring with conversation logs](https://docs.aws.amazon.com/lexv2/latest/dg/monitoring-logs.html) 
+ Amazon Kendra indexes: [ AMAZON.KendraSearchIntent ](https://docs.aws.amazon.com/lexv2/latest/dg/built-in-intent-kendra-search.html) 
+ Lambda functions: [ Using an AWS Lambda function ](https://docs.aws.amazon.com/lexv2/latest/dg/lambda.html) 
+ Tags: [ Tagging resources ](https://docs.aws.amazon.com/lexv2/latest/dg/tagging.html) 

# Migrating a Lambda function from Amazon Lex V1 to Amazon Lex V2
<a name="message-lambda"></a>

Amazon Lex V2 allows only one Lambda function for each language in a bot. The Lambda function and its settings are configured for the bot alias that you use at runtime. 

The Lambda function is invoked for all intents in that language if dialog and fulfillment code hooks are enabled for the intent.

Amazon Lex V2 Lambda functions have a different input and output message format from Amazon Lex V1. These are the differences in the Lambda function input format.
+ Amazon Lex V2 replaces the `currentIntent` and `alternativeIntents` structures with the `interpretations` structure. Each interpretation contains an intent, the NLU confidence score for the intent, and an optional sentiment analysis.
+ Amazon Lex V2 moves the `activeContexts`, `sessionAttributes` in Amazon Lex V1 to the unified `sessionState` structure. This structure provides information about the current state of the conversation, including the originating request ID.
+ Amazon Lex V2 doesn't return the `recentIntentSummaryView`. Use the information in the `sessionState` structure instead.
+ The Amazon Lex V2 input provides the `botId` and `localeId` in the `bot` attribute.
+ The input structure contains an `inputMode` attribute that provides information on the type of input: text, speech, or DTMF.

These are the differences in the Lambda function output format:
+ The `activeContexts` and `sessionAttributes` structures in Amazon Lex V1 are replaced by the `sessionState` structure in Amazon Lex V2.
+ The `recentIntentSummaryView` isn't included in the output.
+ The Amazon Lex V1 `dialogAction` structure is split into two structures, `dialogAction` that is part of the `sessionState` structure, and `messages` that is required when the `dialogAction.type` is `ElicitIntent`. Amazon Lex chooses messages from this structure to show to the user.

When you build a bot with the Amazon Lex V2 APIs, there is only one Lambda function per bot alias per language instead of a Lambda function for each intent. If you want to continue to use separate functions, you can create a router function that activates a separate function for each intent. The following is a router function that you can use or modify for your application.

```
import os
import json
import boto3

# reuse client connection as global
client = boto3.client('lambda') 

def router(event):
    intent_name = event['sessionState']['intent']['name']
    fn_name = os.environ.get(intent_name)
    print(f"Intent: {intent_name} -> Lambda: {fn_name}")
    if (fn_name):
        # invoke lambda and return result
        invoke_response = client.invoke(FunctionName=fn_name, Payload = json.dumps(event))
        print(invoke_response)
        payload = json.load(invoke_response['Payload'])
        return payload
    raise Exception('No environment variable for intent: ' + intent_name)
    
def lambda_handler(event, context):
    print(event)
    response = router(event)
    return response
```

## List of updated fields
<a name="lambda-migrating"></a>

The following tables provide detailed information about the updated fields in the Amazon Lex V2 Lambda request and response. You can use these tables to map fields between the versions.

### Request
<a name="migrating-lambda-request"></a>

The following fields have been updated in the Lambda function request format.

#### Active contexts
<a name="lambda-migrating-contexts"></a>

The `activeContexts` structure is now part of the `sessionState` structure.


| V1 structure | V2 structure | 
| --- | --- | 
|  activeContexts  |  sessionState.activeContexts  | 
|  activeContexts[\$1].timeToLive  |  sessionState.activeContexts[\$1].timeToLive  | 
|  activeContexts[\$1].timeToLive.timeToLiveInSeconds  |  sessionState.activeContexts[\$1].timeToLive.timeToLiveInSeconds  | 
|  activeContexts[\$1].timeToLive.turnsToLive  |  sessionState.activeContexts[\$1].timeToLive.turnsToLive  | 
|  activeContexts[\$1].name  |  sessionState.activeContexts[\$1].name  | 
|  activeContexts[\$1].parameters  |  sessionState.activeContexts[\$1].contextAttributes  | 

#### Alternative intents
<a name="lambda-migrating-alternative"></a>

The interpretations list from index 1 to N contains the list of alternative intents predicted by Amazon Lex V2, along with their confidence scores. The `recentIntentSummaryView` is removed from the request structure in Amazon Lex V2. To see the details from the `recentIntentSummaryView`, use the [GetSession](API_runtime_GetSession.md) operation.


| V1 structure | V2 structure | 
| --- | --- | 
|  alternativeIntents  |  interpretations[1:\$1]  | 
|  recentIntentSummaryView  |  N/A  | 

#### Bot
<a name="lambda-migrating-bot"></a>

In Amazon Lex V2, bots and aliases have identifiers. The bot ID is part of the codehook input. The alias ID is included, but not the alias name. Amazon Lex V2 supports multiple locales for the same bot so the locale ID is included.


| V1 structure | V2 structure | 
| --- | --- | 
|  bot  |  bot  | 
|  bot.name  |  bot.name  | 
|  N/A  |  bot.id  | 
|  bot.alias  |  N/A  | 
|  N/A  |  bot.aliasId  | 
|  bot.version  |  bot.version  | 
|  N/A  |  bot.localeId  | 

#### Current intent
<a name="lambda-migrating-intent"></a>

The `sessionState.intent` structure contains the details of the active intent. Amazon Lex V2 also returns a list of all of the intents, including alternative intents, in the `interpretations` structure. The first element in the interpretations list is always the same as `sessionState.intent`.


| V1 structure | V2 structure | 
| --- | --- | 
|  currentIntent  |  sessionState.intent OR interpretations[0].intent  | 
|  currentIntent.name  |  sessionState.intent.name OR interpretations[0].intent.name  | 
|  currentIntent.nluConfidenceScore  |  interpretations[0].nluConfidence.score  | 

#### Dialog action
<a name="lambda-migrating-dialog"></a>

The `confirmationStatus` field is now part of the `sessionState` structure.


| V1 structure | V2 structure | 
| --- | --- | 
|  currentIntent.confirmationStatus  |  sessionState.intent.confirmationState OR interpretations[0].intent.confirmationState  | 
|  N/A  |  sessionState.intent.state OR interpretations[\$1].intent.state  | 

#### Amazon Kendra
<a name="lambda-migrating-kendra"></a>

The `kendraResponse` field is now part of the `sessionState` and `interpretations` structures.


| V1 structure | V2 structure | 
| --- | --- | 
|  kendraResponse  |  sessionState.intent.kendraResponse OR interpretations[0].intent.kendraResponse  | 

#### Sentiment
<a name="lambda-migrating-sentiment"></a>

The `sentimentResponse` structure is moved to the new `interpretations` structure.


| V1 structure | V2 structure | 
| --- | --- | 
|  sentimentResponse  |  interpretations[0].sentimentResponse  | 
|  sentimentResponse.sentimentLabel  |  interpretations[0].sentimentResponse.sentiment  | 
|  sentimentResponse.sentimentScore  |  interpretations[0].sentimentResponse.sentimentScore  | 

#### Slots
<a name="lambda-migrating-slots"></a>

Amazon Lex V2 provides a single `slots` object inside the `sessionState.intent` structure that contains the resolved values, interpreted value, and the original value of what the user said. Amazon Lex V2 also supports multi-valued slots by setting the `slotShape` as `List` and setting the `values` list. Single-value slots are supported by the `value` field, their shape is assumed to be `Scalar`.


| V1 structure | V2 structure | 
| --- | --- | 
|  currentIntent.slots  |  sessionState.intent.slots OR interpretations[0].intent.slots  | 
|  currentIntent.slots[\$1].value  |  sessionState.intent.slots[\$1].value.interpretedValue OR interpretations[0].intent.slots[\$1].value.interpretedValue  | 
|  N/A  |  sessionState.intent.slots[\$1].value.shape OR interpretations[0].intent.slots[\$1].shape  | 
|  N/A  |  sessionState.intent.slots[\$1].values OR interpretations[0].intent.slots[\$1].values  | 
|  currentIntent.slotDetails  |  sessionState.intent.slots OR interpretations[0].intent.slots  | 
|  currentIntent.slotDetails[\$1].resolutions  |  sessionState.intent.slots[\$1].resolvedValues OR interpretations[0].intent.slots[\$1].resolvedValues  | 
|  currentIntent.slotDetails[\$1].originalValue  |  sessionState.intent.slots[\$1].originalValue OR interpretations[0].intent.slots[\$1].originalValue  | 

#### Others
<a name="lambda-migrating-other"></a>

The Amazon Lex V2 `sessionId` field is the same as the `userId` field in Amazon Lex V1. Amazon Lex V2 also sends the `inputMode` of the caller: text, DTMF, or speech.


| V1 structure | V2 structure | 
| --- | --- | 
|  userId  |  sessionId  | 
|  inputTranscript  |  inputTranscript  | 
|  invocationSource  |  invocationSource  | 
|  outputDialogMode  |  responseContentType  | 
|  messageVersion  |  messageVersion  | 
|  sessionAttributes  |  sessionState.sessionAttributes  | 
|  requestAttributes  |  requestAttributes  | 
|  N/A  |  inputMode  | 
|  N/A  |  originatingRequestId  | 

### Response
<a name="migrating-lambda-response"></a>

The following fields have been changed in the Lambda function response message format.

#### Active contexts
<a name="lambda-migrating-resonse-context"></a>

The `activeContexts` structure moved to the `sessionState` structure.


| V1 structure | V2 structure | 
| --- | --- | 
|  activeContexts  |  sessionState.activeContexts  | 
|  activeContexts[\$1].timeToLive  |  sessionState.activeContexts[\$1].timeToLive  | 
|  activeContexts[\$1].timeToLive.timeToLiveInSeconds  |  sessionState.activeContexts[\$1].timeToLive.timeToLiveInSeconds  | 
|  activeContexts[\$1].timeToLive.turnsToLive  |  sessionState.activeContexts[\$1].timeToLive.turnsToLive  | 
|  activeContexts[\$1].name  |  sessionState.activeContexts[\$1].name  | 
|  activeContexts[\$1].parameters  |  sessionState.activeContexts[\$1].contextAttributes  | 

#### Dialog action
<a name="lambda-migrating-response-dialog"></a>

The `dialogAction` structure moved to the `sessionState` structure. You can now specify multiple messages in a dialog action, and the `genericAttachments` structure is now the `imageResponseCard` structure.


| V1 structure | V2 structure | 
| --- | --- | 
|  dialogAction  |  sessionState.dialogAction  | 
|  dialogAction.type  |  sessionState.dialogAction.type  | 
|  dialogAction.slotToElicit  |  sessionState.intent.dialogAction.slotToElicit  | 
|  dialogAction.type.fulfillmentState  |  sessionState.intent.state  | 
|  dialogAction.message  |  messages  | 
|  dialogAction.message.contentType  |  messages[\$1].contentType  | 
|  dialogAction.message.content  |  messages[\$1].content  | 
|  dialogAction.responseCard  |  messages[\$1].imageResponseCard  | 
|  dialogAction.responseCard.version  |  N/A  | 
|  dialogAction.responseCard.contentType  |  messages[\$1].contentType  | 
|  dialogAction.responseCard.genericAttachments  |  N/A  | 
|  dialogAction.responseCard.genericAttachments[\$1].title  |  messages[\$1].imageResponseCard.title  | 
|  dialogAction.responseCard.genericAttachments[\$1].subTitle  |  messages[\$1].imageResponseCard.subtitle  | 
|  dialogAction.responseCard.genericAttachments[\$1].imageUrl  |  messages[\$1].imageResponseCard.imageUrl  | 
|  dialogAction.responseCard.genericAttachments[\$1].buttons  |  messages[\$1].imageResponseCard.buttons  | 
|  dialogAction.responseCard.genericAttachments[\$1].buttons[\$1].value  |  messages[\$1].imageResponseCard.buttons[\$1].value  | 
|  dialogAction.responseCard.genericAttachments[\$1].buttons[\$1].text  |  messages[\$1].imageResponseCard.buttons[\$1].text  | 
|  dialogAction.kendraQueryRequestPayload  |  dialogAction.kendraQueryRequestPayload  | 
|  dialogAction.kendraQueryFilterString  |  dialogAction.kendraQueryFilterString  | 

#### Intents and slots
<a name="lambda-migrating-response-slots"></a>

Intent and slot fields that were part of the `dialogAction` structure are now part of the `sessionState` structure.


| V1 structure | V2 structure | 
| --- | --- | 
|  dialogAction.intentName  |  sessionState.intent.name  | 
|  dialogAction.slots  |  sessionState.intent.slots  | 
|  dialogAction.slots[\$1].key  |  sessionState.intent.slots[\$1].key  | 
|  dialogAction.slots[\$1].value  |  sessionState.intent.slots[\$1].value.interpretedValue  | 
|  N/A  |  sessionState.intent.slots[\$1].value.shape  | 
|  N/A  |  sessionState.intent.slots[\$1].values  | 

#### Others
<a name="lambda-migrating-response-other"></a>

The `sessionAttributes` structure is now part of the `sessionState` structure. The `recentIntentSummaryReview` structure has been removed.


| V1 structure | V2 structure | 
| --- | --- | 
|  sessionAttributes  |  sessionState.sessionAttributes  | 
|  recentIntentSummaryView  |  N/A  |