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 today Discuss your upgrade priorities See what reaches review →

Delivered through Reign Factory. Keeping an operated instance current stays with Reign Ops.

One move, many repositories one policy

Decided onceThe move, and the rules that make a repository eligible

repositoryFive requests, each one smallOne review policy for all five

out of scopeNot attempted

The eligibility rules decide the scope. Nothing outside them is attempted.

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 prioritization 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

In 2024, Endor Labs found three quarters of dependency-vulnerability patches broke 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.

Reign Ops keeps the platform you run current. Reign Factory moves the versions your own applications are pinned to. Upgrading an instance iTmethods operates is part of Reign Ops, not a Factory engagement.

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 Exceptions are recorded against the same rules for every repository, so the last repository is handled like the first. Not a queue

04 One pull 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 pull requests, forty decisions, all of them yours. Reign Factory does not merge and does not release. Named approver

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 pull request are recorded there; the pull 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 pull 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. Beyond SOC 2 Type II for Reign Ops, no other certification or accreditation is claimed. 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	Attempt the move in each eligible repository. Open one pull 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.
Your team	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.
iTmethods engineers	The named engineer embedded for the move. The repositories that came back declined, and why. The judgment about whether the remaining set is worth attempting at all.

FAQ

Questions buyers ask

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. 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?

Yes. Reign Factory is available today. 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?

In some repositories it will. The figures on this page say so and we do not dispute them. What the path is designed to do is make a failure arrive as a pull request your tests rejected, in front of your reviewer, not 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 pull 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 pull 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. Deployment options →

AWS Advanced Tier Services Partner AWS Validated Managed Service Provider SOC 2 Type II on Reign Ops

Two decades operating critical infrastructure for regulated enterprises.

Next step

Start with the versions that carry the most risk.

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 →