ServiceNow Brazil upgrade: paths, 7 stages and rollback

The Brazil release roundup covered what changes in Brazil. This article is about deciding when, and in what order, to upgrade your own instances.

The short version: Brazil is out in Early Availability for EA customers, but it is not part of the patching program, and General Availability (GA) is planned for November. That timing tends to collide with year-end work, so the key planning decision is whether to get your validation done early. Unless noted otherwise, what follows comes from reading the release notes on ServiceNow Docs in the original. The GA timing estimate draws on NowBen, and the year-end discussion on a ServiceNow Community thread.

Reading the dates#

Item	Details
EA (Early Availability)	From September 24, 2026. For EA customers
GA (General Availability)	Planned for November 2026
Covered by the Q3 2026 patching program	Australia Patch 5a, Zurich Patch 12, Yokohama Patch 13 Hotfix 5a W39. Brazil is not included

ServiceNow’s official documentation says Brazil was published as a feature release on September 24 and is “Available to Early Availability customers”. A version can be in one of three states:

• Available: any user can upgrade to it. It appears in the upgrade management dashboard on the instance
• Available by request: you must contact Customer Service and Support and get approval
• Unavailable: not available

Versions in the patching program are available right away, and you do not need to request version entitlement. Brazil is not in the program, so for now only EA customers can upgrade to it.

The official documentation I read does not give a GA date. NowBen, an information site, lists EA as mid-September and GA as November. According to NowBen, EA under the Early Release Program starts at least 45 days before GA. Brazil’s EA started on September 24, so by that arithmetic GA falls on or after November 8.

The year-end collision#

In January 2026, a user in a ServiceNow Community thread pointed out that a November GA for Brazil would push upgrades into December. Year-end is hard to schedule around because of holidays and fiscal closing work. A ServiceNow employee replied that the two major releases per year are not changing, and acknowledged that their own earlier reply had not clearly called out that this cycle runs later than usual.

The official checklist also includes an item to check, before upgrading, for change freeze periods (such as quarter-end) that affect when you can clone or upgrade. Confirm your year-end freeze first and decide whether production can go in December or has to wait until the new year. From there you can work backward to a validation schedule.

Upgrade paths#

The Brazil release notes point to release notes for upgrading from Australia, Zurich and Yokohama. The official documentation says you can upgrade directly to the latest family. If you are skipping versions, it asks you to read the release notes for each version between your current one and the target.

The release notes include two tools:

• Personalized PRB release notes: generates a list of the problems fixed between your current version and the target version
• Combined product release notes for cross-family upgrades: shows, per product, all changes from one family to another on a single page

Check support end dates in the Now Support Knowledge Base. The End-of-Life upgrade program notice (KB2177115) and your instance’s status are good places to start.

The official 7 stages#

The official process has seven stages, and ServiceNow recommends following them in order.

Stage	What to do
1	Read the release notes and make a plan
2	Prepare to upgrade the development instance. Clone production to development
3	Review upgrade settings and schedule the development instance upgrade in Now Support
4	Upgrade and validate the development instance
5	Upgrade and validate the other non-production instances, such as test
6	Prepare for the production upgrade
7	Upgrade production

The checklist spells out the specific items:

• Stage 2: when cloning production to development, if the instances are the same size, include production’s audit logs and attachments by clearing the exclusion options. The point is to test in an environment close to production
• Stage 3: check how often the “Check distribution for possible upgrade” scheduled job runs, and schedule the upgrade in Now Support. Request version entitlement if needed
• Stage 4: track progress in Upgrade Monitor and process skipped records once it finishes. Run smoke tests on the development instance before and after the upgrade
• Stage 5: reapply the plugins, custom applications, post-upgrade fix scripts and update sets you installed on the development instance
• Stage 6: get IT and business sign-off, arrange support for upgrade day, write an implementation plan, get the change record approved, notify users, and record pre-upgrade performance
• Stage 7: schedule the upgrade, monitor it, apply update sets and fix scripts, and verify with user acceptance testing (UAT)

Brazil upgrades and updates are said to finish considerably faster than in previous releases. The official documentation warns not to read a short run as a failure on its own, and to confirm the result with testing.

How testing is sequenced#

ServiceNow asks you to upgrade development, then test, then production. If you do not have exactly three instances, start with the one furthest from production.

Instance	Required testing
Development	Smoke tests
Test	Automated Test Framework (ATF) quick start tests and product-specific test suites. UAT too, if you have time
Production	UAT only. Use ATF on non-production instances

Rollback#

ServiceNow has no rollback that works for every upgrade. You can roll back only updates within the same family (patch to patch, patch to hotfix, and so on). The window is 10 days by default and can be changed with glide.rollback.expiration_days. To request a rollback, contact Customer Service and Support.

Restoring production from a backup is a last resort when nothing else works, because it means downtime and data loss. ServiceNow does not take on-demand backups. Instances are backed up automatically every day during off-peak hours that ServiceNow chooses. Cross-family upgrades cannot be rolled back, so problems have to be found in testing beforehand.

Changes to catch in the release notes first#

“Changes to Brazil features and products” lists items whose behavior may change on upgrade. In some cases, newly created instances get the new default while upgraded instances keep the old behavior.

• Strict ACL denial: denies access when none of the roles an ACL references exist on the instance. Enabled by default on new instances. On upgraded instances, enable it with glide.security.acl_with_invalid_roles_strict_deny
• Auto-closing resolved incidents: counts business days instead of calendar days. Set the number of days with glide.ui.autoclose.time. Setting it to 0 disables auto-close
• Incident Management roles: removing the inherited itil role applies only to newly created instances (zBoot instances). Upgraded instances keep inheriting the itil role
• Service Graph Workspace: deprecated as of this release. Its features are being merged into CMDB Workspace
• AWS Discovery: determining whether a data center region is active or passive moves from the Config API to the Resource Explorer API

These are only part of the list. Per-product upgrade tasks are collected in “Pre- and post-upgrade tasks for various products”, organized by product and family. Read only the sections for products you use, and check which family you are upgrading from.

Prep you can start today#

1. Confirm your instances’ family and patch level. Check support end dates in Now Support
2. List your change freeze periods and decide when the production upgrade can happen
3. Use a Brazil PDI to check new features and the impact on your existing customizations
4. Generate Personalized PRB release notes and review the fixes that matter to you
5. Clone production to a development instance and measure how long the upgrade takes with real data
6. Review your ATF test coverage and add anything it misses to the UAT steps
7. Check in Now Support whether you need to request version entitlement

Whether to wait for GA or go early with EA depends on your change freeze periods and how much time you can spend on validation. Even if you upgrade during EA, the order of the stages stays the same: validate on a development instance first.