MICROSOFT SQL SERVER TO SNOWFLAKE

MIGRATION REFERENCE MANUAL

2 Introduction
3 Preparing for the migration
8 Executing the migration
13 Migration success factors
14 Need help migrating?
15 Appendix A—Microsoft SQL Server to Snowflake Feature Mapping
21 Appendix B—Other Known Migration Issues
22 Appendix C—Comparing Data from Microsoft SQL Server to Snowflake
22 Appendix D—References
23 About Snowflake
 CHAMPION GUIDES
INTRODUCTION
This document provides the high-
level methodology needed to prepare
for and execute the migration of
an existing Microsoft SQL Server
deployment to Snowflake. The
appendices at the end of this
document list differences between
Microsoft SQL Server and Snowflake
that you should consider as part of
the migration.
The intended audience of this
document includes the solution
architects, program managers, and
Snowflake solution partners that
need a clearly defined approach for
migrating an existing Microsoft SQL
Server to Snowflake.

2
 CHAMPION GUIDES
PREPARING FOR
THE MIGRATION
Successful data migration projects start with a platform with enhanced capabilities for high databases within the Microsoft SQL Server need to
well-designed plan. An effective plan accounts concurrency, low latency workloads and point read be migrated and which ones don’t. Then determine
searches through its search optimization service. which schemas to migrate.
for the many components that need to be
However, for optimal success and to ensure you
considered, paying particular attention to Identify and document the objects within the
realize the value that Snowflake enables, be sure to
architecture and data preparation. This section identify the appropriate workload to migrate. Contact Microsoft SQL Server databases to migrate. Include
gives you a checklist of information to gather your local Snowflake representative to discuss the size of the data to establish the scope of the
and decisions to make before you start the migration project. Plan not to migrate Microsoft SQL
appropriate workloads.
Server catalog tables and views such as sys.tables
actual migration.
(tables that have sys as a prefix) since they are
DOCUMENT THE EXISTING SOLUTION catalog (metadata or directory) objects and aren’t
IDENTIFYING APPROPRIATE USE needed in Snowflake.
Key outcomes:
Snowflake, at the core of the platform, is an ANSI
SQL relational database built for analytical queries. • List of Microsoft SQL Server databases to migrate If you aren’t sure which databases and database
Therefore, OLAP workloads are ideal for migrating to objects to migrate, reference the Microsoft
• List of Microsoft SQL Server database objects
Snowflake. As an example, Snowflake works best as documentation, here. Avoid moving unused objects,
to migrate
an operational data store (ODS) and data warehouse. unless you need them for audit or historical purposes.
Its unique architecture enables processing of huge • List of Microsoft SQL Server schemas to migrate
After you’ve identified the Microsoft SQL Server
quantities of data, but it creates challenges when
• List of processes and tools that populate and databases and database objects to migrate, evaluate
organizations migrate highly transactional, high
pull data from Microsoft SQL Server each data source to determine whether the data
capacity workloads. Snowflake is an ever-evolving
comes from on-premises or a cloud-based source.
• List of security roles, users, and permissions
This will help determine the methods available for
• List of Snowflake accounts that exist or need loading the data into Snowflake. Specifically, will you
to be created need to load terabytes or even petabytes of on-
premises data into Snowflake? If so, you may require
• Frequency of security provisioning processes capabilities such as AWS Snowball, Azure Data Box,
or Google Transfer Appliance to move the data as
• Documentation of the existing Microsoft SQL
efficiently as possible.
Server solution into an as-is architecture diagram
In addition to evaluating the data sources that
Begin preparing for your migration from Microsoft populate Microsoft SQL Server, identify and
SQL Server to Snowflake by determining which document the processes and tools that move data in
and out of Microsoft SQL Server.

3
 CHAMPION GUIDES
Here are some examples: ESTABLISH A MIGRATION APPROACH Snowflake recommends minimal reengineering for
the first iteration unless your current system is
• ETL/ELT tools Key outcomes:
broken. When you decide what you will reengineer,
• List of processes to migrate as-is remember that changes to the existing data
• Scripting languages
structures will impact downstream reporting and
• List of processes that need reengineering
• Reporting/visualization tools visualization tools. Also, more reengineering requires
• List of processes that need fixing more development and testing, which extends the
• Data science processes
length of a migration project.
• Draft of migration deliverables
• Machine learning processes
• To-be architecture diagram
Use this list to evaluate the level of Snowflake
support for the tools you currently use, and to help After you’ve documented your existing Microsoft
determine the migration approach that would best SQL Server solution into an as-is architecture
fit your needs. diagram, focus on your migration approach.
Document the roles, users, and granted permissions Carefully consider how much reengineering
that currently exist within Microsoft SQL Server you want to undertake as part of the migration.
to prepare for the security implementation in Organizations usually fall somewhere between
Snowflake. Pay special attention to sensitive data wanting to migrate the existing solution as is and
sets and how they’re secured within Microsoft SQL completely reworking the existing solution.
Server. Also, determine how frequently security
provisioning processes run so you can create similar
security within Snowflake. In addition, capture
the Snowflake accounts already set up and any
Snowflake accounts needed for the migration,
since they will have an impact on the security
implementation.

If you do not have this information readily available,

Snowflake Professional Services and/or a Snowflake
solution partner can help capture this information.

4
 CHAMPION GUIDES
If you want to resolve issues with your existing CAPTURE THE DEVELOPMENT AND used for the migration (such as the source control
implementation as part of the migration, include that DEPLOYMENT PROCESSES repository and the method for deploying changes
information in your migration plan. from one environment to another). This information
Key outcomes: is critical to how you will implement development
Break the migration into incremental deliverables and deployment.
• List of tools introduced with the migration
that enable your organization to start making the
transition to Snowflake faster. This will also provide • List of tools deprecated after the migration
value to your organization sooner. PRIORITIZE DATA SETS FOR MIGRATION
• List of development environments needed
Use the as-is architecture diagram to create a to- for the migration Key outcomes:
be architecture diagram for communicating the • List of data sets to migrate first
• List of deployment processes used for
migration approach and ensuring the approach
the migration Method for identifying process dependencies
meets the requirements of the organization. •
for data sets
Depending on your migration approach, you may
introduce new tools and deprecate old tools as • Documentation of process dependencies
part of the migration. Since you documented your for data sets
existing tools and processes in an earlier step, this is
when you should document plans to introduce new To deliver value as soon as possible, identify
tools and deprecate old tools. which data sets you should migrate first. The ideal
candidates for starting the migration provide value
Your organization may want to change your to the organization with minimal migration effort.
development or deployment processes as part of Rather than starting with the most complex data sets,
the migration. Whether these processes change or begin with a simpler data set that provides a quick
not, capture the development environments used win and establishes a foundation of development and
for the migration (for example, Pre-Prod/Prod or deployment processes from which to build the rest of
Dev/QA/Prod), and the deployment processes the migration.

To prioritize data sets for migration, pay careful

attention to understanding the process dependencies
of the data sets. Document those dependencies. By
identifying dependencies through a solid process
before beginning the migration work, you will
experience fewer challenges during the migration.
If needed, you can engage Snowflake Professional
Services and/or a Snowflake solution partner to help
capture these dependencies.

5
5
 CHAMPION GUIDES
Ideally, you can create this dependency IDENTIFY THE MIGRATION TEAM DEFINE THE MIGRATION
documentation using an automated process that DEADLINES AND BUDGET
iterates through the existing job schedules and Key outcomes:
Key outcomes:
captures the data within Snowflake. This eliminates • List of migration team members and roles
having to depend on manual investigation. Using • List of business expectations for the
an automated process pays dividends throughout • Contact information for all team members migration deadline
the migration project by updating dependency Documented migration plan and budget
Document the people involved in the migration •
documentation as changes take place. This is required for the migration project
and the roles they will play. The documentation
important since the underlying systems will likely
should include each team member’s name, contact
change during the migration. • Template of estimated costs to run Snowflake
information, and role. Team members may come
from your team, Snowflake staff, or a Snowflake Organizational expectations for migration deadlines
solution partner. are important planning inputs. In addition, consider
other information such as the budget, resource
Some of the obvious roles required for a migration
availability, and amount of reengineering required.
are developer, quality assurance engineer, business
By gathering all of this information, you can establish
owner, project manager, program manager, scrum
and communicate achievable deadlines, even if the
master, and communication specialist.
deadlines differ from what was originally expected.
Snowflake Professional Services and/or a
It’s critical to create a migration plan to understand
Snowflake solution partner can fill multiple
the budget required to complete the migration.
needs for a migration, including solution design,
Snowflake Professional Services and/or a Snowflake
requirements gathering, documentation,
solution partner can help create an end-to-end plan
development, testing, delivery, and training.
that includes an estimate of the migration costs
The entire team works together to successfully
and timeline. In addition, they can provide code
complete the migration and communicate the
conversion services to help accelerate the migration
progress of the migration to stakeholders.
and reduce the overall costs. Compare the scope
and costs of the migration to the available budget to
ensure you have sufficient resources to complete the
migration work.

A key input into the budget is the number of

Snowflake compute clusters (also called virtual
warehouses) required to support the migration and
the number of compute clusters needed after the
migration is completed. A Snowflake representative
can provide a template and work with you to

6
 CHAMPION GUIDES
determine how many compute clusters are needed.
The template calculates the number of minutes a
warehouse is expected to run each day and the
number of days a warehouse is expected to run each
week. Once you complete the template, you will get
an estimated annual cost.

DETERMINE THE MIGRATION OUTCOMES

Key outcomes:
• List of high-level outcomes once the migration is
completed

• Documented plan for communicating the migration

project wins to stakeholders

As the final step of preparing for the migration,

capture the assumptions that will determine whether
the migration is successful, the high-level outcomes
that should be achieved by the migration, and the
benefits those outcomes provide for stakeholders.
(For example, turning off a Microsoft SQL Server
could be one of your desired outcomes.) Use this
documentation to validate that the migration project
provides the overall benefits stakeholders expect to
achieve from the migration.

You can express this information as success or failure

criteria for the migration project. The documentation
can also include benchmarks that compare process
execution on Microsoft SQL Server and Snowflake.
After you compile this information, use it to
communicate the success of the migration project to
stakeholders.

7
 CHAMPION GUIDES
EXECUTING
THE MIGRATION
After you gather the information and decisions ESTABLISH SECURITY You can establish common roles for developer access,
needed to prepare for the migration, you can including read-only access, read and write access, and
When first setting up a Snowflake account, you can administrative access, for nonproduction databases.
execute the migration. This section guides you
manually create users and roles to get started. From You may require additional roles for restricting access
through the steps required. there, make it a priority to move to an automated to sensitive data.
If you need assistance with any part of executing process that creates users and assigns them to
the migration from Microsoft SQL Server to roles, and removes users when they are no longer
Snowflake, check with your Snowflake representative applicable. Depending on your security auditing DEVELOP A TEST PLAN
for Snowflake Professional Services and/or requirements, create processes to capture role and Determine and execute the appropriate level and
recommended Snowflake solution partners. user creation and deletion, as well as the granting and scope of testing for each environment. (For example,
revoking of roles. you might set it up so schedules are executed in
QA and Prod but not in Dev, or data comparisons
Your existing Microsoft SQL Server security can be
between Microsoft SQL Server and Snowflake occur
a good starting point for setting up security within
only for Prod.) Automate testing as much as possible,
Snowflake. However, determine if there are Microsoft
so it’s repeatable and enables you to identify any
SQL Server roles and users that are no longer needed
issues. Define, document, and get agreement on
or should be implemented differently as part of your
acceptance criteria for the tests.
migration to Snowflake.

Start by creating roles for at least the first data sets

you will migrate. Then create users and assign them
to the appropriate roles.

8
 CHAMPION GUIDES
PREPARE SNOWFLAKE FOR LOADING
There are a couple of options for setting up your
Snowflake implementation, depending on the number
of Snowflake accounts you have.

• When you have one Snowflake account, “follow

these steps:

1. Create a Snowflake database for the MS SQL SERVER SNOWFLAKE ACCOUNT

combination of the Microsoft SQL Server (DEV/QA/PROD) (DEV/QA/PROD)
environment and database that you need to
migrate (for example, Dev_Sales/QA_Sales/
Prod_Sales).
Sales
2. Create schemas in Snowflake that match the Sales database
database
schemas from Microsoft SQL Server for each
schema you intend to migrate.

3. Create a Snowflake database for each Product

Microsoft SQL Server environment (such as Product database
database
Dev/QA/Prod) that you need to migrate.

4. Create a Snowflake database for each

Microsoft SQL Server database.
HR
HR database
5. Create schemas for each of the Microsoft database
SQL Server databases you intend to migrate
to Snowflake.

This approach clearly identifies the environment

and database in the database name and uses
schemas to contain the tables and views, so it’s
easier to point tools from Microsoft SQL Server
to Snowflake. Be aware that since the Snowflake Figure 1: Migrating a Microsoft SQL Server environment and database to Snowflake

9
 CHAMPION GUIDES
database name contains the environment in its
name, you will need to update any views that NO ETL
reference a database as the view is deployed ETL
ELT
from one environment to another (for example, DATA FLOW
deploying from QA to Prod).
E NVIRON MEN T
• When you have multiple Snowflake accounts,
S3/Azure
you can create the Snowflake databases and Staging Native
schemas to match the Microsoft SQL Server DATA BASES connector/
ODBC/
databases and schemas for a single environment. JDBC
Figure 1 provides examples of migrating
a Microsoft SQL Server environment to a Compute Analytics &
Snowflake account database and Microsoft SQL clusters for
Data
data science
user tools
Server databases to Snowflake databases. Scientists
Replication
After you create the databases and schemas in & streaming
tools
Snowflake, you can execute the DDL for creating Compute Staging
clusters for
the database objects in Snowflake. loading
tables

Web UI
Create the compute clusters (virtual warehouses)
based on the information captured during the
Ad-hoc
migration preparation. There should be separate Compute
clusters for SQL queries
Source systems
compute clusters for each environment (such as (cloud or
Ad-hoc Users
Dev/QA/Prod) and for each function that the on-prem)
compute clusters will support (such as ETL/ELT
or reporting and visualization). Figure 2 contains a Compute clusters
Reporting Native
reference architecture for using compute clusters for transformations
connector/
database(s)
for different workloads. (schemas, tables,
ODBC/
JDBC
views, etc.)
Data
Base the initial sizing of the compute clusters transformation Compute Business
(virtual warehouses) on the estimates you made tools clusters for intelligence
BI tools tools
while preparing for the migration. Then adjust the
size as needed throughout the migration. Also,
set up resource monitors to track usage and take
appropriate action when limits are reached.

As you create the databases, database objects,

and compute clusters, assign the appropriate
Figure 2: Using compute clusters for different workloads
security roles.

10
 CHAMPION GUIDES
LOAD INITIAL DATA SETS KEEP DATA CURRENT IMPLEMENT THE TEST PLAN
You may require AWS Snowball, Azure Data Box, Implement processes to keep the data current after Begin the Snowflake implementation with the initial
or Google Transfer Appliance if your Microsoft you load the historical data sets from Microsoft SQL data sets loaded and processes running to keep
SQL Server is on-premises and you need to move Server into Snowflake. the data current. Then you can start testing your
terabytes or petabytes of data. Add an appropriate Snowflake implementation. Be sure to engage the
You can set up data loading schedules that parallel
amount of time to the migration schedule to team members you identified when you prepared
the existing Microsoft SQL Server loading processes,
provision these boxes, load them with data, transport for the migration. After you complete initial testing
or you can create new processes for loading data into
them to the cloud data center, and offload the data and validate the data is ready for further scrutiny,
Snowflake. This is another opportunity to evaluate
into the cloud servers. engage additional groups to test their data sets and
whether changes to the schedule would be beneficial
applications against Snowflake.
and should be part of the migration.
You can load data into Snowflake after you’ve
extracted the data from Microsoft SQL Server and To ensure you populate data in the correct order, Compare data between the Microsoft SQL Server
moved the data to the cloud. Use this data loading to create the appropriate schedules based on a clear and Snowflake environments throughout the
test the configuration of the databases and database understanding of the process dependencies you migration. If there are data differences, investigate to
objects, compute clusters, and the security you have captured when you prepared for the migration. determine the cause and resolution.
implemented. See the Snowflake documentation for
Along with scheduling the processes to run, monitor
more information.
those processes so you can clearly understand and
Depending on which Microsoft SQL Server communicate the state of the data (for example,
environment the data came from and which loading is in progress, loading completed successfully,
Snowflake database you populate, you could use or loading failures occurred). You can verify whether
cloning to move data within Snowflake from one SLAs are being met within Snowflake, or identify and
database to another. Cloning in Snowflake doesn’t resolve process issues.
require additional storage. Therefore, you avoid
the challenges and costs of loading the same data
multiple times into different Snowflake databases.

Plan to extract data from Microsoft SQL Server and

load it into Snowflake more than once. Also, begin
with a subset of the data rather than trying to load
the entire contents of the Microsoft SQL Server at
the beginning of the migration.

11
 CHAMPION GUIDES
Part of your migration may include fixing processes REDIRECT TOOLS TO SNOWFLAKE successfully migrated the data, and redirected the
known to be incorrect in Microsoft SQL Server. tools from Microsoft SQL Server to Snowflake.
After you’ve migrated a sufficient amount of
Therefore, the test results may not match Snowflake,
data for each tool you identified while preparing Make sure you’ve planned and communicated the
so use other methods to validate that the data is
for the migration, redirect the tool connections cutover date in advance to your Microsoft SQL
correct in Snowflake. Document why data won’t
to Snowflake. Server users. In addition, make sure they can log
match and share the information with the groups
performing the testing so that they don’t spend time into Snowflake and run the redirected tools they
This usually involves copying and updating the
researching previously identified issues. depend on.
existing solution to connect to Snowflake instead of
Microsoft SQL Server. Compare the tools’ output to To complete the cutover, turn off data processes
Also, compare the performance of the processes
ensure the results are the same between the two that populate Microsoft SQL Server. In addition,
that load and consume data to ensure Snowflake is
systems. In addition, evaluate the performance of revoke access to Microsoft SQL Server so users and
performing as expected. Share these comparisons
the tools to verify they are performing as expected tools no longer have access.
with stakeholders to highlight the benefits of
in Snowflake.
migrating from Microsoft SQL Server to Snowflake.

Also, compare the performance of the processes

CUT OVER TO SNOWFLAKE
that load and consume data to ensure Snowflake is
performing as expected. Share these comparisons The cutover from Microsoft SQL Server to
with stakeholders to highlight the benefits of Snowflake can occur only after you’ve migrated
migrating from Teradata to Snowflake. the initial data, enabled processes to keep the data
current, completed testing that verifies you’ve

RUN MICROSOFT SQL SERVER AND

SNOWFLAKE IN PARALLEL
During the migration, run the Microsoft SQL Server
and Snowflake systems in parallel. Minimize the
time you have both systems running, but make
sure it’s long enough to validate you’ve completed
the migration successfully before shutting down
Microsoft SQL Server.

Consider how to best run Microsoft SQL Server

and Snowflake in parallel to compare data and
performance. For example, you may need to create
hashes as you extract data from Microsoft SQL
Server in order to compare data at the row level
between Microsoft SQL Server and Snowflake
(See Appendix C). Perform these comparisons in
Snowflake to keep from negatively impacting your
Microsoft SQL Server.

12
 CHAMPION GUIDES
MIGRATION
SUCCESS FACTORS
IDENTIFY AND MITIGATE DIFFERENCES from Snowflake, and from any other parties
Paying attention to certain success factors BETWEEN MICROSOFT SQL SERVER involved). Be sure everyone involved can log a
will reduce risk and enable you to successfully AND SNOWFLAKE support ticket in the Snowflake Community portal.
complete the migration. This section Likewise, they should know how to ask questions and
Use Appendix A early in the migration process to
find resources in the Snowflake Community forum
provides insight into how to increase the identify differences between Microsoft SQL Server
and on Stack Overflow.
speed of migration and ensure the migration and Snowflake. Present these differences to the
from Microsoft SQL Server to Snowflake organization along with strategies for handling Establish a regular cadence for reviewing
the differences. Then, confirm that your proposed
is successful. documented issues and getting an updated status
approach will meet their requirements. on resolving each issue.

You may also identify issues during the migration

RESOLVE MIGRATION ISSUES that can be resolved after the migration. Document
There will inevitably be issues that occur during and and prioritize them, so you can work on them
after the migration. Establish processes to document post-migration.
and escalate migration issues so you can resolve
them as quickly as possible.
COMMUNICATE MIGRATION BENEFITS
For each escalation, document the issue, who Use the high-level outcomes that you captured while
is responsible for working on the issue, who is preparing for the migration to document the actual,
responsible for communicating progress, and a list of corresponding benefits that occurred. Publish these
contacts (include contacts from your organization, results to stakeholders so they clearly understand the
benefits of the migration.

13
 CHAMPION GUIDES
NEED HELP
MIGRATING?
Snowflake is available to accelerate Snowflake’s global and regional solution partners
your migration, structure and also have extensive experience performing proofs
of concept and platform migrations. They offer
optimize your planning and services ranging from high-level architectural
implementation activities, and recommendations to manual code conversions. Many
apply customer best practices to Snowflake partners have also built tools to automate
and accelerate the migration process.
meet your technology and business
objectives. Snowflake’s Professional Whether your organization is fully staffed for a
platform migration or you need additional expertise,
Services Team deploys a powerful
Snowflake Professional Services and solution
combination of data architecture partners have the skills and tools to accelerate your
experience and advanced technical journey to cloud-built data analytics, so you can
knowledge of the platform to deliver quickly reap the full benefits of Snowflake.

high performing data strategies, To find out more, contact the Snowflake sales team
proofs of concept, and migration or visit the Snowflake Community.

project planning and implementation.

14
 CHAMPION GUIDES
APPENDIX A: MICROSOFT SQL SERVER
TO SNOWFLAKE FEATURE MAPPING
UTILITIES

SQL SERVER SNOWFLAKE COMMENTS

MSSQL-CLI SnowSQL SnowSQL is the next-generation command-line client for connecting to Snowflake to execute SQL queries and perform all DDL and DML
operations, including loading data into and unloading data out of database tables.

BCP (Bulk Copy COPY <INTO> COPY INTO is a command executed within SnowSQL or any other client connected to Snowflake and can ingest AVRO, Parquet, ORC,
Program) JSON, XML, and flat delimited text files.

MS INTERVAL MINUTE TO SECOND INTERVAL data types aren't supported in Snowflake but date calculations can be done with the date comparison functions (e.g. DATEDIFF
and DATEADD).

DATA TYPES
Snowflake supports most basic SQL data types (with some restrictions) for use in columns, local variables, expressions, parameters, and any other appropriate locations.
Data types are automatically coerced whenever necessary and possible.

SQL SERVER (TSQL) SNOWFLAKE COMMENTS

BIGINT NUMBER Precision and scale not to be specified when using Numeric.

BIT BOOLEAN Recommended: Use NUMBER if migrating value-to-value to capture the actual BIT value. Use Boolean in Snowflake if the desired outcome
is to restrict to Ternary Logic (three valued): TRUE, FALSE, or NULL (UNKNOWN).

DECIMAL NUMBER Default precision and scale are (38,0).

INT NUMBER Precision and scale not to be specified when using Numeric.

MONEY NUMBER Money has a range of 19 digits with a scale of 4 digits, so NUMBER(19,4) can be used.

NUMERIC NUMBER Default precision and scale are (38,0).

15
 CHAMPION GUIDES
APPENDIX A: MICROSOFT SQL SERVER
TO SNOWFLAKE FEATURE MAPPING
DATA TYPES (cont’d)

SQL SERVER (TSQL) SNOWFLAKE COMMENTS

SMALLINT NUMBER Default precision and scale are (38,0).

SMALLMONEY NUMBER NUMBER with precision of 10 digits, with a scale of 4, so NUMBER(10,4) can be used.

TINYINT NUMBER Default precision and scale are (38,0).

FLOAT FLOAT Snowflake uses double-precision (64-bit) IEEE 754 floating point numbers.

REAL FLOAT The ISO synonym for REAL is FLOAT(24).

DATE DATE Default in SQL Server is YYYY-MM-DD.

DATETIME2 TIMESTAMP_NTZ Snowflake: TIMESTAMP with no time zone, time zone is not stored. DATETIME2 has a default precision of up to 7 digits, Snowflake has
TIMESTAMP_NTZ with the precision of 9 digits.

DATETIME DATETIME SQL Server datetime is not ANSI or ISO 8501 compliant. Storage size is 8 bytes. Accuracy is rounded to increments of .000, .003, or .007
seconds.

DATETIMEOFFSET TIMESTAMP_LTZ Up to 34,7 in precision, scale.

SMALLDATETIME DATETIME SMALLDATETIME is not ANSI or ISO 8601 compliant. It has a fixed 4 bytes storage space.

TIMESTAMP TIMESTAMP_NTZ Use DATETIME2 or CURRENT_TIMESTAMP function.

(Unsupported)

TIME TIME SQL Server has a precision of 7 nanoseconds. Snowflake has precision of 9 nanoseconds.

16
 CHAMPION GUIDES
APPENDIX A: MICROSOFT SQL SERVER
TO SNOWFLAKE FEATURE MAPPING
DATA TYPES (cont’d)

SQL SERVER (TSQL) SNOWFLAKE COMMENTS

CHAR VARCHAR(1) Any set of strings that is shorter than the maximum length is not space-padded at the end.

TEXT VARCHAR This data type will be discontinued on SQL Server. Use NVARCHAR, VARCHAR, or VARBINARY instead.

VARCHAR VARCHAR Any set of strings that are shorter than the maximum length is not space-padded at the end.

NCHAR VARCHAR NCHAR is used on fixed-length-string data.

NTEXT VARCHAR This data type will be discontinued on SQL Server. Use NVARCHAR, VARCHAR, or VARBINARY instead.

NVARCHAR VARCHAR NVARCHAR’s string length can range from 1–4000.

BINARY BINARY Snowflake: maximum length is 8 MB.

IMAGE N/A This data type will be discontinued on SQL Server. Use NVARCHAR, VARCHAR, or VARBINARY instead.

VARBINARY BINARY Snowflake: maximum length is 8 MB.

UNIQUEIDENTIFIER N/A Not Supported.

17
 CHAMPION GUIDES
APPENDIX A: MICROSOFT SQL SERVER
TO SNOWFLAKE FEATURE MAPPING
SQL SERVER INSTANCE VERSUS SNOWFLAKE ACCOUNT
Similar to SQL Server instance, a Snowflake account encapsulates users, roles, and databases..

SQL SERVER SNOWFLAKE COMMENTS

Instance Account A Snowflake account is created within a single cloud provider region, and it defines the Snowflake edition, controls authenticating user
connections, and encapsulates all costs associated with the platform.

User User Snowflake users are created and managed at the account level and are independent of database schema objects. SQL Server offers a similar
model with a user setup and is assigned a login but the user may not be able to use or access the databases.

Role Role Object ownership and object access control are managed at the role level using a combination of discretionary access control (DAC) and
role-based access control (RBAC). Access privileges are not granted directly to a user. SQL Server has a similar model of having set role
permissions with the user being assigned to a role. Access privileges are not granted directly to a user, even for logging into SQL Server.

Databases Databases A single Snowflake account supports the creation of a soft limit of 10,000 logical databases.

DDL AND PROCEDURAL LANGUAGES

Snowflake SQL reserves all ANSI keywords (with the exception of type keywords such as CHAR, DATE, and DECIMAL), as well as some additional keywords that are reserved
by SQL Server and other popular databases. DDL operations such as CREATE, DROP, and ALTER within Snowflake will, in many cases, be the same or very similar to their ANSI
counterparts within SQL Server.

SQL SERVER SNOWFLAKE COMMENTS

Schemas Schemas Snowflake schema objects are created and managed independent of a user login.

Tables Tables Snowflake supports permanent, transient, temporary, and clustered tables. External tables are not currently supported within Snowflake.

Table Partitions n/a Snowflake’s unique architecture eliminates the need to manage physical table partitions.

Constraints Constraints Snowflake provides support for constraints as defined in the ANSI SQL standard. Snowflake enforces only the NOT NULL constraints. SQL
Server enforces NOT NULL constraints as well as referential integrity constraints.

Indexes/ n/a Snowflake’s unique architecture eliminates the need to manage indexes.
Partitioned Indexes

18
 CHAMPION GUIDES
APPENDIX A: MICROSOFT SQL SERVER
TO SNOWFLAKE FEATURE MAPPING
DDL AND PROCEDURAL LANGUAGES (cont’d)
SQL SERVER SNOWFLAKE COMMENTS

Views Views A Snowflake view can be created for any valid SELECT statement.

Transactions Transactions A Snowflake transaction is a set of SQL statements, both reads and writes, that are processed as a unit and guarantee ACID properties.

CLR/TSQL JavaScript Stored procedures and user defined functions (UDF) within Snowflake utilize JavaScript as their procedural language.

Stored Procedures Stored Procedures Snowflake stored procedures utilize JavaScript as the procedural language.

User-Defined User-Defined Functions A UDF can contain either a SQL expression or JavaScript code, and can return either scalar or tabular results (such as table functions).
Functions

Unsupported Sequences Sequences can be used for generating sequential, unique numbers.

Indexed Views Materialized Views A materialized view is a precomputed data set derived from a query specification (the SELECT list in the view definition) and stored for later
reuse. In SQL Server, Indexed Views uses the syntax SCHEMABINDING.

DML
Snowflake supports standard SQL, including a subset of ANSI SQL:1999 and the SQL:2003 analytic extensions. Snowflake also supports common variations for several
commands where those variations do not conflict with each other. Snowflake SQL reserves all ANSI keywords (with the exception of data type keywords such as CHAR, DATE,
and DECIMAL). Snowflake supports some additional keywords (such as ASC, DESC, or MINUS) that are reserved by SQL Server and other popular databases. Additionally,
Snowflake reserves keywords REGEXP and RLIKE (which function like the ANSI reserved keyword LIKE) and SOME (which is a synonym for the ANSI reserved keyword ANY).

SQL SERVER SNOWFLAKE COMMENTS

ANSI SQL ANSI SQL ANSI-compliant SQL will transfer to Snowflake with little to no modification if schema, table, and column names remain the same.

SQL Functions SQL Functions Snowflake supports a wide range of scalar, aggregate, and window functions (such as Lead/Lag).

SQL Format Models SQL Format Models Snowflake supports a wide range of standard SQL format models for converting numeric and date values to text and vice versa.

Hints n/a Snowflake’s unique architecture is optimized for data warehousing and eliminates the need for fine-grained query plan tuning via hints.

19
 CHAMPION GUIDES
APPENDIX A: MICROSOFT SQL SERVER
TO SNOWFLAKE FEATURE MAPPING
DATE CONSIDERATIONS
Unlike SQL Server, in Snowflake, there is no GETDATE() function, so you cannot insert the value of CURRENT_TIMESTAMP() into a column with DATETIME datatype. This is
because, in Snowflake, DATETIME is an alias for TIMESTAMP_NTZ but CURRENT_TIMESTAMP returns TIMESTAMP_LTZ, which is incompatible, as detailed below:

SQL SERVER SNOWFLAKE COMMENTS

GETDATE() TIMESTAMP_NTZ Snowflake’s TIMESTAMP_NTZ is similar to TSQL Datetime. Use ALTER SESSION SET TIMESTAMP_TYPE_MAPPING=TIMESTAMP_LTZ;

TO_DATE TO_DATE Behavior within Snowflake will be similar to SQL Server.

DATEDIFF DATEDIFF Behavior within Snowflake will be similar to SQL Server.

DATEADD DATEADD Behavior within Snowflake will be similar to SQL Server.

20
 CHAMPION GUIDES
APPENDIX B:
OTHER KNOWN MIGRATION ISSUES
CASE SENSITIVITY (for example, DATE ‘2018-12-31’). In Snowflake, the • COLLATE
syntax is TO_DATE(), for example, TO_DATE(‘2018- • UPDATE STATISTICS (not needed in Snowflake as
Since Snowflake is case sensitive (for example, Glass,
12-31’). It isn’t necessary to use DATE or TO_DATE() this is carried out as a service)
GLASS, and glass are three different values), during
in many situations, since both Microsoft SQL Server • ROLLBACK TRANSACTION (within Snowflake, it is
the migration, check for comparison issues in queries.
and Snowflake can interpret the date values stored ROLLBACK)
Microsoft SQL Server is case insensitive by default,
in a string. When migrating SQL from Microsoft SQL
however, it is possible to create a case-sensitive SQL
Server to Snowflake, it may be more desirable to
Server database and even to make specific table OTHER CONSIDERATIONS:
replace DATE with TO_DATE() rather than dropping
columns case sensitive. Determine if a database In Snowflake, variables can be initialized in SQL using
DATE altogether.
or database object is case sensitive by checking the SET command. The data type of the variable
its COLLATION property and look for CI or CS in is derived from the date type of the result of the
the result. Run SELECT name, description FROM UPDATING DATA THROUGH A VIEW evaluated expression. In Azure SQL Data Warehouse,
sys.fn_helpcollations(), to illustrate all collations Microsoft SQL Server allows inserts, updates, and DECLARE <variable> <date type> is used followed by
supported by the SQL Server installation. Another deletes to be executed against a view, which then setting the value to the variable.
simple solution to this issue is to use UPPER on updates the underlying table. In Snowflake, inserts, SQL Server was built primarily for OLTP. Snowflake
both sides of a comparison, for example, WHERE updates, and deletes must be executed against a was built for OLAP.
UPPER(COLUMNNAME)=UPPER(COLUMNNAME), table and can’t be executed against a view. Again,
if you want to ignore any differences in case. Note that you do not need to define a schema in
load processes may need to be reengineered to
advance when loading JSON data into Snowflake.
account for this.
CONSTRAINTS For SQL Server Stored Procedures, use table
functions if you are returning result sets from SQL
Microsoft SQL Server enforces Primary Key and SYNTAX SPECIFIC TO SQL SERVER stored procedures and Python if just executing
Foreign Key constraints. While Snowflake supports SQL Server has SQL syntax that is not used in business logic when using Snowflake.
the syntax to define Primary Keys and Foreign Keys, Snowflake:
they aren’t enforced within Snowflake. This means Integration tables are not required as Snowflake is an
• PARTITION BY
you’ll need to reengineer load processes that depend ELT platform. Staging tables are not required.
• COMPRESS/DECOMPRESS
on constraints to prevent duplicate entries and
• FORMAT
orphaned records from being entered into the data
• INDEXES
warehouse.
• CURSOR
• HINTS
DATE VERSUS TO_DATE()
• FREETEXT
Microsoft SQL Server has the capability to put DATE
• BULK INSERT
in front of a string in order to treat it as a date value
• DISABLE/ENABLE TRIGGER

21
 CHAMPION GUIDES
APPENDIX C: COMPARING DATA FROM
MICROSOFT SQL SERVER TO SNOWFLAKE
Use row counts and sums of numeric data to validate columns and attributes in the hash, but exclude insert
data matches between Microsoft SQL Server and update dates/timestamps that can change based
and Snowflake. Another way to confirm you’ve on when the data is loaded into Snowflake). As you
successfully loaded all data into Snowflake is to get load data into Snowflake, generate another MD5
unique values from columns in Microsoft SQL Server hash across the same set of columns, so you can
and compare those unique values with Snowflake. compare it with the MD5 hash from Microsoft SQL
Server. This allows you to compare the contents of
For use cases where you require more in-depth the row on the MD5 hash from Microsoft SQL Server
validation, add an MD5 hash to the data extracted with the MD5 hash from Snowflake, rather than
from Microsoft SQL Server. Construct this MD5 comparing each column individually.
hash using columns that won’t change when the data
is loaded into Snowflake (for example, include key

APPENDIX D: REFERENCES
SQL SERVER DOCUMENTATION
• Data types (Transact-SQL) - SQL Server

• Maximum capacity specifications for SQL

Server - SQL Server

SNOWFLAKE DOCUMENTATION
• General Reference

22
 ABOUT SNOWFLAKE
Snowflake’s cloud data platform shatters the barriers that have prevented organizations of all sizes from unleashing the
true value from their data. Thousands of customers deploy Snowflake to advance their organizations beyond what was
possible by deriving all the insights from all their data by all their business users. Snowflake equips organizations with a
single, integrated platform that offers the only data warehouse built for the cloud; instant, secure, and governed access
to their entire network of data; and a core architecture to enable many types of data workloads, including a single
platform for developing modern data applications. Snowflake: Data without limits. Find out more at snowflake.com.

© 2020 Snowflake, Inc. All rights reserved. snowflake.com #YourDataNoLimits

Snowflake is FedRAMP Authorized