Before an AI assistant starts work on your part of an ERP migration, sort its decisions into 3 groups and name an owner for each. Then keep the reason for every decision your team must be able to explain.
On 28 October 2026 SAP said 4 of its migration and modernisation assistants are available to early adopter customers. It said they are already supporting live projects to move to a cloud enterprise resource planning (ERP) system.[1] SAP's article says these programmes can require "thousands of business and technical decisions". That is SAP's phrase and not a count. The article is a supplier's account of its own product, and it gives no figure for time or cost saved.
Whether the assistants work is only part of your question. The narrower part is what happens to a reason when an assistant takes a decision that a person on your team used to take. A person can tell you why. If nobody keeps that reason, your team has a working system that it cannot safely change.
The reason matters on both sides of the contract. If you work for the client, you will run the system after the integrator has left. If you work for the integrator, you may have to explain a result nobody decided by hand, and your handover should answer that question for you.
Below: what SAP says the assistants do, where a reason goes missing and how to sort the decisions on your own work package.
SAP uses the word 'autonomously' of 2 assistants out of 4
Here is what SAP says each assistant does.[1]
- Data management: it analyses data quality, ranks issues by business impact, recommends fixes and helps carry them out. SAP says the fixes can be automated or guided.
- Test management: it helps define test scope, generates test cases and works out the test data they need. The cases then pass to SAP Test Automation by Tricentis to run.
- Custom code: this covers the changes your organisation has made to standard software. "Acting autonomously", it sorts findings by complexity and "applies available automated fixes". It then generates recommendations and corrections for the remaining findings.
- Business configuration: configuration means the settings that make the software follow your business. This assistant "recommends and autonomously applies configurations" for your industry, segment and goals. SAP says it also flags deviations from SAP's target requirements and "maintains a full audit trail".
SAP plans 3 more: System Analysis, Project Management and Rollout. SAP's article gives no dates for them.
SAP names one customer. AkzoNobel, the paints and coatings company, uses the data assistant through an SAP early adopter programme. It uses it to set the scope of its data quality work and to rank fixes by business impact. An AkzoNobel lead says in SAP's article that it "reduced analysis effort". That is a customer's statement in a supplier's article, with no figure.
The article does not say how a customer limits what an assistant may do alone, or who accepts its work. Those 2 questions are yours to answer.
An audit trail shows what changed, and the reason can still go missing
An audit trail is a log of what changed and when. SAP's article does not say what the trail holds, so check it. A log answers 'what changed?'. The question your successor will ask is different: why was it set this way, and who agreed?
The case below is invented to show the gap. Nothing in it comes from SAP or AkzoNobel.
An example manufacturer has a rule in its old system. Its credit check rule sets a lower maximum order value for one group of distributors than for everyone else. An order above that value is stopped. The rule exists because of a bad debt some years ago. The credit controller knows that. Nobody wrote it down.
During the migration, an assistant reads the old settings and flags the rule as a deviation from the target. Moving to the standard setting is a sensible default, and the change is applied. The test cases pass, because they test the process as it is now designed. The work package closes on time.
A year later, one of those distributors places a large order the old rule would have stopped, and the debt goes bad. The log shows the setting changed, and on which date. It does not show why the old rule existed, because nobody ever recorded that. The credit controller has moved to another team.
Nobody did anything wrong. The assistant followed its target and the team followed its plan. The reason simply had no home.
In fairness to the assistants, and this is a view rather than a finding: reasons go missing on hand-run programmes too. A full audit trail may leave a better record of what changed than a hand-run programme ever did. On this reading the assistant does not create the problem. It moves more decisions past the person who would otherwise have stopped to ask.
Your next change depends on knowing which settings are safe to move
Your organisation will change this system again. A new country, an acquisition or a new tax rule will each send someone back to the settings. That person needs to know which ones can move and which ones are there for a reason.
That knowledge is the ability to change. Teams build it by taking decisions, or by reading why they were taken. An assistant may shorten the time it takes to reach the new system. It does not hand your team that knowledge unless somebody arranges for it.
So the useful test on your work package is small. Pick any setting the assistant changed. Can someone on your team say why it is now that way, without asking the person who left?
Rebuilding 6 lost reasons could take longer than writing all 60
Every figure here is an example. Your work package holds 60 decisions that a person must own. A short reason takes 10 minutes to write. That is 10 hours.
Suppose instead that nobody writes them. After go-live, 1 decision in 10 comes back, which is 6 of the 60. Each one takes 2 people 3 hours to work out again. That is 36 hours, spent while the system is live and the people who knew may have gone.
Swap in your own numbers. The one worth checking is how many of those reasons you could recover today.
Sort your work package's decisions into 3 groups before the assistant runs
List the types of decision on your work package. Then put each type in one group.
- The assistant may apply it. The change is small, tested and easy to reverse. Example: a code fix with a standard replacement. The owner reviews a sample, chosen at random from each batch.
- The assistant recommends and a named person accepts. Example: the ranking of data fixes.
- A person decides and the assistant informs. Example: anything that touches money, tax, credit or compliance, or any old rule nobody can explain.
Use 3 questions to sort them. Would reversing it need a change request, the formal request to change a live setting? Does it touch money, tax, credit or compliance? Is the reason for the old way unknown? Each 'yes' moves the decision towards group 3.
Then ask how far the assistant can be held to those groups. On the client side ask the integrator or SAP; on the integrator side ask your delivery lead. If it cannot, review its batches before they are accepted.
Done when: every type of decision sits in one group, each group has a named owner and your programme lead has seen the list.
Record the reason for every decision a person takes
Keep the record short, or it will not get written. This one is invented, like the rule above:
Decision: keep the lower maximum order value for the distributor group
Old rule: the credit check stops an order above that value
Reason: a bad debt in this group; the finance team set the rule
Decided by: credit controller, with the date
Review when: the first new-country rollout
Write it when the decision is taken, while the person is still in the room. Store it somewhere your organisation owns, beside the programme's other papers.
This week's Capability Brief sets out a one-page rule sheet, for the moment an AI action is allowed to update a live record. The record here comes earlier. It keeps the reason for a decision taken during the migration, long before anyone switches anything on.
Done when: a colleague who was not in the room reads the record and can say why the setting is the way it is.
Ask what the audit trail holds before go-live
Ask to see a real extract from the trail. Then read it with one decision in mind. Can you see what changed, who accepted it and why?
If the extract holds the change and not the reason, your short record is the only home the reason has.
If you are the integrator, settle this before your team rolls off. After checking with your delivery lead, agree with the client's lead who holds these records once you leave. Put them on the handover list, with a name beside them.
Done when: you have read a real extract, and every gap in it has a named owner or an entry in your record.
References
- SAP News, feature by Maura Hameroff, Sonja Liénard and Soeren Ruder on its migration and modernisation assistants for cloud ERP transformations, 28 October 2026. https://news.sap.com/2026/10/migration-and-modernization-assistants-sap-customer-cloud-erp-transformations/.