We simplify and expedite your cloud data migration from on premises to the Snowflake Data Cloud. Our experts will successfully move your database resources with minimal disruptions regardless of the cloud provider you choose.
Every migration is different, but some of the most successful migration projects begin with a thorough plan and the process of documenting the project scope into smaller and more managable chunks. We have been able to successfully complete some migrations in less than 13 weeks.
Native Technologies
We tend to utilize native technologies whenever possible to limit support and licensing fees for our customers. Because of this, we prefer to utilize SnowConvert for our chosen technologies for handling migrations from Oracle, Teradata, or SQL Server.
Code Assessments
Dive into the details of code assessments, understanding the intricacies of legacy code preparation, and maximizing the benefits of SnowConvert’s assessment reports.
- Extracting and preparing legacy code
- Understanding the assessment mode and accessing the conversion of tables
- Navigating post-assessment with Snowflake Professional Services
Code Conversion
Achieve proficiency in code conversion by addressing error resolutions, fine-tuning configurations, and ensuring a seamless deployment on the Snowflake platform.
- Navigating post-migration procedures in Snowflake
- Preparing legacy code
- Extracting data definition language (DDL) using SnowConvert
- Resolving errors in legacy and output code
We take an iterative approach
Using SnowConvert it accellerates your migration through an iterative process.
SnowConvert receives automatic updates for translations and other functionality typically on a two-week basis. As such, rather than running all code through the tool at once initially, it is best to use SnowConvert against portions of the code iteratively throughout the migration.
This may help improve your project’s overall conversion rate over time, by reporting code scenarios that may not yet be automated but are essential to your migration. It also allows you to test converted code incrementally to identify early on if the code performs to expectation in Snowflake or if refactoring of the code may become necessary.
Let’s take a look at the necessary steps to achieve a successful migration using SnowConvert.
- Conversion Plan
Review and prepare input code
First, build your conversion plan, dividing up code into portions that make sense based on your overall migration plan. Then extract, review, and prepare the input code. Be sure to identify and remove code that you do not want to convert, such as back-ups, system-specific code like statistics gathering, or DBA task-based code that will not be relevant in Snowflake.
- Assessment
Evaluate reports, clean up code and address dependencies
Second, run the assessment using the tool. SnowConvert will provide you with reports to help you understand the quality of the input code and what changes you should make to accelerate the conversion. It will also let you know if you have missing dependencies in the code submitted. This is critical, as the best conversion rates depend on understanding all dependencies.
For example, executing a procedure by itself will be less effective than executing a procedure and all its dependent tables, views, and functions simultaneously. SnowConvert will guide you in determining the effort necessary to complete the code conversion once the automated portion of the work is complete.
- Conversion
Analyze output code
Now you should loop through this and the following steps.
First, you evaluate the reports and output code, and then you modify your input code to execute conversions.
- Refactoring
Adjust the code and run the tool again
You can run as many conversions as you find it necesary.
- Beyond Automation
Manual Refactoring
Once the automated portion of the process is over, the most critical step is what you do next to complete your migration project.
Make additional manual code adjustments based on your output results and merge those changes with the converted code to be implemented, tested, and deployed.
There are many migration activities outside of what you do with SnowConvert that are critical to the overall success of your migration. These steps will be discussed further later on in the course.
Migration Process
Migration ≠ Conversion
A migration typically involves moving a business or IT application from one environment or platform to another. It typically requires adapting the application code to work in the new environment, ensuring compatibility and functionality, and modifying all integrated systems interacting with the application.
On the other hand, code conversion refers explicitly to the migration portion that deals with translating code written in one programming language or system to another language or system. Code conversion is only part of the overall migration. It encompasses a broader scope, including tasks like adapting configurations, updating system dependencies, and ensuring overall system compatibility, not just converting the code itself.
Building a Migration Plan
Before starting with SnowConvert, it’s essential to understand the full scope of activities involved in migrating your organization’s legacy system to Snowflake. In this section, we will describe what a successful migration looks like and share some tips for creating a solid migration plan. Then, we will look at where SnowConvert fits (and does not fit) into these migration activities.
Building a Migration Plan is a crucial first step when migrating from your legacy system to Snowflake.
Doing so allows your organization to identify the full scope of the project, the activities that will take place during the migration, and the roles and people required to complete these activities. A thorough plan sets your organization up for success and understanding the full scope of the migration – and where SnowConvert fits and does not fit into the migration project – is essential.
Migration Planning
Migration planning should have three goals:
| Why? | Roles | Time & Effort |
| Why migrate? Set goals – What is essential to migrate? – Project scope – How many phases? | Who is involved? What are their responsibilities? What activities will they perform? | Estimate per Migration Component Include All Activities: – Setup – Design – Code Modification – All Forms of Testing – Asset Managementç – Status Reporting |
| First, to answer the question, “Why migrate?” You must understand the rationale behind the migration to get buy-in from all involved parties and define what success looks like. This includes naming the goals and business outcomes for the migration, identifying what is essential to migrate, and indicating what is in scope and what is out of scope. Some migrations may be executed in multiple phases – what assets need to be migrated first, and what dependencies must come with these assets? What assets can be migrated in a follow-up phase? | Second, during migration planning, roles should be identified. Who must be involved in the migration, and what are their responsibilities? What activities will each role perform? | Third, the migration plan should include a detailed outline of all activities, the estimated resource effort for each activity, and the timing of each activity relative to others. An effort estimate should be completed for each migration component, and the plan should account for all activities, including setup, design, code modification, all forms of testing, asset management, and status reporting. The level of detail for this plan will vary depending on the size and complexity of your particular migration. The details should be sufficient to plan resources properly and identify all dependency risks throughout the migration timeline. |
Migration Components Relevant to SnowConvert
Primarily, SnowConvert will accelerate the conversion of the core database code, including objects and any scripts for the legacy system, such as Oracle PL/SQL and Teradata BTEQ. In most cases, this category is where you will see SnowConvert provide the highest level of acceleration.
Additionally, depending on your legacy data integration and data consumption systems, SnowConvert may also provide some acceleration for these areas. While SnowConvert cannot directly take input from code files exported from systems like Informatica, DataStage, or Tableau, these systems often contain a substantial amount of database-specific SQL code for the legacy system being migrated to Snowflake. In these cases, you can extract these SQL statements via scripting into standalone SQL files, convert them with SnowConvert, and finally put them back into the original code files via scripting.
You can apply similar processes to files, including operating system scripts like shell and bash files. For more information or assistance on these scenarios, please reach out to Snowflake Professional Services.
Valid File Formats
SnowConvert accepts .SQL files for SQL Server, Teradata, and Oracle. Additionally, for Teradata access codes, SnowConvert also accepts BTEQ, FLOAD, and MLOAD files.
Your data integration and data consumption legacy code may contain code that cannot be exported in a valid file format for SnowConvert to ingest. For instance, you may have Informatica XML files, IBM DataStage files, Talend job scripts, Tableau workbook files, Power BI report files, or OS shell or kshell files, to name just a few, which may contain SQL that must be modified to work with Snowflake.
While SnowConvert does not directly support these file formats, you can still use the SnowConvert tool on any SQL statements within these files with additional effort. Just copy the SQL statements within these files and paste them into a new file with the .SQL extension. After successfully converting these SQL statements using SnowConvert, copy the converted code back into the source files.
In many cases where the SQL statements can be easily identified in the source code by tags or keywords, this process can be scripted instead of manually removing and replacing the code to be converted.
Object Inventory
Creating an object inventory for each phase of the migration and each migration category is vital. Object inventories should include a list and count of all object types per environment, such as production, UAT, development, etc.
Identify and document the activities needed to complete the migration for each type of object and provide an effort estimate for all activities identified. Example activities may include setup, design, code modification, all testing, asset management, and status reporting.
For Database Conversion, catalog all tables, views, functions, procedures, and other objects unique to your organization’s legacy system, such as linked systems or external files written in the legacy system’s language.
For Data Integration, include embedded SQL from any externally run processes such as ETL tools, BI tools, shell scripts, python scripts, notebooks, etc…”
For Data Consumption, include any embedded SQL from the Reporting and Analytics Tools or SQL found in your data applications and data science workloads
Example Object Inventory – Database Conversion
Environment: Production
| Object Type | Objects | Hours | Total Hours |
| Tables | 1200 | 0.25 | 300 |
| Views | 26 | 1.5 | 39 |
| Functions | 8 | 4 | 32 |
| Procedures | 34 | 8 | 272 |
| Other (Server Links, BTEQ files, etc.) | 0 | 0 | 0 |
Subtotal: 643
Environment: Non Production
| Object Type | Objects | Hours | Total Hours |
| Tables | 0 | 0.25 | 0 |
| … | … | ….. | … |
Example Object Inventory: Data Integration & Data Consumption
Environment: Production
| Object Type | Objects | Hours | Total Hours |
| SQL Scripts | 60 | 2 | 120 |
| Shell Scripts | 22 | 2 | 44 |
| Python Scripts | 50 | 2 | 100 |
| ETL Jobs | 12 | 3 | 36 |
Subtotal: 300
Environment: Non Production
| Object Type | Objects | Hours | Total Hours |
| SQL Scripts | 0 | 2 | 0 |
| … | … | ….. | … |
Effort Estimation
Example Effort Estimation with SnowConvert
With SnowConvert to accelerate your migration, you can expect to see a reduction in the effort required to complete some migration tasks. Depending on your legacy system, SnowConvert may be able to automate some code modification activity for your database conversion, data integration, and data consumption migration steps.
Remember that the code modification step is just one of many activities involved in the migration. Setup, design, some code adjustments, all testing activities, and deployment, to name a few, are other necessary activities that cannot be automated. However, SnowConvert’s assessment reports and output will provide visibility into potential obstacles to migrating your legacy system, thus accelerating your migration a bit further.
Evaluate these useful reports thoroughly to leverage SnowConvert’s migration acceleration capabilities fully.
Here is a sample report from SnowConvert for migrating SQL Server sample database ContosoRetailDW
