Upgrades that keep slipping. Every one of them is small.
Framework, runtime and library moves, spread thinly across many repositories. Each individual change is well understood. The volume, the consistency and the review load are the problem — and work of this shape is deferrable in every planning round, which is exactly why it is still here.
Reign Factory is in beta and being productized. It is not generally available; beta access is agreed with us and scoped in writing before anything runs.
Nothing here is hard. That is what makes it permanent.
An upgrade backlog is not a knowledge problem and it is rarely a priority failure. It is a class of work that is individually small, collectively enormous, and always safe to move to the next quarter.
There is no quarter in which upgrading a framework across forty repositories beats the commitment the business already announced. The decision is right each time it is taken and wrong in aggregate, which is the definition of a structural problem rather than a management one.
AskWhen was the last time an upgrade won a planning round against a dated commitment?
And it is a quarter of work that produces no new capability, which is why it is hard to staff and harder to defend. The unit that matters is not the change; it is the change multiplied by the estate, and then multiplied again by review.
AskHow many repositories would a single framework move actually touch?
Teams that defer upgrades are not being lazy. They are pricing in a real and measured breakage risk against a benefit that is frequently theoretical — and most of the queue is not reachable in their code anyway. Any page that treats deferral as negligence is arguing with people who have been burned.
AskWhat broke last time, and how long did it take to find?
The gap is not stable. Each deferral makes the next move larger, because a jump across two major versions is a different piece of work from a jump across one — and support windows close on their own schedule regardless.
AskWhich of your services are already on a runtime nobody upstream is patching?
If iTmethods operates your GitLab, Bitbucket, Jira or Camunda under Reign Ops, keeping that instance current is part of that service. It is scheduled through your change process, it is not a Factory engagement, and there is nothing extra to buy. Reign Ops even publishes upgrade currency — the share of operated instances held within a stated number of releases of current — as the measure it is willing to be held to.
This page is the other one: the framework, runtime and library versions your own applications are pinned to, inside your own repositories. Reign Ops upgrades the instance. Reign Factory upgrades what runs on it.
The drift is telemetry, not an opinion.
These are the numbers that describe the shape of an upgrade backlog. Every one is somebody else’s, named with its date and its population. Two of them cut against us, and they are on the page for that reason.
| What is measured | Whose figure, and when | Why it is on this page |
|---|---|---|
| The median dependency is 278 days behind its latest major version — 63 days worse than the year before. Java: 492 days. Services deployed less than monthly are 70% more outdated than those deployed more often. | Datadog, State of DevSecOps 2026, 26 February 2026. Thousands of applications across customer cloud environments. | The last clause is the useful one. Drift tracks deployment cadence, not team diligence — which means it is a delivery-path problem and it responds to a delivery path. |
| For 95% of downloads of a known-vulnerable component, a fixed version already existed. Four Java components alone accounted for 1.8 billion avoidable vulnerable downloads in 2025. | Sonatype, State of the Software Supply Chain 2026, 28 January 2026. Registry telemetry across 9.8 trillion downloads; 1,718 open-source CVE records. | “The answer is already known” is the premise of this whole page. This is the closest thing to a measurement of it. |
| 75% of dependency-vulnerability patches cause breakages. 24% require a major version upgrade. 90.5% of open-source vulnerabilities are not reachable at function level. | Endor Labs, Dependency Management Report, 12 September 2024. Java, Python, Rust, Go, C#, .NET, Kotlin and Scala ecosystems. | This is the row that argues against us. It says most of the queue is noise and most of the signal is expensive, and any honest version of this page has to carry it. |
| Between 5% and 15% of components in enterprise dependency graphs are already end-of-life. 10% of services globally run an end-of-life language or runtime version. | Sonatype, January 2026 (3,000+ enterprise SBOMs) and Datadog, February 2026. | End-of-life is the part of the backlog with no upstream fix coming. It is the population where waiting stops being a trade-off and becomes a decision. |
The Endor Labs figures are from 2024 and we have not found a 2025 or 2026 restatement of them; their November 2025 edition covers different ground. Where a figure is older than the others on this page we say so rather than letting the newest date on the page cover all of it. None of these is an iTmethods measurement.
One move, agreed once, and then repeated.
The same delivery path as remediation, pointed at a different population. What makes it suit upgrades is that the decision is taken once and the repetition is what is expensive — and the repetition is the part a path can absorb.
The only figures we publish about this way of working are our own. Across eight of our own repositories, 326 merge requests were merged. Median time from merge request open to merge was 19 hours. 326 of 326 merged with a recorded approval from a named iTmethods engineer. Measured on our own engineering, 11 July to 11 August 2026, GitLab, release commits excluded, internal environment only, two-person team. The method is written up in full at what we measured. It is not a customer result, and we do not present it as one.
A version move is a governed change like every other change.
Nothing about this population gets a separate route. The model calls made on the way to each merge request pass Reign Gateway and are recorded there; the merge request itself enters the pipeline every other commit enters. The reason to say so plainly is that a bulk change across forty repositories is exactly the shape of work an organization is tempted to fast-track.
Where this sits against the rest of Reign.
Four motions at four different stages of maturity. We state the stage every time, because the stage matters more than the description.
A single-tenant dedicated instance, in your own AWS or Azure account or in infrastructure iTmethods operates. Both are available today; Google Cloud is planned for 2027. Air-gapped and sovereign are in development. There is no multi-tenant or shared option at any tier. Deployment options →
Who holds what, across the whole set.
Written down before the first repository is touched, because a move across an estate is the case where an unwritten boundary costs the most.
| Who | What they hold |
|---|---|
| Reign Factory, automated | Attempt the move in each eligible repository. Open one merge request per repository, sized for review. Run the checks that repository already runs and report what they said. Carry the record of what was tried and under which policy. |
| Customer authored | Which move, and which repositories are in and out of scope. The eligibility rules. Your branch, review and release policy, unchanged. Every merge decision. Whether the set is attempted in one pass or in waves. |
| Operating partner engagement | The named engineer embedded for the move. The repositories that came back declined, and why. The judgement about whether the remaining set is worth attempting at all. |
The questions that arrive every time.
We already pay you to run GitLab. Is upgrading not included?
Can we buy this today?
What if the upgrade breaks something?
Do you do end-of-life runtime moves as well as library bumps?
Will this reduce our vulnerability count?
How do you keep forty merge requests consistent?
Which deployment shapes can we have?
Bring us the move that keeps slipping.
Name the version move and roughly how many repositories it touches. We will tell you which part of the set we think this path suits, which part we would leave alone, and why.