^{Operational practices: deployment, upgrades, and cloning}

Delivery velocity is up across the board. Upgrade cadence is converging on ServiceNow's twice-a-year schedule. Cloning, on the other hand, remains the most operationally disruptive routine on the platform, and the frequency of clone related downtime correlates almost perfectly with where a team sits on the governance maturity curve. Here is what the numbers actually look like.

Delivery is faster; the estate is bigger.

For ServiceNow platform owners, they know the estate they manage is a fleet of separate instances. 51% manage 4 to 10 instances, 13% manage 11 or more, and only 30% keep it to three or fewer. Most deploy weekly or more frequently, and bi-weekly has become the single most common cadence. The market is settling into smaller, more frequent releases, which makes a sprawling multi-environment footprint harder to govern by hand.

ServiceNow Environments Managed Today

New Feature Deployment Frequency, overall

Deploy features daily, double the 2025 rate (5%)

Deploy bi-weekly, now the single most common cadence

Of 10+ year customers manage 11+ instances (highest in sample)

11%

34%

27%

Instance upgrades: convergence toward the ServiceNow cycle

Respondents are nearly evenly split between upgrading twice a year (54%) and once a year (46%), and the pattern is monotonic across governance maturity: the more mature the program, the more likely the team is to align with ServiceNow's twice-annual release. Time-from-GA tells the same story from a different angle. Advanced organizations disproportionately land new family releases within 2 months, and none within 1 month. Speed alone is not the goal; controlled speed is.

Time from GA to production, overall and by governance maturity level

Cloning is where hours disappear.

Eight in ten customers clone once per quarter or less, which looks controlled on the surface. Talk to the platform team about what actually happens during a clone, and a different picture shows up. Cadence varies sharply by governance maturity, and the cohort cloning the least is not the most mature one. It is the least mature one.

Half of Ad-hoc organizations clone just once a year, compared with only 13% of Advanced organizations. Advanced teams spread their cadence across the calendar, with a quarter cloning monthly. Less-mature teams cluster at the annual end. As programs mature, cloning becomes a routine operational lever rather than a once-a-year reset.

Cloning cadence tracks governance confidence. Advanced teams clone when they want to, not when they have to. Ad-hoc teams let non-production drift all year, then reset with the annual clone. Cadence is a signal, not a strategy.

The maturity-cadence shift

WHY THIS MATTERS

Clone-down frequency, overall and by governance maturity level

50%

13%

of Ad-hoc orgs clone just once a year

of Advanced orgs clone just once a year

Developer hours lost to the clone.

Here is the part platform teams know and executives often do not: clone preparation and post-clone recovery cancel out, neatly and symmetrically. About half of organizations lose 0-5 hours in each phase. A third lose 6-20. Roughly one in six lose 21 hours or more. Those hours and the disruption scale together, and once you cross the 21-hour line, the wheels come off the sprint.

Prep and recommit move together. The clone event is a two-sided cost.

Developer hours lost, clone preparation (left) and post-clone recommit (right)

Clone-caused development downtime frequency, overall and by governance maturity level

Hours before, Hours after

10%

71%

of teams at 0-5 prep hours say clones frequently disrupt delivery

of teams at 21+ prep hours say clones frequently disrupt delivery