What are the signs that an RDS to Aurora migration is ready to promote?

The main indicator is replica lag approaching zero after the source database is placed in read-only mode. At that point, the replica is close enough to current data that promotion should preserve the database state. Teams should also confirm that connections have been broken cleanly and that the target cluster is attached to the right network and backup settings.

How to tell the replica has caught up enough to promote

The clearest readiness signal is not a generic “healthy” status, but evidence that the source is no longer moving faster than the replica. If replication lag is near zero after the source has been put into read-only mode, the target is close enough to current state for promotion to preserve the database as it stood at cutover.

That is important because promotion is a state-change decision, not just an availability decision. The moment you promote too early, you risk splitting writes between source and target or carrying over an incomplete final transaction window.

For an operator, the practical question is whether the target is still converging or whether it has effectively reached the same transactional point as the source. When the answer is “effectively reached,” promotion becomes a controlled cutover rather than a guess.

What else has to be true before promotion is safe

Replica lag alone is not enough if the cutover environment is still unstable. You also want to confirm that client connections to the source have been broken cleanly, because lingering sessions can keep the source active longer than expected and make the final sync less trustworthy.

Network placement matters as well. The target cluster should already be attached to the intended network path, with the expected backup settings in place, so that promotion does not create a database that is current but operationally misconfigured.

In practice, the readiness check is a combination of data convergence and environment consistency. A nearly caught-up replica that sits in the wrong subnet, lacks the expected backup policy, or still has active application writes is not ready to become the production database.

What promotion readiness is really telling you

Promotion readiness is a boundary condition. It tells you that the migration has reached the point where the remaining differences are small enough that the target should behave like the source at the moment of cutover, rather than as a partially stale copy.

That makes the final decision less about raw elapsed time and more about control of the last write window. The stronger the cutover discipline, the more reliable the promotion signal becomes.

Teams often underestimate how much the surrounding operational state affects that signal. A low lag number is meaningful only when the source has stopped accepting writes and the target is already aligned with the intended runtime settings.

Risk and Threat Considerations

An early promotion can create data inconsistency, lost updates, or application errors if writes are still landing on the source or if replication has not fully converged. The main exposure is not an attacker technique but a cutover failure that leaves the business uncertain which database is authoritative.

Failure mechanism: Promotion occurs before write traffic is fully quiesced or before the replica has converged, so the new primary comes online with missing or divergent state.

Impact: Transactions can be lost, duplicate recovery work may be required, and applications can reconnect to a database that no longer matches the expected production state.

Practitioner Guidance

What to verify: Treat promotion as a three-part check: the source must be read-only, replica lag must be effectively gone, and the target must already have the right network and backup configuration. If any one of those is missing, delay promotion rather than trying to “finish after cutover.”

Decision rule: If the replica is close to current but the source is still writable, do not promote yet. If the source is read-only and lag is near zero, promote only after confirming no application paths still point at the source.

Practitioner takeaway: The safest promotion is the one that turns a synchronization check into an operationally clean cutover, with no remaining write ambiguity and no hidden environment mismatch.