Two supported families is the entire policy

ServiceNow supports two release families at a time, and that one rule shapes your upgrade calendar more than your roadmap does. The published upgrade policy says the company generally releases two new release families per year, and that you will need to upgrade approximately once per year to stay on a supported release family. The boundary is stated plainly: the current policy of ServiceNow is to support the most recent and the immediately previous release families.

Australia is the current family and Zurich is the one behind it. If your instance sits on Yokohama or earlier, you are outside the boundary. Patches and hotfixes are produced only for supported families, so defects you hit stop getting fixed on your version. And when an instance is left on an unsupported family, ServiceNow schedules the upgrade for it.

That last point is why the policy belongs in annual planning. An upgrade you schedule is a project with a test plan, a clone, named approvers and a rollback conversation. An upgrade somebody else schedules is a date you find out about. Only one of those leaves room for your change approval process to do any work.

The patch rhythm is the part teams miss

Australia's own version history shows the real cadence. The feature release carries the date 2026/03/12. Patch 1 followed on 2026/04/03, Patch 2 on 2026/05/05, Patch 3 on 2026/06/16, Patch 4 on 2026/07/09, Patch 5 on 2026/08/07 and Patch 6 on 2026/09/10. Alongside those, the same page lists weekly hotfixes dated 2026/09/10 and 2026/09/17. Those dates held identically across three separate readings of the page, which was itself updated on September 17, 2026.

Roughly one patch a month with hotfixes arriving weekly is a different operating rhythm from two family upgrades a year. A team that plans only for the family upgrade absorbs the rest unplanned, usually through a support case where the fix lives in a patch nobody applied. Patch decisions deserve the triage you would give any other backlog of fixes, which is the argument behind deciding what gets patched first when every item claims priority.

One warning about reading that table. The availability column, the one telling you whether a patch shows as available, available by request, unavailable or early availability, did not read the same way across repeated visits during our research. So we will not state the availability of any Australia patch here. The dates hold. The flags change week to week and have to be read live.

Store applications upgrade without asking you

ServiceNow Store applications move on the same cycle, which catches teams that scope an upgrade around the platform alone. ServiceNow's documentation puts it plainly: new versions for a ServiceNow Store app can be defined in patch and family releases. Applications sitting below a defined minimum version or minimum hotfix version are upgraded automatically.

The change control question nobody owns sits right there. An application whose version falls below the minimum moves during the platform upgrade with no separate request, no separate approval and no separate test plan. If it backs a catalog item your service desk depends on, the functional change arrives at the same moment as the platform change, and every odd behaviour afterwards gets blamed on the platform.

The fix is unglamorous. Inventory your installed Store applications with their current versions before the upgrade, flag the ones that will move, and give each a functional owner who tests it in the non production instance. Teams that already run a build or buy conversation for every Store purchase usually have most of that list already.

The documentation is harder to pin down than it should be

ServiceNow's documentation is genuinely harder to read for a definitive answer than what the other large vendors in this series publish. The upgrade policy document would not load directly during our research, returning an access error. Its text was confirmed through two independent retrievals instead. The policy is quotable and carries no revision date. You can cite it to a risk committee. You cannot tell them when it last changed.

The reference pages also move under you. The unversioned documentation path currently serves Australia content and was updated on September 10, 2026, listing upgrade paths from Zurich, Yokohama and Xanadu. The available versions page was updated a week later. Both are live surfaces, so a screenshot pasted into an upgrade plan in March will not describe what a reader sees in September.

The knowledge base articles covering upgrade rescheduling sit behind customer authentication, so we could not read them and will not describe what they say. If rescheduling matters to your planning, that is a question for your account team. Having a method for reading change notes matters more here than on a platform whose pages sit still between visits.

The naming convention changed and nobody published a rule

Release families used to be named after cities in alphabetical order, Aspen through Zurich, a convention a ServiceNow community article from 2022 sets out. After Zurich the names became countries. Australia is the current family and Brazil is the next one.

What does not exist anywhere we could find is a published statement that country names are the convention. The evidence sits only in the release names in first party documentation. ServiceNow has not announced a naming policy, so anyone predicting the next several families off the alphabet is guessing. Community posts name later families with confidence, and those names are community sourced, so we are not repeating them.

This matters for planning, not trivia. If your multi year roadmap carries placeholder family names, mark them as placeholders in the document. Naming the family you expect to be running in 2028 gives a steering committee confidence in a schedule nobody has published.

Brazil is coming without release notes

Brazil is next, and as of September 22, 2026 its versioned release notes path returns a not found error. No Brazil release notes exist publicly on ServiceNow's documentation site. Nothing first party describes what the release contains or when it arrives.

A post in the ServiceNow employee community mentions a September 24 early availability for Brazil. That post carries only a relative timestamp and no calendar date, so it cannot be cited here as a dated fact. Community activity points at imminent early availability while first party documentation does not yet exist. Both are true at once, and the gap is normal this far into a cycle.

Do not build an early adopter plan around a date you read on a blog. Watch the versioned documentation path for Brazil, because the day release notes appear there is the day the content becomes something you can plan against. Until then, the Australia patch stream is the only thing changing your instance.

Open Now Support and check three things

All three live in Now Support rather than in documentation. First, which release family each of your instances is actually on today, production and every non production instance separately, because the sub production instances drift. That check belongs on your week two list after a go live as well. If any instance sits two families back, an upgrade is already coming whether or not anyone has told you the date.

Second, the upgrade schedule itself. ServiceNow's planning checklist tells customers to schedule the upgrade in Now Support, and separately to schedule the non production upgrade in Now Support and verify your upgrade configurations. The second is the one people skip. Skipping it is how a sub production instance ends up on a different family from the production instance it is meant to rehearse.

Third, change freeze windows. The same checklist tells you to check change freeze windows impacting the timing for environment clones or upgrades, and those windows are set by your business, not by ServiceNow. A finance close or a filing deadline can collide with a date ServiceNow picked. Put the clone date, the non production upgrade date and the production upgrade date on the same calendar as your freezes before the next family lands. Then the conversation with ServiceNow is about moving a date you chose, instead of reacting to one you did not.