> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stigg.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Upgrading your data export
## Overview
Stigg has upgraded the infrastructure behind its data export for faster, more reliable syncs. To complete the upgrade on your destination, you'll need to re-enter your connection details once. Until you do, your current export keeps running unchanged.
This page explains what the upgrade changes in your warehouse, so you can scope any work on your side before you start.
You'll see an **Action required: reconnect your data export** banner on your export integration in Stigg when your account is ready to upgrade. If you don't see it, there's nothing to do yet.
## What you need to do
In [Stigg](https://app.stigg.io/), navigate to **Integrations > Apps** and open your export integration. Click **Re-enter connection details** on the banner.
This only opens the setup form — nothing changes on your destination, and your current export is untouched until the new connection is live.
**On Snowflake**, the form opens pre-filled with the host, database and schema your current export already writes to, so in most cases there's nothing to re-type.
Your username is **not** carried over, and is deliberately left on Stigg's default. Setup registers a new key on whichever user you name here, so naming the user your current export authenticates as would lock that export out of your warehouse before the new one is ready.
**On BigQuery**, nothing is carried over — the form opens on its defaults, so you re-enter the authentication method, service account email, project ID, dataset and staging bucket. The [BigQuery setup guide](./bigquery#setting-up-the-integration) covers where each value comes from; to reconnect in place, name the same project and dataset your current export writes to.
The new BigQuery connection authenticates as a service account you create for it rather than reusing your current export's credentials, so that export keeps its access until Stigg retires it.
Work through the remaining steps as you would for a new connection — see the [Snowflake](./snowflake#setting-up-the-integration) or [BigQuery](./bigquery#setting-up-the-integration) setup guide for the details.
Once the new connection is live, Stigg retires the previous one for you. You don't need to disconnect anything yourself, and if you abandon setup partway through, your existing export is still there.
## What changes in your warehouse
### Your tables are recreated, not updated
The first sync of the upgraded export drops each table and reloads it from scratch — minutes to a few hours, depending on your volume.
A recreated table is a new object in your warehouse. Any privileges your own roles hold **directly on these tables** have to be granted again afterwards; grants held at the database or schema level are unaffected.
If these tables feed dashboards or scheduled jobs, point the new connection at an **empty schema** — an empty **dataset** on BigQuery — instead of the one you use today. Your current tables stay exactly as they are — just without new updates — and you can switch your queries over once the new tables have finished loading. See [Keeping both exports side by side](#keeping-both-exports-side-by-side) below.
### The usage event tables are renamed
This is the change most likely to break existing queries.
| Before | After |
| -------------------------------- | --------------- |
| `USAGE_EVENT_` | `USAGE_EVENT` |
| `CREDITS_USAGE_` | `CREDITS_USAGE` |
Both tables now carry an `ENVIRONMENT_ID` column, so all of your environments land in one table per entity rather than one table per environment. Where you previously selected an environment by table name, filter on the column instead:
```sql theme={null}
-- before: one table per environment, the environment baked into its name
select * from "USAGE_EVENT_";
-- after: one table, the environment as a column
select * from USAGE_EVENT where ENVIRONMENT_ID = '';
```
The environment ID is the same one your current table name already carries as its suffix.
### Column changes
* **The four `_AIRBYTE_*` columns are gone.** Use `ID` as the row identifier and `UPDATED_AT` as the change timestamp.
* **Every table gains `EXPORTED_AT`**, which records when the export ran — not when the row was created or last changed in Stigg. `USAGE_EVENT` and `CREDITS_USAGE` are the exceptions; they carry their own event timestamps instead.
* **`ENVIRONMENT_ID` is added** to `FEATURE_GROUPS`, `FEATURE_GROUP_FEATURES`, `SUBSCRIPTION_APPLIED_COUPONS` and the `*_INTEGRATION` tables. `FEATURE_GROUP_FEATURES` also gains an `ID` column.
See the [full entity schema](./schema) for every table and column in the upgraded export.
### Type changes
`INTEGRATION.DELETED_AT` arrives as `TIMESTAMP_TZ` rather than `TIMESTAMP_NTZ`. If you compare it against an `NTZ` value, add an explicit cast.
`integration.deleted_at` arrives as `TIMESTAMP` rather than `DATETIME`.
Tables are also partitioned by `updated_at` rather than by extraction date, so filters on the extraction date no longer prune partitions. Filter on `updated_at` to keep your queries partition-pruned.
## Keeping both exports side by side
If you'd rather not have your live tables rebuilt underneath your queries, point the new connection at a schema that's empty — a dataset, on BigQuery — either a new one or one you create for this purpose. Everything else about setup is the same.
What this gives you:
* Your existing tables keep their current contents and stop receiving updates once Stigg retires the old export.
* The upgraded export loads a fresh copy into the new schema.
* You switch your queries over when you're ready, then drop the old tables yourself.
The trade-off is that your queries have to be repointed at the new schema. Reconnecting **in place** — keeping the same database and schema, or project and dataset on BigQuery — means your table names don't change and dashboards built on them keep working, at the cost of the rebuild described above.
### Reconnecting in place on Snowflake
If you keep the same database and schema, the setup script has to take ownership of the tables already in that schema, because the upgraded export needs to own a table to rebuild it. The script does two things for you:
1. Transfers ownership of the tables in that schema to the export's new role, preserving the privileges other roles already hold on them.
2. Grants your current export's role its access back, so it keeps writing until the upgraded export replaces those tables on its first sync.
Both statements are visible in the script before you run it. If any table in the target schema is one **you** created rather than Stigg, don't run the blanket ownership transfer — the script says so inline, and you can transfer ownership one table at a time instead.
Don't reuse a network policy that still allowlists your current export's IP addresses. The setup script's `alter network policy ... set allowed_ip_list` statement **replaces** the entire list rather than adding to it, which would lock out a sync that's still running. Give the new integration its own policy name, or add the new addresses to your existing list by hand instead of running that step as-is.
## Questions
If anything here affects a pipeline you can't easily change, [contact Stigg support](mailto:support@stigg.io) before you start — we can walk through your specific setup with you.
## Related topics
- [Snowflake setup steps](/documentation/importing-and-exporting-data/export/snowflake.md#setting-up-the-integration)
- [BigQuery setup steps](/documentation/importing-and-exporting-data/export/bigquery.md#setting-up-the-integration)
- [Full entity schema](/documentation/importing-and-exporting-data/export/schema.md)