Scope: Snowflake > Snowflake migration
If you need to relocate the Snowflake table(s) HG's RGI Platform reads from — for example moving your Accounts, Contacts, or Events table into a different Snowflake database or schema — you can do this without re-ingesting all your data and without losing sync history, as long as each record keeps its identity through the move. This guide explains what happens during the move, what to preserve, and how to make the switch safely.
What happens to your data during the move
When relocating a source table, there are usually two things one wants to avoid:
A full re-ingestion of the table — which could kick off unnecessary reprocessing and push new scores and signals downstream. This can be avoided by following the steps below.
The platform losing track of history — This cannot happen as our platform does not automatically sweep data from our database once a data source (connector) is disconnected or migrated. We keep already ingested data.
A location-only move can be transparent. While the connection is briefly disconnected during the switch, ingestion simply pauses and then resumes from where it left off — there's no mass re-pull, and your state and history remain intact.
What you must preserve
For the move to be transparent, the table in the new location must keep all three of the following identical to the old table:
The id values — the same records must carry the same IDs.
The names of every other mapped column, especially the record ID column. This is the most common thing that breaks a migration: if the key column (or any other column) is renamed during the move, records and their associated values may not be accurately captured. Keep column names exactly as they are today.
The created_at and updated_at values. Carry the existing timestamps over (for example by cloning the underlying snapshot). If these are regenerated to the migration time, every row will look freshly "updated" and be re-processed unnecessarily.
Tip: cloning the existing table/snapshot into the new database or schema is the simplest way to guarantee IDs, column names, and timestamps all carry over unchanged.
How to make the switch
Create the table in the new database/schema, preserving IDs, column names, and created_at/updated_at as described above.
Grant the HG's RGI Platform service user access on the new location: SELECT on the table, plus USAGE on the new database and schema.
Edit the existing connection — do not create a new one. Go to the Snowflake integration settings, click Edit, update the database/schema parameter, step through the flow, and be sure to click Save at the end (the save button is at the final step).
Schedule the change for a Monday–Thursday and give us a heads-up a few days before (see Need help? below) so we can monitor the next data pull and processing cycles.
If you're already editing the connection, consider switching to key-pair authentication — Snowflake is deprecating single-factor password auth. Password auth still works if you're not ready.
After the switch — how to verify
Confirm that recent values are flowing in Snowflake for:
id (populated, matching your source)
created_at / updated_at
event_timestamp (for the Events table)
Reach out to our support team to confirm everything looks good.
Need help?
Reach out through your usual shared Slack channel (if you have one), or email customersupport@hginsights.com. Where possible, let us know a few days before you make the change so we can monitor the cutover live and validate the data afterward.
Contact us if you cannot preserve the original IDs, column names, or timestamps, or if after the switch you notice records or scores no longer updating as expected.
FAQ
Will moving the table cause RGI platform to re-ingest everything?
No — not if record identity is preserved. The ingestion pauses while the connection is down and resumes from where it left off, keeping your trained models unaffected.
Do I need to create a new connection when relocating the table?
No. You should edit the existing Snowflake connection and update the database/schema parameter instead of creating a new one.
What should I preserve during the table move?
You must preserve the id values, the names of every mapped column, and the created_at/updated_at values to ensure a transparent move.
Can I rename the id or another mapped column during the move?
It's not recommended. Talk to us first (customersupport@hginsights.com), as renaming a mapped column can prevent accurate data capture and may require coordinated changes.
How can I verify that the migration was successful?
Confirm that recent values for id, created_at/updated_at, and event_timestamp (for the Events table) are flowing correctly and matching your source. Ask our support if you are in doubt.
Will this impact my Data Studio scoring models?
Your Customer Fit and Likelyhood to buy models are not affected by a source move. Once a model is trained, it becomes independent of the underlying source data — it simply applies the logic it has already learned to net-new records as they arrive. Relocating the table it reads from doesn't retrain, reset, or recalibrate anything; scores and signals keep being generated exactly as before.