# Migrate Tag History Data Post Migration of Windows/Tags to New Gateway/SQL Server

**URL:** <https://forum.inductiveautomation.com/t/migrate-tag-history-data-post-migration-of-windows-tags-to-new-gateway-sql-server/25731>\
**Category:** Ignition\
**Created:** [June 11, 2019, 4:31pm UTC](https://forum.inductiveautomation.com/t/migrate-tag-history-data-post-migration-of-windows-tags-to-new-gateway-sql-server/25731 "2019-06-11T16:31:41Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\
**Post date:** [April 11, 2025, 7:23pm UTC](https://forum.inductiveautomation.com/t/migrate-tag-history-data-post-migration-of-windows-tags-to-new-gateway-sql-server/25731/6 "2025-04-11T19:23:19Z")

</div>

I recently had to migrate history from one server to another. Here are some good reference threads. There's more than one way to skin a cat but these threads should be helpful.

> [@Tag History Migration Best Practices? Upgrading to new servers!](https://forum.inductiveautomation.com/t/tag-history-migration-best-practices-upgrading-to-new-servers/75766/2):
>
> If you are allowed downtime, it is as simple and making the new database connect just like the old database, using the same database connection (just update the driver ahead of time). MariaDB slots in as a replacement for MySQL quite nicely. Switch to DNS names in the connection URL before old shutdown if you are going to change IP addresses--make that DNS name point at the new DB before new gateway startup/restore. So: Switching to DNS name for DB connection and put in mutually compatible…

> [@Migration Historical Data](https://forum.inductiveautomation.com/t/migration-historical-data/71479):
>
> I have a Ignition setup, which uses only one database connection. Historical data tables per month have more than 200 billion rows and size more than 50GB each one. How to correctly transfer historical data tables to another database without lost data? I would like to know the correct sequence of actions. Please help.

> [@Ignition Historian DB and migration to the new gateway](https://forum.inductiveautomation.com/t/ignition-historian-db-and-migration-to-the-new-gateway/41813):
>
> Hello, I turn to you with question I was not able to find in any sources and I am not alone having this issue (e.g. here: [http://forum.inductiveautomation.com/t/migrate-tag-history-data-post-migration-of-windows-tags-to-new-gateway-sql-server/25731](http://forum.inductiveautomation.com/t/migrate-tag-history-data-post-migration-of-windows-tags-to-new-gateway-sql-server/25731) ). We have migrated Ignition servers to the completely new VMs, everything seems to be up and running so far except the access to values in Historian for the past months. The DB table [IgnitionHistorian].[dbo].[sqlth\_drv] has drv\_id = 1 and 2 for …

You can always call support to get help with fixing backend tables if you need to update those. I did.

---

_[View the full topic](https://forum.inductiveautomation.com/t/migrate-tag-history-data-post-migration-of-windows-tags-to-new-gateway-sql-server/25731)._
