ServiceNow to Snowflake: How to Move Your Data
Move ServiceNow into Snowflake with Airbyte. What the CMDB and SAM streams cover, why ITSM tickets are not included, and building an estate history.
Moving ServiceNow into Snowflake puts your IT estate where it can be counted, joined and tracked over time. ServiceNow holds the authoritative record of what hardware you run and what software you are licensed for, and neither question is answerable from a console built for operating that estate rather than analysing it.
One thing to establish immediately, because it decides whether this pipeline is what you want. The connector covers the Configuration Management Database and Software Asset Management applications. It does not carry incidents, changes, problems or requests, so if you came here for ticket analytics, the section below on scope will save you an afternoon.
ServiceNow to Snowflake at a glance:
Why move data from ServiceNow to Snowflake?
Two situations fit this connector well, and both are about assets rather than tickets.
The first is software licence compliance. Knowing what you are entitled to, what is actually installed and where the gap sits is a reconciliation across ServiceNow and your purchasing records, and it happens in a warehouse or it happens in a spreadsheet somebody maintains by hand.
The second is infrastructure history. The CMDB describes your estate as it is now, and a warehouse accumulating daily snapshots tells you how it changed, which servers appeared during a migration and what quietly persisted after a decommissioning project was declared finished.
What do you need before you start?
The first item involves a commercial conversation rather than a configuration screen:
An Airbyte enterprise agreement covering this connector. ServiceNow is a premium enterprise connector available at an additional cost, so it is not something you switch on from the catalogue. The ServiceNow source documentation sets out what it covers.
Your instance base URL and a service account. The connector authenticates with a username and password, and that account must have access to every table you want included. Its permissions define your dataset, so create one for the pipeline rather than borrowing an administrator's.
Confirmation that the streams answer your question. Check the published stream list against what you actually need before committing, because the coverage is narrower than the ServiceNow name suggests and the connector is still incubating at an early version.
Snowflake objects and a role. A warehouse, database, schema and a role able to create tables in that schema. Volume is modest here, since an estate inventory is thousands of rows rather than millions, so the smallest warehouse is ample.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the Snowflake side before you begin.
How do you build a ServiceNow to Snowflake pipeline in Airbyte?
Step 1: Match the streams to your question
Write down what somebody asked you for, then read the stream list. If the answer involves servers, network devices, printers or licence entitlements, this connector covers it. If it involves tickets, approvals or resolution times, it does not, and no configuration changes that.
Step 2: Configure the ServiceNow source
Click Sources in the left navigation, then New Source, and select ServiceNow, following adding a source. Enter your instance as the base URL, then the username and password of the service account. Run the connection test and review which streams appear.
Step 3: Configure the Snowflake destination
Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role. Airbyte creates one table per stream with its own metadata columns alongside your data.
Step 4: Choose append if you want history
Click Connections, then New connection, and choose a sync mode. Only full refresh is available, so the real decision is overwrite for a mirror of the current estate, or append to accumulate a snapshot per sync. Daily is generous for an inventory that changes when somebody provisions a server.
Derive a snapshot date from the extraction timestamp if you choose append, since that column is what every historical query will group by.
What is actually in these streams?
Two application areas. The Configuration Management Database streams describe infrastructure as configuration items: Linux, Windows, AIX and Solaris servers, ESX hosts, routers, switches, firewalls, load balancers, printers, scanners, storage switches and chassis hardware. The Software Asset Management streams cover licences, product lifecycle records and model categories.
What is absent is the half of ServiceNow most people picture. There are no incident records, no change requests, no problems and no service catalogue items, so questions about mean time to resolution, change failure rate or ticket volume by team cannot be answered from this dataset.
If those are your questions, Connector Builder against ServiceNow's Table API is the route, since the API exposes far more than this connector currently wraps. That is more work than selecting a connector and considerably less than discovering the gap after promising somebody a dashboard.
Why does full refresh only suit this data?
Because an asset inventory is a statement about the present rather than a log of events. Incremental sync answers what changed since last time, and a CMDB record has no natural cursor for that, so reading the whole set each time is the honest mechanism rather than a limitation to work around.
It also makes append mode more interesting than it usually is. Each sync writes the complete estate as it stood that day, so a year of daily snapshots tells you when a server first appeared, when it stopped being reported and how your footprint moved through a migration. ServiceNow itself keeps no queryable record of that.
The cost is storage multiplied by sync frequency, which at inventory volumes is negligible. Weekly snapshots of a few thousand configuration items will not trouble a warehouse, and the historical view they produce is the thing nobody can reconstruct later if you choose overwrite today.
Frequently asked questions
Can I sync incidents and change requests?
Not with this connector. It covers Configuration Management Database and Software Asset Management streams only. For ITSM records, build against ServiceNow's Table API in Connector Builder.
Is the ServiceNow connector included in my plan?
It is a premium enterprise connector available at an additional cost, so it needs a commercial conversation rather than a configuration change.
Can I sync incrementally?
No. Full refresh is the only supported mode, so each sync reads the whole set. Use append if you want to accumulate snapshots over time.
Why is a table I expected missing?
Either it is outside the CMDB and SAM scope, or the service account lacks access to it. Check the account's table permissions first, then the published stream list.
Can I do this without writing code?
Yes for this connector, which is entirely UI-driven. Connector Builder for the ITSM tables is also a user interface rather than code.
Get your ServiceNow data into Snowflake
Check the streams against your question before anything else, because the coverage is narrower than the name suggests. Then scope the service account deliberately, choose append so you accumulate an estate history ServiceNow does not keep, and use Connector Builder if ITSM records are what you actually need.
Airbyte's connector catalog includes 700+ pre-built connectors, so asset data can sit beside the identity and infrastructure sources that complete the picture. For software estate on the workspace side, see Google Workspace Admin to BigQuery, and for cloud infrastructure activity, AWS CloudTrail to ClickHouse.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.