Testing Infor CloudSuite updates: feature releases, monthly maintenance and feature toggles

On-premises Infor ran on your upgrade schedule. Multi-tenant CloudSuite runs on Infor’s. Whether you are on CloudSuite Industrial, M3 or LN, the updates arrive on dates you do not choose, and the job of proving your processes still work after each one stays with you. This guide covers what arrives when, how to turn it into test scope, and the routine that keeps regression from swallowing the team.

The cadence: two feature releases and twelve maintenance updates

Since April 2023, Infor has delivered feature releases for its multi-tenant cloud products twice a year, in April and October. The monthly maintenance calendar continues for issue resolution, security updates and date-sensitive statutory and regulatory changes^[1]. Infor’s stated reasons were fewer changes to review each month and more time to prepare for new features^[1]. Trade press describes the same pattern: two major releases a year, with monthly updates focused on patches and fixes^[2].

Who tests? Infor’s own Customer Implementation Guide says that during testing the customer assumes ownership of the testing process, against entry and exit criteria in the test strategy^[8]. ERP Today’s reporting makes the same point about updates: Infor tests its standard platform, not your configurations, integrations and workflows^[2]. Write that into your operating model now, before the next release lands and someone asks who signed it off.

Get the dates from the deployment calendar, not from memory

Infor’s Customer Experience Hub publishes a Multi-Tenant Release Deployment Calendar and runs enablement on pre-release and post-release action items, Release Reports, Release Highlights and release training^[3]. That calendar is the input to your test calendar. Copy every feature release and monthly update into it, with the date your test tenant updates and the date production does.

Read the Release Report like a test lead

With the move to semi-annual releases, Infor replaced its Resolved Issues and Release Notes with a single Release Report, delivered through a knowledge base article and the What’s New widget^[1]. Treat it as a test requirements document. For every item that touches a product you run:

• Decide whether it affects you: yes, no, or to decide by a named date. “No” needs a reason.
• Map it to processes, interfaces and extensions from your ranked process list and integration inventory.
• Choose the scope: full, targeted, smoke, or none with the reason recorded.
• Link the test IDs. Any item marked “affects us” with no test is a gap the sign-off owner should see.

Statutory and regulatory changes deserve special attention because they arrive in the monthly calendar, not only in feature releases^[1]. Finance and tax owners should read those items themselves.

Feature toggles come with a deadline

Infor said in 2023 that it was building feature toggles so customers could adopt new features at their own pace^[1]. On M3 the mechanism is documented: features are typed (for example zero impact, functional setting, feature toggle, and feature toggle with a process change), a toggled feature has a transition period of at least six months, and the feature list in CMS975 shows the system update in which the feature will be forced on^[4]. Other CloudSuites handle new features in their own ways, so check your product’s documentation.

The testing consequence is simple. A toggle is a change with two dates: the day you choose to switch it on, and the day Infor does. Track every toggle with its forced-activation update and an owner, test it in a non-production tenant before you activate it, and flag anything inside your warning window that has not passed.

The test tenant: refresh it like a test event

Realistic regression needs realistic data, which usually means refreshing a test tenant from production. Infor’s documentation sets the rules. Through the CloudSuite Self-Service Portal you can schedule only one refresh per calendar month for each target suite; the feature must be enabled by Infor; some CloudSuites are refreshed by Infor operations instead; and a refresh can erase all data in the target and may not be reversible^[5]. Refreshing the production tenant is not allowed^[7].

The LN documentation lists what goes wrong if you are careless. Automatic processes on the refreshed tenant can start sending invoice emails or contacting tax authorities unless you block them first; security-related information on the target is deleted; users are copied from the source; and extensions, personalizations and development on the target are overwritten^[6]. Even if you run a different CloudSuite, those are the right questions to ask about yours.

Keep ION in every regression cycle

An update that leaves every screen working can still break an integration. Most Infor integrations run through ION as BODs: messages with a noun such as SalesOrder holding the business data and a verb such as Sync or Process describing the action, in a format defined by OAGi^[9]. ION OneView tracks each business document, shows every ION component it triggered and gives a timeline of its journey^[10].

Put every document flow in the regression suite with at least a positive, a negative and an error-path test, and make a OneView reference the evidence. Integrations deserve the attention: in Panorama’s 2026 ERP Report, more than a quarter of organizations went over budget, and an unexpected need for additional technology was the most common reason^[12].

Test security in both layers

Infor OS roles control access to the portal and its applications. Infor-SuiteUser is the default role for every user, and Infor’s documentation notes that even when a user can see an application, what they can open and do is controlled by the application’s own security^[11]. After an update or a refresh, test both layers for each business role: what the role must be able to do, and what it must not.

If you are still implementing, the clock is already running

Updates do not wait for go-live. Panorama’s 2026 ERP Report put the median ERP project at nine months^[12], and with a feature release every six months, a project of that length will see at least one feature release and several monthly updates land while you are still building and testing. Plan for it in the project test plan rather than discovering it in the middle of SIT.

• Map the releases onto your phases. Infor’s guide describes Onboard, Build, Test and Launch^[8]. Mark which updates fall in which phase.
• Budget regression days inside SIT and UAT. If a feature release lands between SIT 1 and SIT 2, rerun the completed SIT 1 scenarios first.
• Build the regression suite as you go. Every SIT scenario you automate during the project is one you do not run by hand in April or October.
• Pick your go-live date with the calendar open. Your first weeks live should not also be your first regression cycle.

The routine

Measure three things per update: coverage of critical processes, regression cycle time and defects that escaped to production. If cycle time is not falling release over release, automation is not keeping up with the calendar.

Templates for this guide

The free Infor CloudSuite Update Regression Plan holds the release calendar, Release Report triage, toggle register, scope rules and a tenant refresh checklist. The ION & BOD Integration Test Tracker covers the flows, and the Manufacturing Process Test Scope Matrix ranks which processes belong in every cycle.