> ## Documentation Index
> Fetch the complete documentation index at: https://developers.authlete.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Stopping and Resuming the Token Migrator

> The Token Migrator resumes from the timestamp saved on its persistent volume after a restart; it may reprocess some tokens but never skips any.

The Token Migrator resumes automatically after it is stopped, whether intentionally or not. It saves its progress on the persistent volume that the Helm chart mounts. When it restarts with the same volume, it continues from the last saved point. It may reprocess some tokens, but it never skips a token.

## Token ID mapping files (mapping-output)

The `mapping-output` directory holds one file per client that maps each source token ID to its destination token ID. The Token Migrator uses these files to find the destination token to update when a source token changes. Each file is named `<service ID>:<client ID>.json`. The Token Migrator generates these files as part of migration processing.

If the mapping files are lost, the Token Migrator regenerates them, but some tokens may then be created as new tokens in the destination instead of updating the existing mapped tokens. The earlier copies (stale tokens) remain in the destination, so a token that was refreshed or revoked in the source may still be valid there. In this situation, we recommend completely restarting the whole token migration. This involves stopping the Token Migrator, removing the migrated services and clients from the destination (keep the service and client that the Token Migrator uses), and deleting all files on the Token Migrator's persistent volume. Then [migrate the services and clients again](/deployment-and-operations/migration-from-existing-system/migrating-settings-from-an-older-version-of-authlete) and start the Token Migrator.

## Recovery point

### How the moving timestamp is saved

During migration, the Token Migrator tracks a moving timestamp, which records the time up to which it has processed all token changes. After it has processed all token changes up to the current moving timestamp, it writes this value to `timestamp.txt` as a Unix epoch time in **milliseconds** (for example `1784401524667`).

This file is the recovery point in case the Token Migrator stops. On the next start, the Token Migrator continues from the time in `timestamp.txt`.

Because the Token Migrator processes all token changes before it writes `timestamp.txt`, restarting from that point may reprocess tokens that were already created or updated, but it does not miss any token changes.

### If timestamp.txt is lost

1. Stop the Token Migrator (for example, set `tokenmigrator.enabled` to `false` and run `helm upgrade`).
2. Find the last processed timestamp in the shutdown log: `Shutting down sync migration task, latest timestamp [<value>]ms` (see [Shutdown logs](/deployment-and-operations/self-managed-deployment/token-migrator/interpreting-token-migrator-logs#shutdown-logs)).
3. Create `<mount path>/timestamp.txt` containing only that value, in milliseconds.
4. Start the Token Migrator again.

If the container was killed and no shutdown log was written, use an earlier timestamp that you are sure was already processed, such as the last `Read in moving timestamp initial value` log. Using an earlier timestamp only causes some tokens to be reprocessed.