Independent IFS Cloud practice · Operations notes
An IFS Cloud update calendar: who reads the notes, who tests, and what happens in the week of a maintenance window
Key takeaways
- IFS Cloud brings two kinds of change: regular service updates and periodic releases. A service update is a regression question, a release is a small project, and each needs its own owner.
- Your test calendar is built backwards from the production window date in your service agreement, because that date fixes how many days you have to test.
- Twelve scenarios, six on order-to-cash and six on purchase-to-pay, are the practice’s minimum pack for the flows where a failure stops invoicing or receiving. Extensions and integrations go on top.
- Modifications in the Layered Application Architecture break first, so they are tested before integrations, reports and additive extensions.
An IFS Cloud customer with no update calendar finds out about a service update the way users do: something behaves differently on Monday. The environment was patched in a window nobody on the customer side had marked, the scenarios that matter were not run in non-production first, and the person who could have read the release notes did not know it was their job. The cost lands on the days that already carry the most pressure: invoice runs, period close, shipping cut-offs.
1.Two kinds of change: service updates and releases
IFS Cloud customers receive regular service updates and periodic releases, and the two carry different weight. Check the update schedule that your agreement and IFS support give you, and enter those dates in your own calendar. The difference between the two, and how to test each, is covered in our article on service updates versus release updates; this one picks up from there and turns it into a calendar, a regression pack and a window runbook.
What each one changes for you
A service update delivers corrections to the release you already run. The question it asks is narrow: did anything we depend on change behaviour? Regression scenarios on your own configuration, run in non-production, answer it, and because it recurs all year the pack has to stay small enough that someone will actually keep running it.
A release delivers new functionality and changes to existing screens, projections and processes. Its question is broader: what do we adopt, what do we switch off, and what of ours is affected? It needs release-note reading by process owners, a decision on features to enable, a regression cycle that includes extensions and integrations, and user communication. Treat it as a project with a start date and a sign-off. The upgrade readiness checklist on ifs-erp.com covers preparation for a release; this article covers the rhythm around it.
2.How maintenance windows shape your test calendar
The maintenance windows for your environments are the fixed points of your calendar. Take their days and hours from your service agreement and from whatever planned maintenance policy IFS refers you to, and re-read both when they are revised.
Build the calendar backwards from production
Whatever the windows are, the time you have to test is the gap between the window for your non-production environments and the window for production. Count that gap in working days, subtract the days needed to fix and retest, and the remainder is the number of scenarios you can afford.
Three consequences follow. Test scripts and test data must be ready before the non-production window opens. The person who runs the scenarios has to be free in that week, so their leave and the window date are checked against each other when the calendar is built. And if a scenario fails, someone needs authority to raise it with IFS before the production window, so the calendar names an escalation contact.
Changing a window
Whether a window can be changed, and with what notice, is a question for your contract and IFS support. Write the resulting deadline into the calendar as a date. Postponing is sensible around a period close or a stock-take, and a poor remedy for an untested pack.
3.Release support length and why it drives planning
A release is supported for a limited period, and that period defines how long you can postpone a newer one. The length is a contractual matter, so take it from your service agreement and not from forum answers.
Write down the support end date of the release you run today and put the decision on the next release well before it. Postponement is legitimate for a closing quarter or a site go-live. It becomes expensive when it is the default, because each skipped release adds changes that were never exercised, and the regression cycle that finally covers them grows with every one. The true cost of customisation article on ifs-erp.com shows how much of that growth traces back to modifications.
4.A yearly update calendar template
A yearly calendar gives each recurring event an owner, a deadline relative to the maintenance window and a gate that closes it. Copy the table, replace the relative dates with those from your policy and contract, and attach names.
| Event | When (relative) | Owner | Gate to close it |
|---|---|---|---|
| Read service update notes | On publication, before the non-production window | IFS administrator | Notes triaged, affected modules listed |
| Prepare scenarios and data | Before the non-production window opens | Test lead | Regression pack and test data confirmed |
| Run regression in non-production | Between the two windows | Test lead with two key users | Pass, or defects with owners and dates |
| Go / hold decision | Before the deadline for changing the production window | Process owners, IT lead | Written decision, with the hold reason if any |
| Production window | Per your service agreement | IFS administrator | Post-window checks signed (section 7) |
| Release readiness | Well before the non-production release date | Project manager | Scope of adopted features approved |
| Release regression and user communication | Between the two windows of the release | Test lead, process owners | Sign-off by each process owner |
| Support horizon review | Twice a year | IT lead | Support end date recorded, next release decision dated |
Who reads the release notes and who signs off
The process owner of each module reads the release notes, because only the owner recognises when a described change touches how the business works. The administrator compiles who read what. Sign-off belongs to the same process owner, since it says “this process works for us after the change”, which is a business statement. IT signs off interfaces, batch jobs, security and performance.
The split of testing duties between IFS and the customer is set by the service agreement, so confirm the boundary in your contract before an update arrives. The method for building tests is in our testing article and the automation side in rethinking test automation.
The smallest regression pack that still protects order-to-cash and purchase-to-pay
This practice treats the following twelve scenarios as the minimum for every service update cycle. Run them on your own master data, with your own variants.
| Flow | Scenario | Check |
|---|---|---|
| Order-to-cash 1 | Customer order with price and discount | Release it and reserve stock |
| Order-to-cash 2 | Pick and deliver | Delivery confirmed, inventory transaction correct |
| Order-to-cash 3 | Customer invoice | Tax, currency and ledger posting |
| Order-to-cash 4 | Return or credit note on a delivered order | Stock and ledger reverse correctly |
| Order-to-cash 5 | Printed order confirmation or invoice | Renders with your layout |
| Order-to-cash 6 | Customer-facing order interface, if any | Message in and out succeeds |
| Purchase-to-pay 1 | Requisition to purchase order | Approval step fires |
| Purchase-to-pay 2 | Send order, record supplier confirmation | Confirmation status updates |
| Purchase-to-pay 3 | Receive goods, including a partial receipt | Stock and cost correct |
| Purchase-to-pay 4 | Register supplier invoice | Three-way match behaves |
| Purchase-to-pay 5 | Payment proposal and payment | Payment posts to ledger |
| Purchase-to-pay 6 | Supplier-facing interface, if any | Order export or invoice import succeeds |
Add one scenario per extension and per integration you own, one for the overnight scheduled jobs and one for the roles with the highest permissions. Write the pack down with expected results, so a different person can run it in a different year.
5.Where extensions and integrations break first
What breaks at an update is the part that is yours: code that depends on the interface of standard logic, integrations that read or write fields by name, reports built on standard data, and configuration edited in place. A Custom Event or Custom Field stays additive and tends to survive. Modifications in the Layered Application Architecture compile against an interface and can silently change behaviour when it changes.
The calendar uses that ordering to spend testing time: modifications first, then integrations, then reports, then additive extensions. The levels are defined in the tailoring guide. This practice’s reference figure is that a change set that stays additive needs up to 60% less regression testing at a release than one with Level 3 modifications. In the calendar that shows as fewer scenarios and a shorter test week. Preparation for a larger step is in our article on preparing for an ERP upgrade.
6.The week of a production window: a 7-day runbook
The week before a production window is a fixed sequence of decisions with one job per day. Day 7 is the earliest day, counted back from the window.
- Day 7 - the test lead confirms that the non-production regression run is finished and lists every open defect with an owner.
- Day 6 - process owners classify each defect as blocking, workaround available or cosmetic.
- Day 5 - for a blocking defect, the escalation contact raises it with IFS support, and any request to change the window is decided before its deadline.
- Day 4 - process owners and the IT lead record the go / hold decision in writing.
- Day 3 - users receive a short notice: when the system is unavailable, what may look different, whom to call.
- Day 2 - integration owners confirm that partner systems will queue or pause during the window, and the batch schedule is checked for jobs that fall inside it.
- Day 1 - the post-window checklist is open, the people who run it are named, and their availability on the morning after is confirmed.
7.After the window: verification and rollback conditions
Verification after a production window has two parts: a smoke run of the regression pack and a watch period over real traffic. The smoke run repeats the first, third and fifth scenario of each flow plus one test posting that is reversed straight away, and it finishes before the first users log in.
Agree rollback conditions before the window, as a short list of observable facts: the invoice print fails, a posting stops reaching the ledger, an integration queue grows without clearing, a role loses a permission it needs. What you can revert yourself depends on your service agreement, so settle in advance, with IFS support, which remedies exist. Write a workaround for each blocking scenario into the calendar: usually a short manual process while the defect is fixed.
The first service update often lands while hypercare is still running; our hypercare article shows how to fit the two together. If a project keeps missing its update gates, the project health check helps separate a calendar problem from a project problem. When the gap is on the supplier side, choosing an implementation partner and reading the quote explain how to ask for update support in writing and where it appears as a line.
8.Watching for exceptions after the window
A smoke run proves that the scenarios you thought of still work; it does not see unconfirmed purchase orders, overdue receipts or stock below threshold in the days after an update. The SCM Automation Pack watches those through standard OData projections with a read-only account. No object is created in the customer’s IFS Cloud, so a release update leaves nothing of ours in your tenant to test, and we check the projections against the new release under the subscription.
9.Frequently asked questions
How often does IFS Cloud get updated?
IFS Cloud receives regular service updates, which correct the release a customer already runs, and periodic releases that add functionality. The exact cadence is defined by IFS and in the customer’s service agreement, and a customer reads it there. A customer plans the two separately, because a service update needs a regression run and a release needs a project.
When are IFS Cloud non-production and production maintenance windows?
The days and hours of the windows come from the customer’s service agreement and from any planned maintenance policy that IFS refers the customer to. A customer reads the current versions, enters the resulting dates in its own calendar and plans testing in non-production before the production window.
Do I have to move to every new IFS Cloud release immediately?
A release is supported for a limited period defined in the customer’s service agreement, so adopting a newer release later is possible until that period ends. Postponement stays cheap while it is a decision with a date, and becomes expensive when it is the default, because untested changes accumulate between releases.
Who is responsible for testing after a service update, IFS or the customer?
The split is set by the customer’s service agreement. The part that belongs to the customer, its own configuration, extensions, integrations and reports, is validated by the customer in non-production before the production window. A customer therefore keeps a written regression pack with expected results and a named test lead, and checks the contract wording on testing before the first update arrives.
10.About the author
Dariusz Myśliwiec: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice.
Selected clients: Fugro · LGC · BVI Medical · Betafence · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Updates keep arriving and nobody owns the calendar?
A short technical call is enough to agree the operating model: dates from your service agreement, roles, the regression pack and the go / hold gate. You leave with a calendar your team can run without us.