Microsoft Patents a System That Runs a Secret Copy of Your Job to Test New Software
Every time Microsoft wants to update a cloud service, it risks breaking something for real customers. This patent describes a way to run a duplicate of your actual job against the new version, without you ever knowing, and without putting your real results at risk.
What Microsoft's shadow-job testing system actually does
Cloud services get updated constantly, and every update is a gamble. Before this kind of system, engineers had to test changes on fake or synthetic workloads that never quite matched what real customers actually sent in.
Microsoft's patent describes a process where, when you submit a job to one of its cloud services, the system secretly makes a copy of that request. Your original job runs normally on the current, stable version of the service. The copy, called a shadow job, gets routed to a second version of the service that's running experimental or updated software. Both jobs use your real data, but only your original job's results are ever delivered to you.
Afterward, Microsoft collects performance and output data from both runs and compares them. That comparison tells engineers whether the new version behaves correctly and performs better, all without exposing you to any risk from the experiment.
… create a copy of the customer job request as a shadow job request for a shadow job; provide the customer job request to a first service having a first configuration to enable the first service to execute the customer job based on first data of the customer to generate first results …
Translation: The system duplicates a user task so it can run a hidden twin version alongside the real one.
How the flighting service picks jobs and compares outcomes
When a job request arrives (think: a batch data processing task, a model inference call, or any scheduled compute workload), the system immediately creates an exact copy of that request before routing it anywhere.
The original request goes to a first service running the current production configuration. The copy goes to a flighting service, which is a routing layer that checks whether this particular job meets certain criteria before deciding what to do with it. Flighting is an industry term for gradually rolling out a change to a subset of traffic, the way airlines test new boarding procedures on select flights.
If the shadow job passes the flighting criteria (which could be based on job type, size, customer tier, or other factors), it gets forwarded to a second service running a different configuration, such as a newer software version or a different hardware setup. Both jobs run using the customer's actual input data.
- The customer receives results only from the first, stable service.
- The second service produces its own results independently.
- Execution data from both runs is collected and stored for comparison and analysis.
The key design point is that the shadow job is invisible to the customer: it runs in parallel, costs the customer nothing extra, and never overwrites the customer's real output.
A received customer job request for a customer job is copied to create a shadow job request for a shadow job. The customer job request is provided to a first service having a first configuration, and the shadow job request is provided to a flighting service.
Translation: Incoming work tasks are automatically cloned and routed to a testing environment behind the scenes.
What this means for Microsoft cloud customers and reliability
For Microsoft, this is a way to gather real-world performance data on new software configurations without staging risky public rollouts. Instead of relying on synthetic benchmarks that may not reflect actual usage, engineers get a direct, apples-to-apples comparison using genuine customer workloads.
For cloud customers, the practical effect is safer, more reliable updates over time. If the shadow results consistently match or beat the production results, Microsoft can roll out the new configuration with much higher confidence. If they diverge, engineers catch the problem before anyone's actual workflow is affected. The tradeoff is that Microsoft is running your job twice, which has a real infrastructure cost that customers don't pay but Microsoft absorbs.
Microsoft's 495th filing in our Microsoft coverage since May adds to a run that includes compressing AI math tables and camera-based AI answers.
Running every flagged job twice, on two different versions of a service simultaneously, costs real money. Microsoft is betting that the engineering confidence gained from live comparison data justifies doubling the computing work for a selected slice of jobs, and at the scale of a major cloud platform, that trade reads as worth it.
The weak point is the filter that decides which jobs get duplicated for testing. Too narrow, and the sample misses the unusual cases that tend to cause failures in the real world. Too broad, and the costs climb fast enough to undermine the whole approach.
The deeper question is whether the filtering logic stays well-calibrated over time as customer workloads change. A filter that worked well at launch can become stale, producing test results that look representative but aren't.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
6 drawing sheets from US 2026/0300143 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →
Be the first to weigh in