# The role of config.idb in Ignition 8.3 and migrations from 8.1 **URL:** \ **Category:** Ignition\ **Tags:** ignition83\ **Created:** [May 14, 2026, 10:49pm UTC](https://forum.inductiveautomation.com/t/the-role-of-config-idb-in-ignition-8-3-and-migrations-from-8-1/115541 "2026-05-14T22:49:00Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![paul.longtine](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul.longtine/32/10599_2.png) [@paul.longtine](https://forum.inductiveautomation.com/u/paul.longtine)\ **Post date:** [May 14, 2026, 10:49pm UTC](https://forum.inductiveautomation.com/t/the-role-of-config-idb-in-ignition-8-3-and-migrations-from-8-1/115541/1 "2026-05-14T22:49:00Z")
With the introduction to text-based configuration files, what is the role of the tables within the `db/config.idb` database that seem to have been migrated to configuration files? Post migration, it seems like the majority of the gateway configuration that now has a `config.json` still exist as a table within the `config.idb` database. I've landed on a couple rationalizations, either may be true or false, but some clarification may help: 1. The existing _"migrated"_ tables in `config.idb`, post-migration, are still relevant and are being used, but the configuration files takes precedence after a configuration scan / startup. 2. Only some _"migrated"_ tables in `config.idb` are still relevant post-migration, and some tables are ignored entirely but have not been dropped for durability/reliability of the migration process. Of course, meddling with `config.idb` is not something for the faint of heart, but the intention here is to better understand the migration process and how to minimize the time it takes to bring a production 8.3 gateway online from an 8.1 backup. My end goal here is to have a known configuration which can be committed to source control that is defined in terms of the `config` directory, `ignition.conf`, `logback.xml`,`gateway.xml`, ... et cetera. Whether or not it is possible to run a targeted migration on an 8.1 gateway backup that would only bring over what is not contained within these plaintext configuration files (e.g. tag configurations, internal user sources, ???) is one question I am entertaining, that perhaps the wider Ignition community has answers to. The most well-documented approach in my experience seems to be running a migration on an 8.1 .gwbk file and overlaying the desired configuration files on the migrated `data/` folder. One issue on this, is that it may take some amount of time to run this "offline" migration, and I would like to try to optimize this migration process to minimize the amount of time the 8.1 gateway would be running while I have a captured .gwbk that is being migrated to be used in the 8.3 gateway. For instance, if most of my configuration is already determined by the well-known configuration in a textual `config` directory, I would like to _only_ migrate what is not represented there. It seems to me that the migration seems to leave behind some crumbs in this `config.idb` file, which I would ideally like to avoid if possible to have a clean state, where the 8.3 migration machinery believes that this gateway was running 8.3 from the very beginning of time. Does anyone have any wisdom to share in this domain? I feel like I am on the right track, but if anyone has any recommendations or resources I had missed while researching (even the obvious ones!) I would greatly appreciate it. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [May 15, 2026, 12:00am UTC](https://forum.inductiveautomation.com/t/the-role-of-config-idb-in-ignition-8-3-and-migrations-from-8-1/115541/2 "2026-05-15T00:00:34Z")
The IDB file is only used for migration. It can be deleted after upgrade.