Almost every new Workday feature arrives switched off
Workday ships new functionality on two separate clocks, and almost none of it turns itself on. The Release Best Practices guide says so directly: "Workday delivers new features in two ways: weekly service updates and feature releases." Weekly service updates are "Disabled by default, so your team does not need to test every week." Feature releases are "Mostly disabled by default, so your team can plan to test and enable later."
That changes what a release threatens. The Saturday itself rarely breaks anything, because the code that would break something sits behind a switch nobody has flipped. The failure mode looks different. A manager asks in November why the absence change demoed in March never appeared, and the answer turns out to be that nobody was assigned the decision to enable it.
So the planning job splits in two. One half is regression testing, which matters less than upgrade-weekend folklore suggests. The other half is a standing enablement list: which new features your team wants, who owns switching each one on, and which release it landed in. That list decides whether the optional half of 2026R2 gets acted on or quietly expires.
Weekly updates and feature releases do different jobs
Weekly service updates carry "Software and regulatory fixes" and "Small enhancements", in the words of the same guide. The regulatory half is what payroll teams watch, because statutory changes arrive on that clock rather than waiting for March. The small enhancements accumulate unnoticed, since they also arrive disabled and nobody has to look at them.
The cadence has a documented conflict. Workday's administration guide says weekly updates land on Wednesday and Friday afternoons Pacific time. Workday's blog says product updates are released every Friday. We follow the administration guide, since it is the operational document, and we would raise the difference with anyone building a change freeze around one weekday.
Sitting alongside both is the maintenance calendar. The same guide states that "Workday does planned maintenance: four hours each week, month, and quarter." That is separate from any feature delivery and belongs beside your integration schedules, because a batch job that assumes continuous availability will find those hours eventually.
The five weeks before a release are your entire test budget
The convention is the calendar year plus Release 1 or Release 2, shortened to that year's R1 or R2. Workday's administration guide describes a yearly R1 release in March and a yearly R2 release in September. Ahead of each, Workday says "Your team can test releases during the five-week release preparation window", and separately that "we deliver new features and functionality to preview tenants approximately five weeks in advance of the feature release".
Five weeks is both the constraint and the advantage. The length is known in advance every time, so the test plan can be built once and edited twice a year rather than rewritten from scratch. A team that burns the first fortnight deciding who tests what has cut its own budget by forty percent before anyone touches a business process.
At the end of the window Workday delivers the feature release to all tenant types on the same date. Preview buys early access, not an extension. Anything untested by then goes to Production with everything else, still mostly switched off, and joins the pile of decisions nobody made. If custom reporting sits in scope, read the guide to custom report performance before the window opens.
Sandbox and Sandbox Preview answer different questions
Workday's tenants datasheet draws the line clearly. A Sandbox tenant "is refreshed weekly as a copy of Production", while a Sandbox Preview tenant refreshes twice per year. Those two sentences decide which tenant a given test belongs in, and teams get it wrong in both directions.
Sandbox tracks what is live now, so it answers questions about today. Whether a business process still routes correctly after last week's configuration change. Whether an integration picks up a field somebody added on Tuesday. What Sandbox does not hold is the next release's code, so a clean result there tells you nothing about R2.
Sandbox Preview carries the new code during the preparation window, which makes it the only tenant where feature release testing honestly happens. The cost is stale data, sometimes months stale, because it refreshes twice a year. A compensation test there runs against a population predating half your recent hires, the same kind of drift described in comp cycle configuration drift. Teams that ignore the distinction reach confident wrong conclusions.
The second Saturday rule did not survive a check
A lot of Workday planning folklore says feature releases land on the second Saturday of March and September. Workday's own blog does say that. The blog carries no publication date and describes a change made in 2020, while 2026R2 went live on Saturday, September 19, 2026, the third Saturday of the month. The rule and the date do not agree, so we are not repeating the rule as current.
Workday's Release Center reference identifies releases by ISO week number instead of by weekday. The wording takes the form that a given year's R1 label applies to any feature delivering to production tenants in a stated week number. Week numbers and second Saturdays do not always coincide, which explains the discrepancy and argues for dropping the weekday rule from planning decks.
Two sourcing caveats belong on the record. The September 19 date for 2026R2 is confirmed on a customer institution's public page, not on any Workday-owned page we could reach. The date of 2026R1 is unconfirmed, so we are not stating it. Workday has published no date for 2027R1, and while March 2027 follows from the annual pattern, that is inference rather than something to write into a freeze calendar.
Workday is not hiding any of this. The practical problem is that a date remembered from a partner blog makes a weak basis for a payroll freeze. Take your dates from your own tenant and from the Release Center, reconfirm them every cycle, and write the source beside the date.
Release notes land before the change, behind a login
Notes are published to the Release Center before service updates go out, on a Wednesday and Friday evening Pacific schedule. Coming Soon notes appear one to six weeks before a feature reaches Preview or Production. Feature notes appear one week before Preview and again at Production.
We could not inspect the Release Center or the What's New in Workday report while researching this, because both sit behind customer authentication. That matters more for you than for us. Anything a trade publication writes about Workday release content is a secondhand account of material you can open directly and we cannot, which argues for one named person owning the weekly read, along the lines of reading change notes properly.
No Workday source states a deferral deadline. The official wording is that your team can plan to test and enable later. There is no published limit, no expiry, and no date at which an optional feature turns mandatory, and anyone who says otherwise should be asked to produce the page.
Put the next preparation window on the calendar now
With 2026R2 in Production, the useful work this month is the enablement list rather than another regression pass. Pull every feature delivered in the last two releases that is still switched off, put a name against each, and give each name a date to decide by. A few of those items will turn out to be why somebody is still doing something by hand.
Then build the test plan before the next preparation window opens instead of inside it. Five weeks is known in advance, so the plan can name the business processes, the integrations, and the reports that get checked, plus the people checking them. For payroll, decide now whether the window includes a parallel run and what it would prove.
Fix the date habit at the same time. Put the source beside every release date in your plan, and verify each one against your own tenant every cycle rather than against memory. The first administrator who does that will find at least one date nobody can trace, and finding it in September beats finding it in March.
