Why a rollback plan is indispensable before the cutover
A rollback plan is not an optional accessory, it is the safety net that lets the team cut over to production with confidence. When a critical migration reveals a serious incident within the first hours live (data corruption, a service degraded below acceptable thresholds, or a system incompatibility not detected in pre-production), the ability to return quickly to the source infrastructure determines whether the outage lasts twenty minutes or several hours. Without a defined, tested, and documented rollback strategy, the team faces a paralyzing dilemma: persist with a failing system or improvise a manual restoration under pressure, which lengthens the incident and increases the risk of human error. For migrations to AWS involving sensitive data or critical services, a complete and rehearsed rollback plan reduces the psychological stress of the cutover itself, because everyone knows that the risk of a decision is bounded by a predefined return time. This is precisely why industry best practices require that the rollback be tested at least once under real pre-production conditions before D-day.
Criteria and conditions for triggering the rollback
Deciding to launch a rollback must be an objective process, not a panic reaction. Before the cutover, the team must explicitly define the conditions that justify an immediate rollback, because these conditions also determine the acceptable observation window after the switch. A typical condition is data loss: if the application or database logs reveal corruption beyond an acceptable threshold (for example, more than 1% of the cutover writes are invalid), the rollback must be launched without waiting. Another is critical performance degradation: if the average response time of the production APIs exceeds 5 seconds for more than 5 consecutive minutes, which indicates an architecture or resource problem in the new AWS environment, the rollback immediately switches users back to the old system. Likewise, if a key service (authentication, payment) becomes inaccessible or returns 5xx errors continuously after 15 minutes, the return to the source infrastructure must be launched without debate. For complex migrations, you can also include secondary criteria such as the number of abnormal application errors (an unexplained spike in errors) or a monitoring alert that trips a predefined threshold. The key is to document these criteria BEFORE the cutover, ideally in the operational runbook, with measurable and non-subjective thresholds. This avoids decisions made under pressure and ensures that the entire team acts according to the same reference framework.
Technical rollback strategies based on the architecture
The rollback technique varies greatly depending on what was migrated and how. For a stateless application hosted on EC2 instances behind a load balancer, the rollback can be as simple as a change to the security group or the DNS, which switches traffic instantly to the old servers left active in parallel. If the source infrastructure was taken offline after the switch (a zero-downtime approach without a standby), a rollback requires restarting and verifying the old servers, which adds a few minutes of manual work and requires that no one has shut down or deleted the resources. For databases, the rollback is trickier: if only the AWS database has received writes since the cutover, you must either restore the source database from a very recent backup (a few seconds before the cutover), or maintain bidirectional replication during a rollback window (often 2 to 4 hours after cutover). A common approach is WAL (Write-Ahead Log) replication or logical replication, which records every change in near real time and makes it possible to replay the post-cutover writes onto the source database without loss. For stateless services (queues, caches), the rollback is generally transparent: the requests recorded in the AWS queue can be reprocessed on the old infrastructure without a problem, provided the old application stays listening. Hybrid migrations (AWS cloud + on-premises) often benefit from a faster rollback, because the on-premises resources can stay warm and ready. The key is to choose a strategy consistent with the tolerated RTO (Recovery Time Objective): if the organization accepts 5 minutes of unavailability, a manual restoration is enough; if it requires a switch in under 30 seconds, an automatic DNS or load balancer switch is necessary.
Bidirectional synchronization and a limited rollback window
Maintaining the rollback capability for too long after the cutover becomes technically complex and costly. This is why best practices define a bounded rollback window, typically 2 to 4 hours after going live. During this window, the source infrastructure must stay active and capable of receiving traffic, and the data must stay synchronized so that a return does not cause abnormal loss or duplication. For databases, this means putting in place bidirectional replication during these critical hours: every write on the new AWS database is duplicated in near real time on the source database, and vice versa if a rollback occurs. Tools such as AWS DMS (Database Migration Service) with the continuous replication option, or third-party solutions such as Debezium or GoldenGate, enable this synchronization. Beyond the window (after 4 hours for example), the team generally decides to close the source infrastructure and stop the replication, because extending beyond that becomes an unjustified fixed cost and increases the risk of data divergence if no one is actively monitoring the replication. The other advantage of bounding the window is psychological: it pushes the team to actively monitor the first hours post-cutover, which is exactly when problems are most likely to appear. After the window closes, the old infrastructure is gracefully shut down, the AWS resources are confirmed stable, and the migration is considered final.
Runbook and responsibilities for executing the rollback
A rollback plan without an executable runbook is a plan on paper. The runbook must be a step-by-step sequence, tested and approved, that any engineer on the team can execute under pressure in 5 to 10 minutes maximum. It begins with the go/no-go decision: who has the right to declare a rollback necessary (you need at least two decision-makers to avoid false positives) and who contacts whom (incident commander, ops lead, etc.). Next comes the communication plan: notifying the stakeholders, the users (via a status page), the product team, in order to avoid contradictory decisions being made during the rollback. The technical execution phase is then very precise: stop the traffic to the new AWS infrastructure (via DNS, load balancer, or security group), verify that the old infrastructure is operational, switch the traffic to it, verify the health of the service (a few key functional tests), and confirm that the critical data is intact. Each step must have an assigned owner and a time limit (for example: 60 seconds to switch the DNS, 2 minutes to validate the service health), beyond which you escalate rather than wait. This timed breakdown prevents a rollback meant to last 5 minutes from stretching into half an hour of hesitation.
Testing the rollback in pre-production and iterating
A rollback has real value only if it has been tested, at least once, under conditions as realistic as possible. This means simulating a complete cutover to the AWS infrastructure in pre-production or staging, then triggering an intentional rollback and measuring the real execution time, the errors encountered, and the adjustments needed. The test must include the data: load a sufficiently large copy of the production database (at least a few million rows for the critical tables) so that the replication is representative, then simulate post-cutover writes and verify that the rollback brings the data back to the exact state at cutover without corruption or duplication. The team will also note the pitfalls discovered: for example, a rollback script that assumes the SSL certificates are present on the old infrastructure, but which are not, or a synchronization that drags because an index is missing in production. These tests also make it possible to validate the timings announced in the runbook: if the test shows that the DNS rollback takes 15 minutes instead of the promised 2 minutes, the runbook must be revised before D-day. Iterations following the tests are normal and expected; they strengthen confidence and avoid nasty surprises. Finally, partially re-running the test each quarter or before a major cutover strengthens the team's muscle memory and detects deviations (for example: a dependency has changed and the rollback no longer accounts for it).