# 8.3 module migration: supported timing for deleting legacy PersistentRecord rows after NamedRecordMigrationStrategy?

**URL:** <https://forum.inductiveautomation.com/t/8-3-module-migration-supported-timing-for-deleting-legacy-persistentrecord-rows-after-namedrecordmigrationstrategy/117377>\
**Category:** Module Development\
**Tags:** ignition83, ignition81\
**Created:** [October 7, 2026, 9:45pm UTC](https://forum.inductiveautomation.com/t/8-3-module-migration-supported-timing-for-deleting-legacy-persistentrecord-rows-after-namedrecordmigrationstrategy/117377 "2026-10-07T21:45:56Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![mdia](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mdia/32/87599_2.png) [@mdia](https://forum.inductiveautomation.com/u/mdia)\
**Post date:** [October 7, 2026, 9:45pm UTC](https://forum.inductiveautomation.com/t/8-3-module-migration-supported-timing-for-deleting-legacy-persistentrecord-rows-after-namedrecordmigrationstrategy/117377/1 "2026-10-07T21:45:56Z")

</div>

Hi all,

We're developing a module that supports both Ignition 8.1 and 8.3, and I'm testing the supported 8.1 → 8.3 configuration migration path.

On 8.1, the module stores configuration in a `PersistentRecord`. On 8.3, the equivalent configuration is a named resource using `ResourceTypeMeta` / `NamedResourceHandler`.

For migration we're using:

- `GatewayModuleHook.getRecordMigrationStrategies()`
- `NamedRecordMigrationStrategy`
- `DefaultRecordEncodingDelegate`

The migration itself is working correctly on 8.3.6, including conversion of an 8.1 encoded credential into the 8.3 secret representation.

The part I'm trying to clarify is what the supported lifecycle is for cleaning up the old 8.1 row afterward.

I tested deleting the module-owned legacy row through the public persistence APIs:

```java
GatewayContext.getPersistenceInterface().getSession()

```

followed by normal `find`, `deleteRecord()`, and explicit transaction/commit handling.

That works in testing. I also tested interruption around the cleanup transaction:

- kill before migration
- kill after the new resource exists but before cleanup
- kill after the delete is flushed but before commit
- kill after cleanup commit

The rollback/restart behavior looked safe in those cases.

However, I also found an important restore case: if an 8.3 `.gwbk` restore is still being processed and the Gateway is killed, the next startup may replay restoration and migration. Because of that, I don't want to assume that simply reaching Gateway `RUNNING` means it is safe for the module to automatically delete migrated legacy rows.

So I have three questions:

1. **After a `NamedRecordMigrationStrategy` has successfully created the new resource, is it supported for a module to transactionally delete its own migrated `PersistentRecord` row using the normal persistence/session APIs?**

2. **Is there a public lifecycle callback/event/state that guarantees Gateway restore and record-to-resource migration are fully and durably complete?**

3. **Is there a supported module API for removing an obsolete migrated table entirely?**

I specifically want to avoid raw SQL or private/internal database APIs.

Target floor versions are **8.1.33 → 8.3.6** , so I'm especially interested in what is supported on 8.3.6 rather than behavior added in later 8.3 releases.

Thanks!

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [October 7, 2026, 10:13pm UTC](https://forum.inductiveautomation.com/t/8-3-module-migration-supported-timing-for-deleting-legacy-persistentrecord-rows-after-namedrecordmigrationstrategy/117377/2 "2026-10-07T22:13:26Z")

</div>

You don't need to do anything.  
The internal database is inert and ignored after migration has been run.  
Migration is expected to either succeed or fail (it's typically very quick), and if it's succeeded an entry will be written to the `MIGRATED_TABLES` table in the idb - at which point, on next startup your migrator will be skipped.

Just ignore it. In the next major version (`2027`) we're dropping all the migration and SQLite/IDB code entirely, because the only path to upgrade will be from `8.3`. In some version beyond that, we may proactively remove .idb files from gateway backups.

But generally, the advice is "don't overthink it".  
Write your migrator to do the simplest idb config -\> file config. It should take a few milliseconds, and then you never have to think about migration again.