SolutionsUpgrades

Move the versions you have already chosen across every eligible repository.

Turn one approved framework, runtime or library move into a tested change for every eligible repository while product teams stay on dated work. Your reviewers decide what merges and releases.

Available · Beta Release Discuss your upgrade priorities See what reaches review →

Reign Ops · Available today. Reign Factory · Available · Beta Release.

One move, many repositories one policy

The version move is agreed once. The repetition is what the path is for, and the repository nobody agreed to touch is not touched.

The cost

Why upgrade work keeps slipping.

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.

01It loses every prioritisation round it enters

A version move competes against work with a date on it, and loses, correctly, every time.

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. That is a structural problem.

02The volume is the work, not the change

One version bump is quick. The same bump across dozens of repositories, reviewed consistently, becomes a quarter of an engineer's time.

And it is a quarter of work that produces no new capability, which is why it is hard to staff and harder to defend.

03Deferring is often the rational call

Three quarters of dependency-vulnerability patches break something.

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.

04The distance compounds while you wait

The median dependency is now 278 days behind its latest major version, and that is 63 days worse than a year ago.

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.

The breakage and reachability figures are Endor Labs, Dependency Management Report, 12 September 2024, measured across the Java, Python, Rust, Go, C#, .NET, Kotlin and Scala ecosystems: 75% of dependency-vulnerability patches cause breakages, 24% require a major version upgrade, and 90.5% of open-source vulnerabilities are not reachable at function level. We have not found a 2025 or 2026 restatement of these figures; the Endor Labs November 2025 edition covers different ground. The drift figure is Datadog, State of DevSecOps 2026, 26 February 2026, measured on thousands of applications across customer cloud environments. None of these figures is an iTmethods measurement.

Keep both the operated instance and the code that runs on it current.

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 covers the other half: 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.

A managed platform upgrade produces a completed change record with its validation result and open items. An application-code upgrade produces a tested merge request in each repository, carrying the target version, check results, differences and open issues.

Benefits

What you gain.

Reduce lifecycle and security exposure

Unsupported platforms, dependencies approaching end of support and versions affected by a relevant vulnerability move first, toward target versions you approve.

Make upgrades planned and repeatable

Every repository in the population reaches review against the same approved target, checks and rollback conditions.

Preserve product-delivery capacity

Product teams keep dated work moving while eligible upgrades advance in parallel. They step in where product knowledge or a design decision is required.

Keep progress and remaining exposure visible

You see what has been upgraded, what is in review, what failed a required check and what is still on an older version, with the reason and the owner on each.

How the work runs

Repeat the move without lowering the review bar.

Once you approve the move and population, each repository follows the same review path. Upgrades run on the same delivery path as remediation and delivery the business is waiting on; only the work changes. The path suits upgrades because the move is decided once and the cost is in the repetition — and repetition is what the path absorbs.

01 Agree the move One named version move: this framework, this runtime, this library, from here to there. Not a program, one move. In writing

02 Agree what is eligible Which repositories are in scope, which are excluded, and what makes a repository ineligible to be attempted at all. Yours to set

03 Keep exceptions consistent Embedded for the move, running it with your team and staying with it across the estate rather than handing it on. Not a queue

04 One merge request per repository Sized for review, scoped to one repository, with the reason for the change stated on it. Consistency across the set is the point. Your repo

05 Your tests are the test The checks that already run on that repository run on the change and report what they found. Nothing new gates the merge. No auto-merge

06 What breaks is handed back A repository where the move needs a design decision comes back declined, with what was learned, rather than as a change nobody wants to unpick. Refusal recorded

07 Your reviewer decides, every time Forty merge requests, forty decisions, all of them yours. Reign Factory does not merge and does not release. Named approver

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.

Where the record fits

A version move is a governed change like every other change.

Nothing about this population gets a separate route. Model calls sent through Reign Gateway on the way to each merge request are recorded there; the merge request itself enters the pipeline every other commit enters. A bulk change across forty repositories is exactly the shape of work an organization is tempted to fast-track.

What the record carries

For each call: the identity that made it, the policy that applied, the decision taken, the model that answered, and the time. Joined to the merge request it produced — so forty changes made the same way have forty records that say so, and a reviewer asked about the thirty-first does not have to reconstruct it.

The part worth being precise about. This is a record of how a change was produced. It is not a judgment that the upgrade is safe, and it does not replace your tests or your review. iTmethods makes no compliance, certification or accreditation claim under any framework. How the boundary works → · Regulatory context →

Shared responsibility

Your approval path still governs every change.

You retain eligibility, review, merge and release decisions. Factory attempts only the approved population and records exceptions.

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.

FAQ

We already pay you to run GitLab. Is upgrading not included?

For the instance, yes, and there is nothing extra to buy. Keeping an operated platform current is part of Reign Ops, scheduled through your change process, and it is one of the few things this site publishes a measure for. This page is about a different population: the framework, runtime and library versions inside your own repositories, which nobody operates on your behalf because they are your applications. Reign Ops upgrades the instance; Reign Factory upgrades what runs on it. A customer can buy either without the other.

Can we buy this today?

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. For an upgrade population that means the move, the repository list and the eligibility rules are agreed before anything is attempted, and either side can stop.

What if the upgrade breaks something?

It will, in some repositories — the published figures on that are on this page and we are not going to argue with them. What the path is designed to do is make the breakage arrive as a merge request your tests failed, in front of your reviewer, rather than as a merged change in production. A repository where the move needs a design decision comes back declined rather than forced.

Do you do end-of-life runtime moves as well as library bumps?

The path does not distinguish between them; the scoping does. A library bump across forty repositories and a runtime move on four are different amounts of work per unit and different amounts of risk per unit, and we would want to scope them separately even if they are agreed in the same conversation.

Will this reduce our vulnerability count?

It might, and we will not put a number on it. Most open-source vulnerabilities are not reachable at function level, so a count that falls is not automatically a risk that falls. What the path produces is proposed changes with their records attached; what they are worth is your measure.

How do you keep forty merge requests consistent?

One move, one set of rules, one named engineer across the whole set. That is the entire argument for doing it as one population rather than forty tickets. Where a repository needs to differ, the difference is visible on its merge request instead of being invisible in somebody’s branch.

Which deployment shapes can we have?

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 deployment are supported. There is no multi-tenant or shared option at any tier. Deployment options states the status of each.

AWS Advanced Tier Services Partner SOC 2 Type II on Reign Ops

AWS Advanced Tier Services Partner and Validated Managed Service Provider. Twenty-one years operating regulated engineering environments.

Next step

Start with the versions carrying the greatest operational or security exposure.

Tell us which upgrade keeps slipping and what makes it a priority. We will use the first conversation to identify the applicable path and a useful starting population.

Discuss your upgrade priorities See where Reign Factory fits →