Infor M3 & CloudSuiteFree checklistPDF, Excel, Word exportInfor M3All Infor M3 tools

Infor M3 LCM Fix and Cumulative Update Checklist

This checklist covers applying M3 Business Engine fixes and cumulative updates on an on-prem Infor M3 13.x system through Lifecycle Manager. It adds the MAK retrofit and regression steps that keep modifications and integrations working after the fix.

0%

0 of 30 items complete

9 critical items still open - these are the highest-risk gaps.

Download checklist:

Prepare

Apply in test

Verify

Production

Close

Critical items protect against the two common failures: a fix that overwrites a MAK modification's behaviour, and production differing from what was tested. Do not start the production window until every critical item in Prepare, Apply in test and Verify is checked.

Get your next M3 fix window scoped

Send us the fix list and your modification register and we will flag likely MAK merges and the regression tests to run.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use it

Open a copy per fix window. Group the fixes you plan to apply, read their documentation and list the affected programs before anything is installed. Work through Apply in test and Verify fully, then repeat the exact same fixes and MAK builds in production. Critical items block the production window. Export the result to PDF and attach it to the change, together with the LCM logs. The Close group is what makes the next window faster: a known fix level per environment and an updated modification register.

Where this lives in M3 13.x

On-prem M3 13.x is installed and maintained through Lifecycle Manager (LCM), which manages the M3 Business Engine and other grid applications per environment and is where you see installed fix levels. Java modifications are developed and deployed with the M3 Adaptation Kit (MAK); when a fix changes an object you have modified, the change has to be merged into the modification and the modification rebuilt. The H5 client, MI programs and MEC all sit on top of the Business Engine, which is why the Verify group tests all three, not just the screens.

Worked example

A cumulative update corrects pricing in customer order lines. The fix documentation lists changed objects used by OIS100. Your register shows a MAK modification on one of them that adds a discount check. In test, the administrator applies the update through LCM, the developer merges the standard change into the modification and redeploys it, and the grid applications are restarted. Testers run order entry with and without discounts, an EDI order through MEC and the order-line MI transactions used by the web shop. All pass, so production gets the same update and the same MAK build in the next window.

Gotchas

The most common problem is a modification built against the old object that silently undoes the fix, so the fix appears not to work. The second is browser and client caching after panel changes, which makes testers report errors that are not there. The third is applying a slightly different set of fixes in production than in test because a new fix was released in between. Freeze the list at the start of testing and move new fixes to the next window unless they are urgent.

Frequently Asked Questions

What does an Infor M3 technical consultant check before applying a fix?

Prerequisites and manual steps in the fix documentation, the current fix level per environment in LCM, and which MAK modifications touch the changed objects. They also confirm backups exist and that the same fix list will be applied in test and production, in the same order.

Do MAK modifications need to be redone after an M3 update?

Only those that modify objects the update changes, but those must be merged and rebuilt. If you skip it, either the fix is lost because your modified version runs, or the modification breaks. A modification register listing changed objects makes this check quick.

How often should on-prem M3 be updated?

Many sites apply cumulative fixes on a regular cycle, for example quarterly, plus urgent individual fixes as needed. A regular cycle keeps each window small and testable. Long gaps mean larger fix sets, more MAK merges and bigger test scope each time.

What should be tested after an M3 BE fix?

The scenario the fix addresses, the MI transactions your integrations use, H5 scripts on changed panels, MEC maps for affected message types, key programs such as OIS100, PPS200, PMS100 and MMS001, and the batch jobs touching changed areas.

If you want your M3 team to ask in plain English which modifications and integrations a fix touches, we can set that up on your own servers.

ArchRay builder
Design the on-prem AI stack for Infor M3: model, GPUs, RAG pipeline, guardrails
See memory, speed and cost as you swap parts, then export the diagram. Free, in your browser.
Open the builder

Keep exploring

Free tools

ERP fixes and how-tos

Runs with your ERP

Guides

AI on your ERP

Integrations

Comparisons

Software