TDE Wallet Migration: The Step DBAs Miss During Database Migration

A healthcare provider completes an RMAN duplicate to move a TDE-encrypted database to ExaCC. The restore finishes cleanly. On open, every encrypted tablespace returns ORA-28365: wallet is not open - the keystore wallet, stored outside the database files by design, never made the trip.

Transparent Data Encryption protects data at rest - tablespace-level encryption for datafiles and column-level encryption for individual sensitive fields - using a master key stored in a keystore wallet file, deliberately separated from the encrypted data itself for security isolation.

Each layer here depends on the one below it, which is exactly why skipping the wallet during a migration breaks everything above it. The encrypted tablespace or column is meaningless without the master encryption key that can decrypt it, and that master key is meaningless without the wallet file that stores it – move the data without moving the wallet, and you've migrated a tablespace full of ciphertext with no way to read it.

Figure 1 · The three layers between your data and its encryption key

Every migration method - RMAN duplicate, Data Pump, GoldenGate, XTTS - moves data but not the keystore wallet automatically. The wallet must be explicitly copied, its auto-login configuration re-established, and its master key verified against the migrated datafiles before the database can be opened normally.

This is the single most important thing to understand about TDE and migration: there is deliberately no overlap between these two circles. Every data migration method – RMAN duplicate, Data Pump, GoldenGate, XTTS – was designed to move data, and none of them were designed to also move keystore wallets, because the wallet's isolation from the data it protects is a security feature, not an oversight. That means the wallet step has to be planned and executed as its own separate task, every single time, regardless of which data migration method is in use.

Figure 2 · Whichever data migration method you pick, the wallet step is identical and separate

1. Treat Wallet Migration as Its Own Checklist ItemNever assume it's implicitly covered by the data transfer method.
2. Validate Wallet Open Before the Full CutoverTest wallet access on the target ahead of the final switchover, not during it.
3. Document Wallet Password and Auto-Login ConfigurationKeep this documentation access-controlled but readily available to the migration team.
4. Use ZDM's Built-In Wallet Handling Where PossibleAutomated response-file-driven wallet transfer reduces the chance of this step being skipped.

Working through these four steps in sequence, and confirming the last one before the real cutover, is what separates a clean migration from an ORA-28365 incident discovered in front of end users. The final check – opening the wallet and reading encrypted data on the target while the source is still available as a fallback – is the one step teams most often skip under time pressure, and the one that would have caught nearly every wallet-related migration failure before it became a production outage.

Figure 3 · Four checks that catch a wallet migration gap before cutover