Phase 1: Migrate the UI from Studio Classic to Studio - Amazon SageMaker
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Phase 1: Migrate the UI from Studio Classic to Studio

The first phase for migrating an existing domain involves migrating the UI from Amazon SageMaker Studio Classic to Amazon SageMaker Studio.

Phase 1 consists of the following steps:

  1. Create a test domain to verify configurations before migrating the existing domain.

  2. Migrate the existing domain.

  3. Clean up the test domain.

Prerequisites

Before running these steps, complete the prerequisites in Prerequisites.

Step 1: Create a test domain

Before you migrate your existing domain from Studio Classic to Studio, we recommend creating a test domain using Studio with the same configurations as your existing domain. Use this test domain to interact with Studio, test out networking configurations, and launch applications, before migrating the existing domain.

  1. Get the domain ID of your existing domain.

    1. Open the Amazon SageMaker console at https://console.aws.amazon.com/sagemaker/.

    2. From the left navigation pane, expand Admin configurations and choose Domains.

    3. Choose the existing domain.

    4. On the Domain details page, choose the Domain settings tab.

    5. Copy the Domain ID.

  2. Add the domain ID of your existing domain.

    export REF_DOMAIN_ID="domain-id" export SM_REGION="region"
  3. Use describe-domain to get important information about the existing domain.

    export REF_EXECROLE=$(aws sagemaker describe-domain --region=$SM_REGION --domain-id=$REF_DOMAIN_ID | jq -r '.DefaultUserSettings.ExecutionRole') export REF_VPC=$(aws sagemaker describe-domain --region=$SM_REGION --domain-id=$REF_DOMAIN_ID | jq -r '.VpcId') export REF_SIDS=$(aws sagemaker describe-domain --region=$SM_REGION --domain-id=$REF_DOMAIN_ID | jq -r '.SubnetIds | join(",")') export REF_SGS=$(aws sagemaker describe-domain --region=$SM_REGION --domain-id=$REF_DOMAIN_ID | jq -r '.DefaultUserSettings.SecurityGroups | join(",")') export AUTHMODE=$(aws sagemaker describe-domain --region=$SM_REGION --domain-id=$REF_DOMAIN_ID | jq -r '.AuthMode')
  4. Validate the parameters.

    echo "Execution Role: $REF_EXECROLE || VPCID: $REF_VPC || SubnetIDs: $REF_SIDS || Security GroupIDs: $REF_SGS || AuthMode: $AUTHMODE"
  5. Create a test domain using the configurations from the existing domain.

    IFS=',' read -r -a subnet_ids <<< "$REF_SIDS" IFS=',' read -r -a security_groups <<< "$REF_SGS" security_groups_json=$(printf '%s\n' "${security_groups[@]}" | jq -R . | jq -s .) aws sagemaker create-domain \ --domain-name "TestV2Config" \ --vpc-id $REF_VPC \ --auth-mode $AUTHMODE \ --subnet-ids "${subnet_ids[@]}" \ --app-network-access-type VpcOnly \ --default-user-settings " { \"ExecutionRole\": \"$REF_EXECROLE\", \"StudioWebPortal\": \"ENABLED\", \"DefaultLandingUri\": \"studio::\", \"SecurityGroups\": $security_groups_json } "
  6. After the test domain is In Service, use the test domain's ID to create a user profile. This user profile is used to launch and test applications.

    aws sagemaker create-user-profile \ --region="$SM_REGION" --domain-id=test-domain-id \ --user-profile-name test-network-user

Update application creation permissions

After the test domain is In Service, update the test domain's execution role to grant users permissions to create applications.

  1. Create an Amazon Identity and Access Management policy with one of the following contents by following the steps in Creating IAM policies:

    • Use the following policy to grant permissions for all application types and spaces.

      Note

      If the test domain uses the SageMakerFullAccess policy, you do not need to perform this action. SageMakerFullAccess grants permissions to create all applications.

      { "Version": "2012-10-17", "Statement": [ { "Sid": "SMStudioUserProfileAppPermissionsCreateAndDelete", "Effect": "Allow", "Action": [ "sagemaker:CreateApp", "sagemaker:DeleteApp" ], "Resource": "arn:aws:sagemaker:region:account-id:app/*", "Condition": { "Null": { "sagemaker:OwnerUserProfileArn": "true" } } }, { "Sid": "SMStudioCreatePresignedDomainUrlForUserProfile", "Effect": "Allow", "Action": [ "sagemaker:CreatePresignedDomainUrl" ], "Resource": "arn:aws:sagemaker:region:account-id:user-profile/${sagemaker:DomainId}/${sagemaker:UserProfileName}" }, { "Sid": "SMStudioAppPermissionsListAndDescribe", "Effect": "Allow", "Action": [ "sagemaker:ListApps", "sagemaker:ListDomains", "sagemaker:ListUserProfiles", "sagemaker:ListSpaces", "sagemaker:DescribeApp", "sagemaker:DescribeDomain", "sagemaker:DescribeUserProfile", "sagemaker:DescribeSpace" ], "Resource": "*" }, { "Sid": "SMStudioAppPermissionsTagOnCreate", "Effect": "Allow", "Action": [ "sagemaker:AddTags" ], "Resource": "arn:aws:sagemaker:region:account-id:*/*", "Condition": { "Null": { "sagemaker:TaggingAction": "false" } } }, { "Sid": "SMStudioRestrictSharedSpacesWithoutOwners", "Effect": "Allow", "Action": [ "sagemaker:CreateSpace", "sagemaker:UpdateSpace", "sagemaker:DeleteSpace" ], "Resource": "arn:aws:sagemaker:region:account-id:space/${sagemaker:DomainId}/*", "Condition": { "Null": { "sagemaker:OwnerUserProfileArn": "true" } } }, { "Sid": "SMStudioRestrictSpacesToOwnerUserProfile", "Effect": "Allow", "Action": [ "sagemaker:CreateSpace", "sagemaker:UpdateSpace", "sagemaker:DeleteSpace" ], "Resource": "arn:aws:sagemaker:region:account-id:space/${sagemaker:DomainId}/*", "Condition": { "ArnLike": { "sagemaker:OwnerUserProfileArn": "arn:aws:sagemaker:us-east-1:account-id:user-profile/${sagemaker:DomainId}/${sagemaker:UserProfileName}" }, "StringEquals": { "sagemaker:SpaceSharingType": [ "Private", "Shared" ] } } }, { "Sid": "SMStudioRestrictCreatePrivateSpaceAppsToOwnerUserProfile", "Effect": "Allow", "Action": [ "sagemaker:CreateApp", "sagemaker:DeleteApp" ], "Resource": "arn:aws:sagemaker:region:account-id:app/${sagemaker:DomainId}/*", "Condition": { "ArnLike": { "sagemaker:OwnerUserProfileArn": "arn:aws:sagemaker:us-east-1:account-id:user-profile/${sagemaker:DomainId}/${sagemaker:UserProfileName}" }, "StringEquals": { "sagemaker:SpaceSharingType": [ "Private" ] } } }, { "Sid": "AllowAppActionsForSharedSpaces", "Effect": "Allow", "Action": [ "sagemaker:CreateApp", "sagemaker:DeleteApp" ], "Resource": "arn:aws:sagemaker:*:*:app/${sagemaker:DomainId}/*/*/*", "Condition": { "StringEquals": { "sagemaker:SpaceSharingType": [ "Shared" ] } } } ] }
    • Because Studio shows an expanded set of applications, users may have access to applications that weren't displayed before. Administrators can limit access to these default applications by creating an Amazon Identity and Access Management (IAM) policy that grants denies permissions for some applications to specific users.

      Note

      Application type can be either jupyterlab or codeeditor.

      { "Version": "2012-10-17", "Statement": [ { "Sid": "DenySageMakerCreateAppForSpecificAppTypes", "Effect": "Deny", "Action": "sagemaker:CreateApp", "Resource": "arn:aws:sagemaker:region:account-id:app/domain-id/*/app-type/*" } ] }
  2. Attach the policy to the execution role of the test domain. For instructions, follow the steps in Adding IAM identity permissions (console).

Test Studio functionality

Launch the test domain using the test-network-user user profile. We suggest that you thoroughly test the Studio UI and create applications to test Studio functionality in VPCOnly mode. Test the following workflows:

  • Create a new JupyterLab Space, test environment and connectivity.

  • Create a new Code Editor, based on Code-OSS, Visual Studio Code - Open Source Space, test environment and connectivity.

  • Launch a new Studio Classic App, test environment and connectivity.

  • Test Amazon Simple Storage Service connectivity with test read and write actions.

If these tests are successful, then upgrade the existing domain. If you encounter any failures, we recommended fixing your environment and connectivity issues before updating the existing domain.

Step 2: Migrate the existing domain

After you have tested Studio functionality with the configurations in your test domain, migrate the existing domain. When Studio is the default experience for a domain, Studio is the default experience for all users in the domain. However, the user settings takes precedence over the domain settings. Therefore, if a user has their default experience set to Studio Classic in their user settings, then that user will have Studio Classic as their default experience.

You can migrate the existing domain by updating it from the SageMaker console, the Amazon CLI, or Amazon CloudFormation. Choose one of the following tabs to view the relevant instructions.

You can set Studio as the default experience for the existing domain by using the SageMaker console.

  1. Open the Amazon SageMaker console at https://console.aws.amazon.com/sagemaker/.

  2. From the left navigation pane expand Admin configurations and choose Domains.

  3. Choose the existing domain that you want to enable Studio as the default experience for.

  4. On the Domain details page expand Enable the new Studio.

  5. (Optional) To view the details about the steps involved in enabling Studio as your default experience, choose View details. The page shows the following.

    • In the SageMaker Studio Overview section you can view the applications that are included or available in the Studio web-based interface.

    • In the Enablement process section you can view descriptions of the workflow tasks to enable Studio.

      Note

      You will need to migrate your data manually. For instructions about migrating your data, see Phase 3: Migrate data.

    • In the Revert to Studio Classic experience section you can view how to revert back to Studio Classic after enabling Studio as your default experience.

  6. To begin the process to enable Studio as your default experience, choose Enable the new Studio.

  7. In the Specify and configure role section, you can view the default applications that are automatically included in Studio.

    To prevent users from running these applications, choose the Amazon Identity and Access Management (IAM) Role that has an IAM policy that denies access. For information about how to create a policy to limit access, see Update application creation permissions.

  8. In the Choose default S3 bucket to attach CORS policy section, you can give Studio access to Amazon S3 buckets. The default Amazon S3 bucket, in this case, is the default Amazon S3 bucket for your Studio Classic. In this step you can do the following:

    • Verify the domain’s default Amazon S3 bucket to attach the CORS policy to. If your domain does not have a default Amazon S3 bucket, SageMaker creates an Amazon S3 bucket with the correct CORS policy attached.

    • You can include 10 additional Amazon S3 buckets to attach the CORS policy to.

      If you wish to include more than 10 buckets, you can add them manually. For more information about manually attaching the CORS policy to your Amazon S3 buckets, see Update your CORS policy to access Amazon S3 buckets.

    To proceed, select the check box next to Do you agree to overriding any existing CORS policy on the chosen Amazon S3 buckets?.

  9. The Migrate data section contains information about the different data storage volumes for Studio Classic and Studio. Your data will not be migrated automatically through this process. For instructions about migrating your data, lifecycle configurations, and JupyterLab extensions, see Phase 3: Migrate data.

  10. Once you have completed the tasks on the page and verified your configuration, choose Enable the new Studio.

To set Studio as the default experience for the existing domain using the Amazon CLI, use the update-domain call. You must set ENABLED as the value for StudioWebPortal, and set studio:: as the value for DefaultLandingUri as part of the default-user-settings parameter. 

StudioWebPortal indicates if the Studio experience is the default experience and DefaultLandingUri indicates the default experience that the user is directed to when accessing the domain. In this example, setting these values on a domain level (in default-user-settings) makes Studio the default experience for users within the domain.

If a user within the domain has their StudioWebPortal set to DISABLED and DefaultLandingUri set to app:JupyterServer: on a user level (in UserSettings), this takes precedence over the domain settings. In other words, that user will have Studio Classic as their default experience, regardless of the domain settings.

The following code example shows how to set Studio as the default experience for users within the domain:

aws sagemaker update-domain \ --domain-id existing-domain-id \ --region Amazon Web Services Region \ --default-user-settings ' { "StudioWebPortal": "ENABLED", "DefaultLandingUri": "studio::" } '
  • To obtain your existing-domain-id, use the following instructions:

    To get existing-domain-id
    1. Open the Amazon SageMaker console at https://console.aws.amazon.com/sagemaker/.

    2. From the left navigation pane, expand Admin configurations and choose Domains.

    3. Choose the existing domain.

    4. On the Domain details page, choose the Domain settings tab.

    5. Copy the Domain ID.

  • To ensure you are using the correct Amazon Web Services Region for your domain, use the following instructions:

    To get Amazon Web Services Region
    1. Open the Amazon SageMaker console at https://console.aws.amazon.com/sagemaker/.

    2. From the left navigation pane, expand Admin configurations and choose Domains.

    3. Choose the existing domain.

    4. On the Domain details page, verify that this is the existing domain.

    5. Expand the Amazon Web Services Region dropdown list from the top right of the SageMaker console, and use the corresponding Amazon Web Services Region ID to the right of your Amazon Web Services Region name. For example, us-west-1.

After you migrate your default experience to Studio, you can give Studio access to Amazon S3 buckets. For example, you can include access to your Studio Classic default Amazon S3 bucket and additional Amazon S3 buckets. To do so, you must manually attach a Cross-Origin Resource Sharing (CORS) configuration to the Amazon S3 buckets. For more information about how to manually attach the CORS policy to your Amazon S3 buckets, see Update your CORS policy to access Amazon S3 buckets.

Similarly, you can set Studio as the default experience when you create a domain from the Amazon CLI using the create-domain call. 

You can set the default experience when creating a domain using the Amazon CloudFormation. For an Amazon CloudFormation migration template, see SageMaker Studio Administrator IaC Templates. For more information about creating a domain using Amazon CloudFormation, see Creating Amazon SageMaker domain using Amazon CloudFormation.

For information about the domain resource supported by Amazon CloudFormation, see Amazon::SageMaker::Domain.

After you migrate your default experience to Studio, you can give Studio access to Amazon S3 buckets. For example, you can include access to your Studio Classic default Amazon S3 bucket and additional Amazon S3 buckets. To do so, you must manually attach a Cross-Origin Resource Sharing (CORS) configuration to the Amazon S3 buckets. For information about how to manually attach the CORS policy to your Amazon S3 buckets, see Update your CORS policy to access Amazon S3 buckets.

Update your CORS policy to access Amazon S3 buckets

In Studio Classic, users can create, list, and upload files to Amazon Simple Storage Service (Amazon S3) buckets. To support the same experience in Studio, administrators must attach a Cross-Origin Resource Sharing (CORS) configuration to the Amazon S3 buckets. This is required because Studio makes Amazon S3 calls from the internet browser. The browser invokes CORS on behalf of users. As a result, all of the requests to Amazon S3 buckets fail unless the CORS policy is attached to the Amazon S3 buckets.

You may need to manually attach the CORS policy to Amazon S3 buckets for the following reasons.

  • If there is already an existing Amazon S3 default bucket that doesn’t have the correct CORS policy attached when you migrate the existing domain's default experience to Studio.

  • If you are using the Amazon CLI to migrate the existing domain's default experience to Studio. For information about using the Amazon CLI to migrate, see Set Studio as the default experience for the existing domain using the Amazon CLI.

  • If you want to attach the CORS policy to additional Amazon S3 buckets.

Note

If you plan to use the SageMaker console to enable Studio as your default experience, the Amazon S3 buckets that you attach the CORS policy to will have their existing CORS policies overridden during the migration. For this reason, you can ignore the following manual instructions.

However, if you have already used the SageMaker console to migrate and want to include more Amazon S3 buckets to attach the CORS policy to, then continue with the following manual instructions.

The following procedure shows how to manually add a CORS configuration to an Amazon S3 bucket.

To add a CORS configuration to an Amazon S3 bucket
  1. Verify that there is an Amazon S3 bucket in the same Amazon Web Services Region as the existing domain with the following name. For instructions, see Viewing the properties for an Amazon S3 bucket.

    sagemaker-region-account-id
  2. Add a CORS configuration with the following content to the default Amazon S3 bucket. For instructions, see Configuring cross-origin resource sharing (CORS).

    [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "POST", "PUT", "GET", "HEAD", "DELETE" ], "AllowedOrigins": [ "https://*.sagemaker.aws" ], "ExposeHeaders": [ "ETag", "x-amz-delete-marker", "x-amz-id-2", "x-amz-request-id", "x-amz-server-side-encryption", "x-amz-version-id" ] } ]

Migrate from Data Wrangler in Studio Classic to SageMaker Canvas

Amazon SageMaker Data Wrangler exists as its own feature in the Studio Classic experience. When you enable Studio as your default experience, use the Amazon SageMaker Canvas application to access Data Wrangler functionality. SageMaker Canvas is an application in which you can train and deploy machine learning models without writing any code, and Canvas provides data preparation features powered by Data Wrangler.

The new Studio experience doesn’t support the classic Data Wrangler UI, and you must create a Canvas application if you want to continue using Data Wrangler. However, you must have the necessary permissions to create and use Canvas applications.

Complete the following steps to attach the necessary permissions policies to your SageMaker domain's or user’s Amazon IAM role.

To grant permissions for Data Wrangler functionality inside Canvas
  1. Attach the Amazon managed policy AmazonSageMakerFullAccess to your user’s IAM role. For a procedure that shows you how to attach IAM policies to a role, see Adding IAM identity permissions (console) in the Amazon IAM User Guide.

    If this permissions policy is too permissive for your use case, you can create scoped-down policies that include at least the following permissions:

    { "Sid": "AllowStudioActions", "Effect": "Allow", "Action": [ "sagemaker:CreatePresignedDomainUrl", "sagemaker:DescribeDomain", "sagemaker:ListDomains", "sagemaker:DescribeUserProfile", "sagemaker:ListUserProfiles", "sagemaker:DescribeSpace", "sagemaker:ListSpaces", "sagemaker:DescribeApp", "sagemaker:ListApps" ], "Resource": "*" }, { "Sid": "AllowAppActionsForUserProfile", "Effect": "Allow", "Action": [ "sagemaker:CreateApp", "sagemaker:DeleteApp" ], "Resource": "arn:aws:sagemaker:region:account-id:app/domain-id/user-profile-name/canvas/*", "Condition": { "Null": { "sagemaker:OwnerUserProfileArn": "true" } } }
  2. Attach the Amazon managed policy AmazonSageMakerCanvasDataPrepFullAccess to your user’s IAM role.

After attaching the necessary permissions, you can create a Canvas application and log in. For more information, see Getting started with using Amazon SageMaker Canvas.

When you’ve logged into Canvas, you can directly access Data Wrangler and begin creating data flows. For more information, see Prepare data in the Canvas documentation.

Migrate from Autopilot in Studio Classic to SageMaker Canvas

Amazon SageMaker Autopilot exists as its own feature in the Studio Classic experience. When you migrate to using the updated Studio experience, use the Amazon SageMaker Canvas application to continue using the same automated machine learning (AutoML) capabilities via a user interface (UI). SageMaker Canvas is an application in which you can train and deploy machine learning models without writing any code, and Canvas provides a UI to run your AutoML tasks.

The new Studio experience doesn’t support the classic Autopilot UI. You must create a Canvas application if you want to continue using Autopilot's AutoML features via a UI.

However, you must have the necessary permissions to create and use Canvas applications.

  • If you are accessing SageMaker Canvas from Studio, add those permissions to the execution role of your SageMaker domain or user profile.

  • If you are accessing SageMaker Canvas from the Console, add those permissions to your user’s Amazon IAM role.

  • If you are accessing SageMaker Canvas via a presigned URL, add those permissions to the IAM role that you're using for Okta SSO access.

To enable AutoML capabilities in Canvas, add the following policies to your execution role or IAM user role.

  • Amazon managed policy: CanvasFullAccess.

  • Inline policy:

    { "Sid": "AllowAppActionsForUserProfile", "Effect": "Allow", "Action": [ "sagemaker:CreateApp", "sagemaker:DeleteApp" ], "Resource": "arn:aws:sagemaker:region:account-id:app/domain-id/user-profile-name/canvas/*", "Condition": { "Null": { "sagemaker:OwnerUserProfileArn": "true" } } }
To attach IAM policies to an execution role
  1. Find the execution role attached to your SageMaker user profile
    1. In the SageMaker console https://console.amazonaws.cn/sagemaker/, navigate to Domains, then choose your SageMaker domain.

    2. The execution role ARN is listed under Execution role on the User Details page of your user profile. Make note of the execution role name in the ARN.

    3. In the IAM console https://console.amazonaws.cn/iam/, choose Roles.

    4. Search for your role by name in the search field.

    5. Select the role.

  2. Add policies to the role

    1. In the IAM console https://console.amazonaws.cn/iam/, choose Roles.

    2. Search for your role by name in the search field.

    3. Select the role.

    4. In the Permissions tab, navigate to the dropdown menu Add permissions.

      • For managed policies: Select Attach policies, search for the name of the manage policy you want to attach.

        Select the policy then choose Add permissions.

      • For inline policies: Select Create inline policy, paste your policy in the JSON tab, choose next, name your policy, and choose Create.

For a procedure that shows you how to attach IAM policies to a role, see Adding IAM identity permissions (console) in the Amazon IAM User Guide.

After attaching the necessary permissions, you can create a Canvas application and log in. For more information, see Getting started with using Amazon SageMaker Canvas.

Clean up test domain resources

After you have migrated the existing domain, clean up test domain resources.

  1. Add the test domain's ID.

    export TEST_DOMAIN="test-domain-id" export SM_REGION="region"
  2. List all applications in the domain that are in a running state.

    active_apps_json=$(aws sagemaker list-apps --region=$SM_REGION --domain-id=$TEST_DOMAIN) echo $active_apps_json
  3. Parse the JSON list of running applications and delete them. If users attempted to create an application that they do not have permissions for, there may be spaces that are not captured in the following script. You must manually delete these spaces.

    echo "$active_apps_json" | jq -c '.Apps[]' | while read -r app; do if echo "$app" | jq -e '. | has("SpaceName")' > /dev/null; then app_type=$(echo "$app" | jq -r '.AppType') app_name=$(echo "$app" | jq -r '.AppName') domain_id=$(echo "$app" | jq -r '.DomainId') space_name=$(echo "$app" | jq -r '.SpaceName') echo "Deleting App - AppType: $app_type || AppName: $app_name || DomainId: $domain_id || SpaceName: $space_name" aws sagemaker delete-app --region=$SM_REGION --domain-id=$domain_id \ --app-type $app_type --app-name $app_name --space-name $space_name echo "Deleting Space - AppType: $app_type || AppName: $app_name || DomainId: $domain_id || SpaceName: $space_name" aws sagemaker delete-space --region=$SM_REGION --domain-id=$domain_id \ --space-name $space_name else app_type=$(echo "$app" | jq -r '.AppType') app_name=$(echo "$app" | jq -r '.AppName') domain_id=$(echo "$app" | jq -r '.DomainId') user_profile_name=$(echo "$app" | jq -r '.UserProfileName') echo "Deleting Studio Classic - AppType: $app_type || AppName: $app_name || DomainId: $domain_id || UserProfileName: $user_profile_name" aws sagemaker delete-app --region=$SM_REGION --domain-id=$domain_id \ --app-type $app_type --app-name $app_name --user-profile-name $user_profile_name fi done
  4. Delete the test user profile.

    aws sagemaker delete-user-profile \ --region=$SM_REGION --domain-id=$TEST_DOMAIN \ --user-profile-name "test-network-user"
  5. Delete the test domain.

    aws sagemaker delete-domain \ --region=$SM_REGION --domain-id=$TEST_DOMAIN

Troubleshooting

Administrators can revert to Studio Classic as the default experience for the existing domain by updating the domain. This can be done through the SageMaker console or the Amazon CLI. Choose one of the following tabs to view the relevant instructions.

When Studio Classic is the default experience for the domain, Studio Classic is the default experience for all users in the domain. However, the user settings takes precedence over the domain settings. So if a user has their default experience set to Studio, then that user will have Studio as their default experience.

To revert to Studio Classic as the default experience using the SageMaker console, use the following instructions.

  1. Open the Amazon SageMaker console at https://console.aws.amazon.com/sagemaker/.

  2. From the left navigation pane expand Admin configurations and choose Domains.

  3. Choose the existing domain to revert.

  4. Choose the Domain settings tab.

  5. On the Domain details page, navigate to the Revert to Studio Classic experience section.

  6. In the Revert to Studio Classic experience section choose Revert to Studio Classic process. This will take you to the Revert domain to Studio Classic page.

  7. On the Revert domain to Studio Classic page, complete the following tasks and select the corresponding boxes. Go through the following tasks before reverting the existing domain's default experience to Studio Classic:

    1. Step 1 - Back up your data contains information about the different data storage volumes for Studio Classic and Studio. Your data will not be migrated automatically through this process. For instructions about migrating your data, lifecycle configurations, and JupyterLab extensions, see Phase 3: Migrate data.

    2. Delete all JupyterLab and Code Editor applications from Studio reminds you to delete your Studio applications to avoid additional charge. This is not a mandatory step because you can delete your applications and spaces after reverting the existing domain to Studio Classic. We recommend that you delete your unused applications and spaces to avoid additional costs from them.

      For instructions on how to delete applications and spaces from your domain, see Delete or stop your Studio running instances, applications, and spaces.

    3. Step 3 - Confirm you want to revert this domain to Studio Classic asks you to confirm your intention to revert the existing domain's default experience to Studio Classic.

    4. Provide feedback provides the option to leave feedback on the reason you are reverting the existing domain to Studio Classic.

  8. Once all of the steps have been completed and the check boxes are filled, the Revert domain to Studio Classic button becomes available.

  9. After you complete the tasks on the page and verify your changes, choose Revert domain to Studio Classic to revert the existing domain.

To revert to Studio Classic as the default experience for the existing domain using the Amazon CLI, use the update-domain call. You must set DISABLED as the value for StudioWebPortal and app:JupyterServer: as the value for DefaultLandingUrias part of the default-user-settings parameter. 

StudioWebPortal indicates if the Studio experience is the default experience and DefaultLandingUri indicates the default experience that the user is directed to when accessing the domain. In this example, setting these values on a domain level (in default-user-settings) makes Studio Classic the default experience for users within the domain.

If a user within the domain has their StudioWebPortal set to ENABLED and DefaultLandingUri set to studio:: on a user level (in UserSettings), this takes precedence over the domain settings. In other words, that user will have Studio as their default experience, regardless of the domain settings.

The following code example shows how to set Studio Classic as the default experience for users within the domain:

aws sagemaker update-domain \ --domain-id existing-domain-id \ --region Amazon Web Services Region \ --default-user-settings ' { "StudioWebPortal": "DISABLED", "DefaultLandingUri": "app:JupyterServer:" } '
  • To obtain your existing-domain-id, use the following instructions:

    To get existing-domain-id
    1. Open the Amazon SageMaker console at https://console.aws.amazon.com/sagemaker/.

    2. From the left navigation pane, expand Admin configurations and choose Domains.

    3. Choose the existing domain.

    4. On the Domain details page, choose the Domain settings tab.

    5. Copy the Domain ID.

  • To obtain your Amazon Web Services Region, use the following instructions to ensure you are using the correct Amazon Web Services Region for your domain:

    To get Amazon Web Services Region
    1. Open the Amazon SageMaker console at https://console.aws.amazon.com/sagemaker/.

    2. From the left navigation pane, expand Admin configurations and choose Domains.

    3. Choose the existing domain.

    4. On the Domain details page, verify that this is the existing domain.

    5. Expand the Amazon Web Services Region dropdown list from the top right of the SageMaker console, and use the corresponding Amazon Web Services Region ID to the right of your Amazon Web Services Region name. For example, us-west-1.