These four events landed in the same mid-November 2026 window. Nothing public connects them, and I am not suggesting a link.
What they share is a lesson about gates, verification and change discipline. Things fail at cutovers, at tests that touch production, and in old infrastructure that is finally being changed. One of the four shows the opposite pattern: an automated no-go that refused to proceed.
I build MigrateForge in Coimbatore: a system that moves PHP applications to Java 21 / Spring Boot and keeps cutover blocked until recorded user journeys match on both sides. That is not a claim that it would have prevented any of these incidents. It is about applying the same discipline to a software cutover.
Microsoft 365: the checker was in the failure path
Starting shortly before 1 p.m. ET on Thursday, 12 November, Outlook, Teams, SharePoint Online and Copilot were disrupted for a large part of a day, with knock-on effects for organisations that depend on them. CNBC reported that engineers were still restoring service nearly 24 hours later, and that Microsoft said on Saturday, 14 November, that it had addressed the underlying issue and restored service to the remaining affected customers and regions.
Microsoft's first public account was not a traffic surge. A portion of its infrastructure was under elevated load across multiple regions because servers had become unexpectedly unavailable. As Ars Technica quoted from Microsoft's status updates, the company pointed to "a problem that's causing servers to fail automated health checks and become unavailable," which then strained the machines that remained. Recovery was slow in part because early fixes did not hold: some servers brought back online became unresponsive again once they received traffic.
Microsoft later said the disruption stemmed from "an issue during an earlier network capacity upgrade." CNBC reported that the company had not detected malicious activity and would issue a full report once its assessment was complete. Until that post-incident report is published, the upgrade wording is Microsoft's stated cause, not a finished root-cause analysis.
Two points matter for anyone planning a cutover.
First, a health check is a gate. If the gate fails in a way that removes healthy capacity, the rest of the system inherits the error. "The dashboard is green" is not evidence if you have not tested the checker.
Second, a workflow that lives inside someone else's cloud inherits that cloud's outages. MigrateForge is local-first: source code stays on the client's machines, and only AI requests leave. When an AI provider is down, translation runs end PAUSED or ENVIRONMENT_INVALID and resume later with nothing lost. Capture, replay, parity verification, security sweeps and evidence reports need no AI call. Several recent nights spent $0 while still producing verified waves.
Workday: a disaster-recovery test reached production
On the evening of Friday, 13 November, Workday placed all WD1 production tenants into maintenance. The company's Community Status Page notice, quoted in full by Washington University IT, said:
While validating the weekly Maintenance Window for Disaster Recovery tenants, we have identified that tenanted services within the DR Site unexpectedly connected to Production databases. As a result, this has left data in an inconsistent state that can cause errors accessing tenants or jobs/integrations/tasks to fail with missing transaction error messages.
Florida Atlantic University's IT status page reported the same pattern that night: an issue involving the disaster-recovery environment had left production data inconsistent, and production was taken offline as a precaution. FAU said users could not access the system or complete normal business activities; Washington University had to collect time by hand for staff who could not clock in. FAU said production was available again at 10:30 a.m. on Saturday, 14 November; Washington University marked the unplanned outage resolved later that afternoon, with some updates between systems still delayed. Restoration times varied by tenant. Workday has not, in public, said how many customers were affected, and a detailed root-cause report is still outstanding.
A disaster-recovery test is supposed to prove you can survive a failure. Here the test became the failure, because the recovery copy was not isolated from live databases. For a migration, the analogue is direct. If your verification environment can write to production, or if a rehearsal shares state with the live system, you are not testing. You are touching the data you are trying to protect.
The FAA: a copper-to-fiber cutover flooded the network
On Friday, 13 November, the FAA issued a nationwide ground stop after communication issues hit multiple Air Route Traffic Control Centers. The Verge reported that the stop went out at 3:44 p.m. ET and was lifted at 8:15 p.m. ET, a little over four hours later.
The next day, Transportation Secretary Sean Duffy gave the Department's account. At a remote FAA site, contractor L3Harris was replacing discontinued copper telecommunications lines with fiber, moving from TDM to IP. A router involved in that work "started flooding other routers": more than 1,000 connection attempts every four to five seconds. That disrupted communications with aircraft and radar feeds. Controllers and pilots then grounded more than 3,500 flights. Once the stop lifted, more than 8,000 flight operations resumed that night.
Duffy and FAA Administrator Bryan Bedford have described the underlying telecom as a 1980s-era TDM network. Officials said they do not believe the event was a cyber attack. They have not yet determined whether the fault was installer error or a faulty router.
The airspace shutdown was itself a gate: when the data going to controllers was inconsistent, traffic stopped. The expensive part was that the inconsistency showed up in operation, during a change that was supposed to be routine, rather than in a rehearsal that could refuse to proceed.
Starship Flight 15: the no-go fired
The contrast is Starship Flight 15.
On Friday, 13 November, Super Heavy lifted off from Starbase, Texas. SpaceX's flight recap says the booster's boostback burn ended early due to low fuel mass, with the root cause of that early cutoff still under investigation. During coast, the booster's guidance, navigation and control system triggered an automated abort, diverted to an offshore landing in the Gulf of Mexico, hovered, cut its engines, and the flight termination system triggered.
About 22.5 hours after liftoff, on Saturday, 14 November, the ship returned to the same pad and was caught by the tower for the first time.
SpaceX commentator Dan Huot corrected an earlier remark on the Saturday webcast: "It was not a GNC issue that caused us not to come back. GNC triggered that abort; it was doing what it was supposed to do." It had detected that the booster "was not in the place that it was supposed to be to proceed with a catch."
The catch is the new part. The gate is old. A no-go that fires automatically, against a written criterion, is how you keep a bad state from becoming a worse one. Most software migrations have no such gate. A rewrite looks done, someone switches traffic, and production is where you find out.
What a migration gate has to do
If you are moving a business-critical PHP application to Java 21 and Spring Boot, the question is the same one that GNC answered: are we where we need to be to proceed?
MigrateForge's answer is behavioural, not ceremonial:
- Record real user journeys on the existing PHP system.
- Replay them against both the legacy PHP and the new Spring Boot application.
- Compare HTTP responses, database writes and outgoing API calls.
- Keep cutover blocked until they match.
The output is standard Spring Boot. Every wave ships an evidence report. The work is local-first, as above: code stays on the client's machines.
This is the product today for plain PHP and CodeIgniter 3. Laravel is next.
What the benchmarks actually show
These are benchmarks, not client projects.
- WA Blast Pro, my own production multi-tenant WhatsApp SaaS (plain PHP): waves 1–2, 572 fixtures, all matching.
- InvoicePlane v1.7.2 (open-source, CodeIgniter 3.4): waves 1–2, 286 fixtures, all matching.
In total: 4 waves, 858 fixtures, 100% parity, 0 write-effect diffs and 0 HIGH findings.
First-pass parity, before hand fixes, was 82%, with 9.7 hand fixes per 1,000 PHP lines. The gate held until the rest was closed.
We also test the checker, by planting known bugs. The self-test catch rate was 57.14% on WA Blast Pro wave 1 and 35.89% on InvoicePlane wave 1. That is not 100%, and it is why we publish it next to the parity numbers. A checker you have not tested is the Microsoft lesson in miniature.
Before release, verification caught a delete that would also have removed a client's invoices and payments, a page missing its login check, data visible across tenants, and a skipped cashback payout. It also found defects in the original PHP applications.
Full evidence is at migrateforge.com/proof.
A starting point
If you run a PHP estate and a Java cutover is on the horizon, the free migration report is ₹0: size, risks, an indicative wave plan and a price range, with no source code required. It is on migrateforge.com.
For a comparison of manual rewrites, AI coding agents and parity-gated replay, see the earlier piece: PHP to Java 21 Migration in 2026: Manual Rewrite vs AI Coding Agents vs Parity-Gated Replay.
