# Migrate Tag History Data Post Migration of Windows/Tags to New Gateway/SQL Server **URL:** \ **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:** 6\ **Page:** 1
**Author:** ![MikeAllgood](https://avatars.discourse-cdn.com/v4/letter/m/a183cd/32.png) [@MikeAllgood](https://forum.inductiveautomation.com/u/MikeAllgood)\ **Post date:** [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/1 "2019-06-11T16:31:41Z")
Long title! 🙂 I may have been a bit short sighted when I migrated some content from one server to another for a customer. In the effort we were tasked with moving a set of OPC tags and windows from one server (that was remote from the site) to a new site based server. My lack of foresight was in regard to the tag history data. So now the customer only has access to data back to when the content was migrated. What would be the most effective and convenient method to migrate the tag history data from the original server to the new server? Both servers have their own MS SQL server and it would be preferred for the site data to be in the site SQL server. Thanks, Mike ---
**Author:** ![richardNZ15](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/richardnz15/32/33373_2.png) [@richardNZ15](https://forum.inductiveautomation.com/u/richardNZ15)\ **Post date:** [January 26, 2023, 8:20pm UTC](https://forum.inductiveautomation.com/t/migrate-tag-history-data-post-migration-of-windows-tags-to-new-gateway-sql-server/25731/2 "2023-01-26T20:20:09Z")
Got this exact requirement too, what kind of solution did you find? ---
**Author:** ![MikeAllgood](https://avatars.discourse-cdn.com/v4/letter/m/a183cd/32.png) [@MikeAllgood](https://forum.inductiveautomation.com/u/MikeAllgood)\ **Post date:** [January 26, 2023, 10:22pm UTC](https://forum.inductiveautomation.com/t/migrate-tag-history-data-post-migration-of-windows-tags-to-new-gateway-sql-server/25731/3 "2023-01-26T22:22:52Z")
That's been a minute! 😆 If I recall correctly, we did not find a solution. The client decided it was not worth the effort. Sorry I can't be of more help. ---
**Author:** ![richardNZ15](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/richardnz15/32/33373_2.png) [@richardNZ15](https://forum.inductiveautomation.com/u/richardNZ15)\ **Post date:** [January 27, 2023, 6:35am UTC](https://forum.inductiveautomation.com/t/migrate-tag-history-data-post-migration-of-windows-tags-to-new-gateway-sql-server/25731/4 "2023-01-27T06:35:23Z")
No problem. I think it can be done if you keep track of old and new tagID's carefully, and do some direct SQL table manipulation. ---
**Author:** ![Erin\_Wentworth](https://avatars.discourse-cdn.com/v4/letter/e/a183cd/32.png) [@Erin\_Wentworth](https://forum.inductiveautomation.com/u/Erin_Wentworth)\ **Post date:** [April 11, 2025, 7:13pm UTC](https://forum.inductiveautomation.com/t/migrate-tag-history-data-post-migration-of-windows-tags-to-new-gateway-sql-server/25731/5 "2025-04-11T19:13:10Z")
Did you ever find a solution for this? Having the same problem. ---
**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")
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.