Why the maintenance window is the major constraint of the cutover The maintenance window is the interval of time during which your infrastructure changes state: services shut down on the old platform, data synchronizes, and you switch over to AWS. It is the moment when end users lose access to the application, and it is also the moment when the risk of data loss or application inconsistency is highest. Contrary to what some teams imagine, the window is not a simple restart: it is a cascade of interdependent operations where every minute counts because it directly affects your SLA and the trust of your users. A well-planned window lasts only a few hours; a poorly sequenced window can stretch to half a day or more, turning a "standard" maintenance into a critical incident. This is why Stralya insists that this window be described in detail in the cutover plan, with precise timings for each step and escalation thresholds defined in advance. If you wait until the day itself to discover that data synchronization takes twice as long as expected, or that the network team has not validated the DNS routes, you will fall behind and your window will inexorably swell. ## The critical activities that consume the window During the maintenance window, several activities must take place in sequence or in parallel, and it is the longest of them that determines the total duration. Let us identify the main ones. The first is shutting down the active services on the source infrastructure: applications, background workers, distributed caches. This step seems simple but it is not if you have services that refuse to stop cleanly (timeouts, persistent reconnections) or in-flight asynchronous tasks that must finish before shutdown so as not to be lost. Generally, you need to plan 15 to 30 minutes here, with checks that no critical job has been interrupted. The second is data synchronization: you must ensure that all database changes since the last planned replication are copied to the AWS target, and that shared file volumes or caches are up to date. If your data source has a heavy load until the last moment (orders in progress, user uploads), this synchronization can stall or be imprecise. This is why it is often combined with a "read-only" mode: you stop writes before stopping services, you sync, and only then do you cut over. This can add 30 to 60 minutes depending on the data volume. The third activity is the traffic switchover itself: DNS (changing the records to point to AWS), load balancer (if you use one), internal network routes (if it is a hybrid architecture). Each of these operations must be verified to ensure that traffic really arrives at the right destination. Count 15 to 45 minutes depending on your architecture. Finally, the health validation: once traffic is switched over, you must quickly test that the applications respond, that connections to third-party services (APIs, databases, queues) work, and that a few critical business scenarios pass. This is the fastest phase if you have pre-written the tests (10 to 30 minutes), but the longest if you discover unexpected problems (potentially several hours). ## Reducing the window: strategies and trade-offs The temptation is strong to want to reduce the window as much as possible, but there are physical and logical limits that must be respected. Here are the real levers. The first is to pre-synchronize the maximum of data well before the window. If you have had continuous replication for two weeks, the delta sync (synchronization of only the recent changes) will be very short. This is why Stralya recommends a long-term replication phase of 4 to 8 weeks before cutover: the window becomes shorter because you synchronize only a few gigabytes of recent writes, not your entire database. Second lever: parallelize what can be parallelized. While the data synchronizes, you can in parallel start configuring the monitoring alerts on AWS, validate the DNS routes (not applying the route, just verifying its syntax), or prepare the rollback. Every minute saved through parallelization is a minute gained on the total window. Third lever: use "zero downtime" or "minimal downtime" cutover tools. Some solutions (for example Continuous Replication with automated failover) make it possible to switch traffic in a few seconds once the source and target are synchronized, instead of waiting for a manual validation. This does not remove the window (there is always a moment when the data must be frozen for the final sync), but it drastically reduces it. Fourth lever: automate the validations. If you have a Selenium or API test suite that runs automatically after the switchover, instead of testing each flow manually, you save 20 to 40 minutes. The main trade-off here is the investment time: automating the tests takes 3 to 5 days of development, but you recoup that week through shorter future windows. Finally, the last lever is risk tolerance: accepting a slightly shorter downtime means accepting a slightly higher risk of discovering a problem after switchover, which would lengthen post-cutover monitoring or require a rollback. It is a business choice: a bank will never make this choice, a startup can consider it. Stralya helps its clients define this threshold based on their business and technical context. ## Critical dependencies that can lengthen the window Even the best planning can be disrupted by hidden dependencies that emerge during the window. The first, and often the most insidious, is incomplete or slow data synchronization. Imagine that your source database is 500 GB, but the network throughput between your datacenter and AWS is only 100 Mbps (a standard, unoptimized link). The mathematical sync of 500 GB at 100 Mbps takes about 11 hours. If you had planned a 4-hour window, you have a problem. This is why Stralya recommends predicting the real throughput very early and adjusting the timing or the network infrastructure (private circuit, transfer accelerator) well before the window. Second critical dependency: the third-party services that do not respond during the window. You have switched traffic to AWS, but your payment API, your external authentication provider, or your CDN is under maintenance on precisely that day. No test revealed it to you because you had mocked these services. This forces the team to either wait or roll back. This is why you must check the status of all critical third-party services the day before the window, and have a plan B if one of them is unavailable. Third dependency: DNS propagation. Changing a DNS record does not mean everyone accesses it instantly. The TTL (time-to-live) determines how long clients will keep the old address cached. If you had a TTL of 3600 seconds (1 hour), and you change the IP at T+0, some clients will only reach the new address at T+1 hour. To get around this problem, you must lower the TTL 24 or 48 hours before the window (for example set it to 60 seconds), wait for everyone to have adopted it, then make the change during the window. Many teams forget this step and discover the problem live. Fourth dependency: the firewall rules and security groups that have not been synchronized. You have configured the AWS rules correctly on your VPC, but a rule on a corporate edge firewall still blocks the old source IP. Traffic arrives at AWS but does not get back out. This adds hours of debugging. Stralya insists that these dependencies be documented in the cutover plan, with clearly named owners and defined timeouts: if the data sync does not finish in 6 hours, you roll back automatically instead of waiting indefinitely. ## Timeline and key checkpoints to validate before and during the window A well-executed window follows a defined timeline, with key checkpoints at each step. Ideally, this timeline is described in a shared document (a runbook, or a playbook) that the whole team knows and can execute point by point. Here is a typical structure. D-7 days before the window: verify that the prerequisites are OK (AWS capacity provisioned and tested, long-term replication running for at least 2 weeks, DNS TTL lowered for 48 hours). D-1 day: full cutover test on a copy (mock migration of test data to validate all the scripts, all the configurations). D-2 hours before the window: official notification to users (in-app message, email, status page). T-60 minutes: final internal communication to the IT team, terminal preparation, verification that no one is doing a system update or restart that could interfere. T-0 (window open): shutdown of source services, start of the sync. At this moment, you also launch continuous monitoring: logs, CPU/memory metrics, network connections. A single owner must steer and announce each step. T+30 min or so: end of the data sync, DNS switchover, load balancer switchover. T+60 min: full health validation (automated tests, manual spot tests). T+90 min: stable monitoring, reduction of on-call staff. T+120 min or more: escalation if an unforeseen problem emerges (rollback or technical resolution). After the window, the follow-up continues: 24/7 monitoring, rapid escalation if an anomaly is detected. Each checkpoint must have an owner ("it is Marylene who validates the data sync," "it is Jerome who switches the DNS"). If a checkpoint fails or takes too long, the escalation procedure triggers either a rollback or a window extension (but not indefinite waiting). This may seem academic, but it is the difference between a 2-hour window and a half-day window: it is the absence of clear ownership and escalation triggers that makes things drag. ## Rollback and contingency plans: handling the unexpected Even with excellent planning, something can always deviate from the plan. This is why every maintenance window must have a documented and tested rollback plan. Rollback is the reverse operation: you switch traffic back to the old infrastructure and you re-synchronize any data that might have been written to AWS in the meantime. The critical question is: how quickly can you roll back? If the answer is "10 minutes," you can be more aggressive in your window. If it is "2 hours," you must be more conservative. Stralya recommends that the rollback always be faster than the forward execution, which means that you must keep the old infrastructure operational for 24 to 48 hours after a successful cutover, the time for everyone to know that the migration is stable. It is a cost, but it is the cost of safety. Second point: when do you trigger the rollback? This is a stressful live decision, and it must be pre-defined. For example, "if the health validation reveals more than 5 percent of errors after 30 min of switchover, automatic rollback." Or "if the data sync is not finished after 6 hours, roll back and reschedule." These thresholds must be agreed in advance, not debated live. Third point: the data written after switchover. If you have rolled back after 2 hours on AWS, and you want to relaunch a corrected migration, what happens to the data that users wrote during those 2 hours? In general, it is lost and you must warn the users. This is a major reputational risk that pushes teams to be very cautious with rollback thresholds. Finally, a contingency plan is not tested live. At least one week before the window, you must simulate a rollback (on a test environment or on a test replication of real data) to make sure that your scripts work, that the teams know them, and that the timing is realistic. Too many teams discover during the window that their rollback script is broken or that no one has the passwords to the old servers. This is unacceptable and it is a major source of windows that drag on. Stralya insists that rollback be an integral part of the cutover plan, not an afterthought.