Key Rotation
Periodically replacing a cryptographic key with a new one while retaining the old for decrypting existing data, so exposure from any single key is bounded.
The purpose is to bound the amount of data protected by any one key and the window during which a compromised key is useful. It is also a standing requirement in most compliance regimes.
The distinction that determines effort:
Rotating the key encryption key is cheap. With envelope encryption, only the wrapped data keys must be re-encrypted, not the data — which is why cloud KMS services offer automatic annual rotation with no application impact and no re-encryption of stored objects.
Rotating the data encryption key requires re-encrypting the data, which for a large dataset is a real project. This is usually done lazily: new writes use the new key, old data is re-encrypted on next write or by a background job, and both keys remain available meanwhile.
The properties a rotation design needs. Key versioning, so ciphertext records which key version protected it — without this, rotation is impossible because you cannot tell what to use. Overlap periods, since old keys must remain available for decryption long after they stop being used for encryption. And rotation that does not require downtime, which follows from the first two.
The failure worth guarding against: deleting an old key while data encrypted under it still exists. That is unrecoverable data loss, and it is why key deletion should have a mandatory waiting period.