Snowpark Migration Accelerator: Understanding the Assessment Summary¶

Spark API Readiness Score¶

This report includes several items, with the Readiness Score being the most important metric.

Let’s examine each section in detail:

1. Readiness Score - The Spark API Readiness Score is the main metric that SMA uses to evaluate how ready your code is for migration. This score represents the percentage of Spark API references that can be converted to Snowpark API. While this score is useful, it only considers Spark API references and doesn’t account for third-party libraries or other factors. Therefore, use it as an initial assessment rather than a complete evaluation.

   The score is calculated by dividing the number of convertible Spark API references by the total number of Spark API references found in your code. For example, if the score shows 3541/3746, it means 3541 references can be converted out of 3746 total references. A higher score indicates better compatibility with Snowpark API. You can find this score on the first page of the detailed report.

2. Suggestion on what to do next - Based on your readiness score, SMA provides recommendations for your next steps in the migration process.

3. Explanation of the Readiness Score - This section provides details about what the Spark API Readiness score means and how to interpret your results.

4. Readiness Score Breakdown - This section shows how your score was calculated using two key metrics:

   • Usages ready for conversion: The number of Spark API references (functions, elements, or import statements) that can be converted to Snowpark

   • Identified usages: The total number of Spark API references found in your code

Third-Party Libraries Readiness Score¶

The Third-Party Libraries Readiness Score will be displayed in the following format:

1. Readiness Score - Displays your readiness score and its category (green, yellow, or red). The Third-Party Libraries Readiness Score shows what percentage of your imported libraries are supported by Snowflake. For more details, see the Third-Party API Readiness Score section.

2. Next Steps - Based on your readiness score, SMA provides recommendations for your next actions.

3. Score Explanation - Describes what the Third-Party Libraries Readiness score means and how to interpret your results.

4. Score Breakdown - Shows how your Third-Party Libraries Readiness Score was calculated using this formula: (Number of library calls supported in Snowpark) ÷ (Total number of identified library calls)

   Where:

   • “Library calls supported in Snowpark” means libraries that Snowpark can use

   • “Identified library calls” means all third-party library calls found in your code, including both Spark and non-Spark libraries, whether supported or not

SQL Readiness Score¶

The SQL Readiness Score will be displayed in the following format:

• Readiness Score - Displays your readiness score and its category (green, yellow, or red). This score indicates how many SQL elements in your code can be successfully converted to Snowflake SQL. For more details, see the SQL Readiness Score section.

• Next Steps - Based on your readiness score, SMA provides recommendations for actions to take before proceeding.

• Score Explanation - Provides a clear explanation of the SQL Readiness score and how to interpret your results.

• Score Breakdown - Shows a detailed calculation of your SQL Readiness Score, calculated as: (number of supported elements) ÷ (total number of elements).

Spark API Usages¶

The report contains three main sections displayed as tabs:

1. Overall Usage Classification

2. Spark API Usage Categorization

3. Spark API Usages By Status

We will examine each section in detail below.

Import Calls¶

The “Import Calls” section displays frequently used external library imports found in your codebase. Note that Spark API imports are excluded from this section, as they are covered separately in the “Spark API” section.

This table contains the following information:

The report displays the following information:

1. A table with 5 rows showing:

   • The 3 most frequently imported Python libraries

   • An “Other” row summarizing all remaining packages

   • A “Total” row showing the sum of all imports

2. A “Supported in Snowpark” column indicating whether each library is included in Snowflake’s list of supported packages in Snowpark.

3. An “Import Count” column showing how many times each library was imported across all files.

4. A “File Coverage” column showing the percentage of files that contain at least one import of each library. For example:

   • If ‘sys’ appears 29 times in the import statements but is only used in 28.16% of files, this suggests it’s typically imported once per file where it’s used.

   • The “Other” category might show 56 imports occurring across 100% of files.

For detailed import information per file, refer to the ImportUsagesInventory.csv file in the Output Reports.

File Summary¶

The summary report contains multiple tables displaying metrics organized by file type and size. These metrics provide insights into the codebase’s volume and help estimate the required effort for the migration project.

The Snowpark Migration Accelerator analyzes all files in your source codebase, including both code and non-code files. You can find detailed information about the scanned files in the files.csv report.

The File Summary contains multiple sections. Let’s examine each section in detail.

Issues Summary¶

The Issues Summary provides critical information about potential problems found during code scanning. When transitioning from assessment to conversion, you’ll see a list of EWIs (Errors, Warnings, and Issues) detected in your codebase. For a detailed explanation of these issues, please refer to the Issue Analysis section in the documentation.

At the top of the issue summary, you will find a table that provides an overview of all identified issues.

The table contains two rows.

• The “Number of issues” represents the total count of all issue codes found in each category.

• The “Number of unique issues” represents the count of distinct error codes found in each category.

The problems are divided into three main categories:

• Warnings indicate potential differences between source and target platforms that may not require immediate action but should be considered during testing. These could include slight variations in behavior for edge cases or notifications about changes in appearance compared to the source platform.

• Conversion issues highlight elements that either failed to convert or need additional configuration to work properly in the target platform.

• Parsing issues occur when the tool cannot interpret specific code elements. These are critical issues requiring immediate attention, typically caused by non-compiling source code or incorrect code extraction. If you believe your source code is correct but still receive parsing errors, it may be due to an unrecognized pattern in SMA. In such cases, please report an issue and include the problematic source code section.

The table summarizes the total count for each item.

Below this table, you will find a list of unique issue codes and their descriptions.

Each issue code entry provides:

• The unique issue identifier

• A description of the issue

• The number of occurrences

• The severity level (Warning, Conversion Error, or Parsing Error)

You can click any issue code to view detailed documentation that includes:

• A full description of the issue

• Example code

• Recommended solutions

For instance, clicking the first issue code shown above (SPRKPY1002) will take you to its dedicated documentation page.

By default, the table displays only the top 5 issues. To view all issues, click the SHOW ALL ISSUES button located below the table. You can also use the search bar above the table to find specific issues.

Understanding the remaining conversion work is crucial during assessment mode. You can find detailed information about each issue and its location in the issue inventory within the Reports folder.

Execution Summary¶

The execution summary provides a comprehensive overview of the tool’s recent analysis. It includes:

• The code analysis score

• User details

• The unique execution ID

• Version information for both SMA and Snowpark API

• Project folder locations that were specified during Project Creation

Appendixes¶

The appendixes contain additional reference information that can help you better understand the output generated by the SMA tool.

This guide contains general reference information about using the Snowpark Migration Accelerator (SMA). While the content may be updated periodically, it focuses on universal SMA usage rather than details about specific codebases.

This is what most users will see when they run the Snowpark Migration Accelerator (SMA). If you are using an older version, you might see the Abbreviated Assessment Summary instead, which is shown below.