Your release goes in on Saturday. The go/no-go meeting is the day before.
The pack is green from top to bottom. And everyone in the room expects one answer, because stopping now feels more expensive than the known bugs.
So test the pack against three questions it will face after go-live. What did each sign-off cover? Who accepted each open risk? And if it goes wrong, how do we get back?
Start with the last one. If your back-out line says “roll back the release”, check that your vendor actually describes a rollback.
This article looks at five platforms: SAP, Oracle Fusion, Workday, Salesforce and Microsoft’s Dynamics 365. Across all five, the public documentation doesn’t describe a customer-run undo of a whole update or transport once it is live.
Microsoft says it outright for Dynamics 365 Finance and Operations, about the regular service updates it applies there: “rollbacks can’t be done after a service update is applied”.
By the end, you’ll have a pack you can defend after go-live. Three tools build it:
- A 15-item checklist where every item names its proof, its signer and whether it blocks the go.
- A table of what each vendor documents about rolling back, postponing and timing a change.
- A decision rule for go, go smaller, go with conditions or no-go.
If you run the go/no-go for a recurring change on one of these five platforms, your name is on that “go”. If you can’t show what it covered and who accepted each risk, you can’t defend it later. And the next one is already in the diary.
Most of these vendors keep that diary for you. Oracle Fusion’s quarterly updates are mandatory for all customers. Salesforce delivers three releases a year, and publishes the dates up to a year ahead. Microsoft deploys Dynamics 365 updates in two release waves a year, to all its customers and partners. Workday moves all its tenant types to each feature release on the same day.
On SAP, the timing is yours: your team starts each transport import, or schedules it.
Why a green status report is not proof of readiness
A status colour tells you that something happened. It doesn’t tell you what it covered.
Take the UAT sign-off. It arrives as an email that says “approved”. But can anyone say which processes were tested, by whom and with what result? If not, the sign-off covers nothing you can point to.
Now take the open-defect list. “Twelve open, none critical” sounds safe. But a count can’t tell you what each defect would do to a business process. One defect on the payroll run matters more than 10 on a report nobody opens.
Then there’s the regression run. It’s green. But if nobody trusts the regression pack any more, green proves very little.
Status reports are not a readiness strategy.
If something breaks after go-live, leadership will ask you why it went live. Even if the decision wasn’t yours.
So what is proof? For every item in the pack, three things:
- The proof: the record that answers the item. A test result, a log, a named approval. Not a colour.
- The signer: one named person who says that proof is enough.
- The rule: what happens if the proof is missing.
The release readiness checklist: proof, signer and rule for every item
Here are 15 items in five groups. Each one carries its proof, its signer and its rule.
Every rule is one of three. It blocks the go, or it can be accepted by a named owner. Or it’s not applicable to this change. Adjust them to your own change controls, but fix them before the meeting, not in it.
A few items shift with the type of change:
- A vendor’s scheduled update: the vendor-feature check (Scope 2) applies, and regression tests (Testing 2) run where the vendor updates first.
- Your own enhancement bundle: on an SAP transport-only change, the vendor-feature check (Scope 2) doesn’t apply.
- An urgent fix: regression testing narrows to the processes the fix touches. The list of what wasn’t tested (Testing 3) is never skipped.
The pack works the same whether you make the call yourself, or a CAB or the CIO makes it.
Scope: what is actually changing
Start with what’s going in.
| Item | Proof | Signer | Rule |
|---|---|---|---|
| Scope 1 Change list frozen | The final list of changes, reconciled line by line to the approved changes | Release manager | Blocks |
| Scope 2 Vendor features that switch on by themselves, read and judged | Each such feature, the process it touches and a judgement, re-checked in the final week | Owner of each process touched | Blocks; not applicable to an SAP transport-only change |
| Scope 3 Interfaces, batch jobs and other applications the change reaches | A test result for each one | Integration lead | Blocks |
Scope 2 matters because some vendor features arrive switched on.
On Workday, features marked Automatically Available are switched on in your tenant by Workday itself. Workday’s own advice is to assess the impact and create a testing plan. Workday’s other label, Setup Required, marks the opposite case. Those features don’t affect your tenant configuration if you don’t set them up.
On Oracle Fusion, check the “Allows Opt-In” column on Oracle’s opt-in page for new features. Where that column is blank, the feature stays on once it’s enabled, and you can’t opt out.
On Finance and Operations, some features can’t be disabled once you enable them. Features in the Mandatory state are switched on, and disabling one means contacting Microsoft.
And re-check in the final week. Workday’s release-notes FAQ says a feature can still be added the week before the production release.
Scope 3 is where a mixed estate bites. A change in one application can break an interface into another.
Testing: what was run, where and what was left out
Next, the proof that it works.
| Item | Proof | Signer | Rule |
|---|---|---|---|
| Testing 1 Business sign-off backed by evidence | For each process: what was run, by whom, when and with what result | Owner of each process | Blocks |
| Testing 2 Regression results by business process | Results from an environment that already has the change | Test lead | Blocks |
| Testing 3 What we did not test | Each gap written down, with its reason | Owner of the process left untested | Blocks if the list is missing; each gap is accepted by its named owner |
Testing 1 fixes the empty sign-off. “Approved” isn’t proof. A list of what ran, who ran it and what happened is.
Testing 2 asks where the tests ran, not just how many passed. Results from an environment without the change prove nothing about the change.
Testing 3 makes the gaps visible. Every release leaves something untested. Write down what, why and who accepted it.
Defects: judged by what they hit, not how many
Now the open defects.
| Item | Proof | Signer | Rule |
|---|---|---|---|
| Defects 1 Every open defect listed | Each defect, with the process it hits and its workaround | Owner of the process each defect hits | An open severity 1 or 2 blocks if it sits on a process the change touches. Anything else can be accepted by that process owner, with a written workaround |
Don’t set a percentage of open defects as your bar. A count can’t tell you what each defect would break.
Approvals: who signed what, and when
Then the approvals.
| Item | Proof | Signer | Rule |
|---|---|---|---|
| Approvals 1 Every approval recorded | A name, a time and what it covered | Release manager | Blocks |
| Approvals 2 The approver didn’t build the change | The builder and the approver, named, and not the same person | Change manager | Blocks where your change controls require it; otherwise accepted by a named owner |
| Approvals 3 The decision-maker named | Who makes the call, named on the pack: you, the CAB or the CIO | Release manager | Blocks |
An approval you can’t show later is barely an approval. No time, no name, no record of what it approved.
On SAP, check one more thing. Where quality-assurance (QA) approval is switched on, a request still awaiting approval can’t be imported. But SAP also lets a team activate such a request by hand, for example when the QA system isn’t available. So the Approvals 1 proof lists any request activated that way, and why.
Approvals 2 is segregation of duties: the person who approves a change isn’t the person who built it.
If your change controls require an approval trail, this group is that trail. If they don’t, it’s still the record you’ll need after go-live.
Cutover: the outage, the way back, the point of no return and hypercare
Last, the weekend itself.
| Item | Proof | Signer | Rule |
|---|---|---|---|
| Cutover 1 The business told when to stop work | The outage notice, sent, with its window | Business lead | Blocks |
| Cutover 2 The date checked against month-end, payroll and statutory deadlines | The calendar check, with any clash and its mitigation | Release manager | Blocks where the date can move; needs a written mitigation where the vendor sets the calendar |
| Cutover 3 The way back, named as the vendor documents it | The vendor’s page plus a tested forward fix; or “not stated by the vendor” plus the tested fix | Application owner | Blocks |
| Cutover 4 The point of no return | Its time, and who calls it | Cutover lead | Blocks |
| Cutover 5 Hypercare and first checks staffed | Names, hours and the first checks after go-live | Support lead | Blocks |
SAP is direct about the outage. Its help on precautions in the target system says: “You must stop productive use of the systems during the import.” For a vendor’s update, plan the outage around the update’s maintenance window.
Cutover 3 is the item to slow down on. Here’s why.
Can you roll it back? What each vendor actually documents
The table below shows what each vendor’s public documentation says on four questions, as of October 2026. Where it doesn’t describe an answer, the cell says so.
| Platform and change | Roll back once live? | Postpone? | The way back the vendor does document | Who sets the timing |
|---|---|---|---|---|
| SAP: transports of the customer’s own changes | not stated by the vendor | Not described as such; the customer starts the import of the requests in the queue, or schedules it for a specific time | Version management can display, compare and retrieve old versions of a repository object; an import can overwrite the active version. To correct an error in production between the import times, the request can be imported into QA and production earlier | The customer. Requests still marked “Request must still be approved” cannot be imported unless they are activated |
| Oracle Fusion: quarterly update | not stated by the vendor | Not described; the updates are mandatory for all customers and applied in the maintenance months the customer selects | Where “Allows Opt-In” shows a check mark, the customer can opt in to or out of the feature; where it shows nothing, the feature stays enabled once enabled and can’t be opted out of | Oracle, in one of three quarterly schedules the customer picks. Environments on the Non-Production cadence are updated the weekend after the first Friday of the month, on the Production cadence the weekend after the third Friday (Middle East: first or third Thursday) |
| Workday: feature release | not stated by the vendor | No postponement described; at the end of the preview window Workday delivers the release to all tenant types on the same date | A customer way back is not described. Setup Required features don’t impact the tenant configuration if not set up. Workday’s What’s New report shows whether a feature was removed or reverted | Workday. Automatically Available features: Workday enables them in the tenant. Preview tenants about five weeks ahead, if not earlier; features can still be added the week before production |
| Salesforce: major release | not stated by the vendor | No postponement described; upgrades are automatic and all customers run the same version | Not stated in the vendor’s documentation | Salesforce, three times a year, on dates published up to a year ahead; the first set of upgrades happens on sandbox instances 4–6 weeks before production |
| Dynamics 365 Finance and Operations: service update | No: “rollbacks can’t be done after a service update is applied”. If the deployment fails, the environment is rolled back to the original state | Pause at most one consecutive update at a time, and take at least two updates a year; Microsoft grants more pauses only when it confirms an update-blocking Microsoft bug or regression with no viable workaround | Features can be disabled, except some that can’t be disabled once enabled; mandatory features can’t be disabled without contacting Microsoft | The customer picks the maintenance window; Microsoft applies the update in it |
| Release waves: Dynamics 365 and Power Platform | not stated by the vendor | Power Platform documentation: “a release wave is a mandatory update and can’t be postponed” | Not described for the wave itself. Switching from the Monthly to the Semi-annual channel reverts the visibility of some features: a visibility setting, not a rollback | Microsoft, two release waves a year to all customers and partners |
Read across the rows and two groups appear. On SAP, you own the timing. On the four cloud platforms, the vendor sets the calendar, and you choose within it where the vendor allows.
SAP transports: you set the import date, but no undo is described
On SAP, your team decides when a transport goes in. SAP’s help on importing a queue says you can start the import or schedule it for a specific time.
But SAP’s public help doesn’t describe a way to undo an import.
SAP does have a knowledge-base article titled “How to recover the data if you have imported a request wrongly”, but its answer sits behind an SAP sign-in. So the SAP rollback cell says “not stated by the vendor”. If you have SAP support access, read that article before you write your back-out line.
What SAP does describe is a correction moved forward. To fix an error in production between the regular import times, you can import the correcting request into QA and production early.
SAP’s version management can also retrieve an old version of a repository object, such as a program. And it shows whether an import has overwritten the active version.
Note what that page covers: repository objects, such as programs. It doesn’t describe configuration data. So don’t plan to get configuration back that way.
One limit on this row: it covers transports of your own changes. Support packages and upgrades are a different question, and they need their own answer.
Oracle Fusion, Workday, Salesforce and Dynamics 365: the vendor’s calendar, and the few switches it documents
On these four platforms, the vendor sets the calendar.
Oracle applies its Fusion quarterly update in the maintenance months you selected. Workday puts all its customers on the same version. Salesforce upgrades are automatic, so all customers run the same version.
On Finance and Operations, you can select the maintenance window. Microsoft then applies the update during it.
And there’s the one plain “no” in the table. Microsoft’s One Version FAQ says rollbacks can’t be done once a Finance and Operations service update is applied. The exception is a failed deployment: if the deployment fails, the environment is rolled back to its original state.
For Oracle Fusion, Workday and Salesforce, the public documentation doesn’t describe a customer rollback. It doesn’t rule one out either.
So don’t write “Oracle cloud updates can never be rolled back” either. On Oracle’s separate EPM Cloud service, you may ask Oracle to revert an environment to its state before the monthly update. The condition: a fix for a critical issue isn’t immediately available.
EPM Cloud isn’t Fusion. But it shows that “never” claims more than Oracle documents.
What Oracle Fusion and Finance and Operations do document is narrower: a switch on a single feature, where they allow it.
On Oracle Fusion, you can opt out of a new feature only where the “Allows Opt-In” column shows a check mark.
On Finance and Operations, you can disable features, except some that can’t be disabled once enabled. Mandatory features can’t be disabled without contacting Microsoft.
Workday’s What’s New report is useful here, but it isn’t a way back. It says Setup Required features don’t affect your tenant configuration if you don’t set them up, and it shows whether a feature was removed or reverted. It doesn’t say who triggers a reversion. So don’t write “Workday will roll it back” on your pack.
The same goes for release waves. Microsoft’s release-wave pages don’t say whether a wave can be rolled back.
One more limit: none of this covers backing out your own configuration on a cloud platform. Think of a Workday business process, or a Salesforce deployment. Cutover 3 still applies there: name the correcting change, and test it.
What to write on the back-out line instead
So what goes on the back-out line? Nothing that claims more than the vendor documents.
In practice, that’s one or more of these:
- A forward fix that has already been tested.
- A feature switch the vendor allows, named.
- A decision taken in the test window, before production.
- The words “not stated by the vendor”, where the documentation doesn’t describe a way back.
If the line says “roll back”, the proof column holds the vendor page that describes it. That way, the night of the release isn’t when you find out your vendor doesn’t describe the undo you planned.
Saying no-go to a vendor update: the decision sits in the test window
A no-go means different things on different platforms.
On SAP, it’s simple. Your team starts the import. So a no-go means you don’t start it.
On Finance and Operations, you can pause one update, but never two consecutive ones. And you must take at least two updates a year. Microsoft allows extra pauses only when it confirms a bug or regression of its own that blocks the update, and no viable workaround exists.
On Oracle Fusion, the quarterly updates are mandatory for all customers.
Microsoft deploys release waves to all its customers and partners. And its Power Platform documentation says “a release wave is a mandatory update and can’t be postponed”.
For Workday and Salesforce, no postponement is described in the vendor documentation.
So where does a no-go still have teeth? In the test window. That’s the gap between the vendor updating your test environment and the vendor updating production.
On Oracle Fusion, environments on the non-production cadence get the update the weekend after the first Friday of the month. Production follows the weekend after the third Friday. In Middle East regions, Oracle uses the first and third Thursdays instead. Either way, that gives you about two weeks.
On Salesforce, the first upgrades reach sandbox instances 4–6 weeks before production. Workday’s preview tenants, where customers try the next release, get new features approximately five weeks before the feature release, if not earlier. And Microsoft says Finance and Operations customers “are expected to test service updates in sandbox environments as early as possible”.
A no-go in that window can still do three things:
- Hold your own changes back from the same weekend.
- Keep a feature off, where the vendor allows it.
- Get the workaround ready before production arrives.
Deciding in the test window is also how you escape the meeting where “go” is the only answer anyone expects. Make the hard call there, before production arrives, while it can still change something.
And if the date can’t move, say so on the pack. A no-go you can’t take isn’t an option. It’s a risk to manage.
Go, go smaller, go with conditions or no-go: the decision rule
Whenever you take the decision, it has four possible outcomes.
- Go: when every blocking item has its proof.
- Go smaller: when a blocking item has no proof but can come out, because nothing else in the release depends on it. Take it out and go with the rest.
- Go with conditions: when every open gap passes the four tests below.
- No-go: when a blocking item has no proof and can’t come out, and you can’t check it before the point of no return.
When a blocking item fails, try taking it out first, if nothing else depends on it. If it can’t come out, it can only go as a condition that passes the four tests. If neither works, it’s a no-go.
A condition passes when it’s:
- Known: the gap is named.
- Bounded: you know what it can hit.
- Owned: a named person accepts it.
- Checkable before the point of no return: the check, and its time, are written down.
Miss any one, and it’s a no-go described as a go. Use these four because each one leaves a record.
They also fix the risk that gets accepted in the room, with nobody named and nothing written down.
When a risk hits a process, the owner of that process signs its acceptance. Not IT alone. And on a vendor’s update, take the no-go in the test window, while it can still change something.
A worked example: one release taken to a conditional go
The release below is an example, built to show the rule deciding something.
The estate mixes SAP and Oracle Fusion, and the date can’t move. An SAP enhancement bundle, moved by transports, is planned for the weekend Oracle’s quarterly update reaches production. That’s the weekend after the third Friday of the month.
Three findings decide it.
First, Scope 2. An Oracle feature with a blank “Allows Opt-In” column touches invoice approval. The accounts payable owner reads it, tests it and judges it harmless. Signed.
Second, Scope 3. An SAP-to-Oracle interface failed in Oracle’s test environment two weeks earlier. The fix is built, and its retest is booked for 10:00 on Saturday. The point of no return is 14:00. So the gap is known, bounded and checkable in time, and the integration lead owns it. That makes it a legitimate condition.
Third, Defects 1. One severity 2 defect sits on a payroll report in the SAP bundle. It blocks. The report change travels in its own transport. The dependency check shows nothing else in the bundle needs it. So that transport is held back from this import, and the rest goes.
Here’s the pack, filled in:
| Item | Proof | Signer | Outcome |
|---|---|---|---|
| Scope 2 Oracle feature with no opt-in, on invoice approval | Feature read, tested, judged harmless | Accounts payable process owner | Accepted |
| Scope 3 SAP-to-Oracle interface | Failed in Oracle’s test environment; fix built; retest booked for 10:00 Saturday | Integration lead | Condition: known, bounded, owned, checkable by 10:00 |
| Defects 1 Severity 2 on a payroll report | Defect log; dependency check shows no other transport needs it | Payroll process owner | Blocks: held back from this import |
| Cutover 3 The way back | Oracle: “not stated by the vendor”, plus the interface fix (its retest is the condition above). SAP: “not stated by the vendor”, plus a correcting request, tested and ready to import early | Application owners | Met, with the condition above |
| Cutover 4 Point of no return | 14:00 Saturday, called by the release manager | Cutover lead | Met |
| Decision | Conditional go, smaller scope | Release manager, recorded Friday 18:00 | Go with one condition |
The call: a conditional go, with a smaller scope.
The Oracle update arrives that weekend either way. Oracle Fusion’s quarterly updates are mandatory for all customers.
The one-page pack to take into the meeting
Take one page into the room. On it:
- One line per item, each linked to its proof.
- Every condition, with its owner and its check time.
- The way back as the vendor documents it, or “not stated by the vendor” and the tested fix.
- The decision, who made it and when.
That page is also your record after go-live. When someone asks what the “go” covered, or who accepted a risk, you hand it over.
So here’s what to do this week. Take your next pack and add three columns: proof, signer and rule. Then read your back-out line against the table above. If it says “roll back”, find the vendor page that says how.
TurboCore’s release readiness and go-live assurance prepares the evidence behind a pack like this.
Build the pack so Saturday’s “go” survives Monday’s questions.