Guilherme Joventino is COO and co-founder of MIGNOW, which says it developed the world’s first SAP upgrade software. He has more than 20 years of experience in SAP implementation at major global corporations and leading retail companies. With SAP ECC mainstream maintenance ending next year and migrations often taking 18 to 36 months, he explains in this interview where companies actually stand, which parts of an ECC to S/4HANA migration AI can compress, how it reduces risk and cost, and which decisions must stay with people.
With ECC mainstream maintenance ending next year, where do companies actually stand in their migration, and what most often keeps them from starting or finishing?
Most companies are still much closer to the starting line than they’d like to admit. There are more than 40,000 SAP customers worldwide that still need to move to S/4HANA, and the traditional, manual delivery model can handle roughly 2,500 projects a year. The math just doesn’t add up.
What stops companies from starting is rarely the technology. It’s uncertainty. A lot of them don’t have a clear picture of what they’re running today: how much custom code they have, how many integrations, how much of it anyone still uses. Without that, it’s hard to put together a business case the board will sign off on, so the decision keeps getting pushed back.
What stops them from finishing is usually scope. There’s a classic trap here: “while we’re at it.” While we’re at it, let’s redesign this process. While the project is running, let’s add that. Each request sounds reasonable on its own, but together they turn a migration into a program nobody can predict. In my experience, projects rarely run late and over budget for technical reasons. They start late, the scope is defined without proper analysis, and governance is weak.
And waiting only makes it harder. Environments drift, documentation gets lost and the custom code keeps growing.
Which parts of an ECC to S/4HANA migration does AI meaningfully compress today, and which still depend mainly on people?
A big part of an SAP migration is repetitive, rule-based, high-volume work, and that’s exactly where AI makes the difference.
You see it first in the assessment. Instead of weeks of manual analysis, we map the environment, identify custom code, usage, dependencies and critical gaps, and estimate effort based on what we’ve seen in previous projects.
The biggest gain is probably in custom code remediation. Our AI is built on machine learning, so it learns from what worked in earlier projects and applies that to new ones.
Every adjustment follows the same rules and patterns. That’s an important distinction, because a lot of tools on the market just automate specific steps, with no real AI behind them. Today we automatically update more than 97% of custom “Z” code, with every change documented and traceable, and we automate around 85% of the overall conversion.
Then there’s testing. Running tests automatically and in parallel cuts the time and manual effort it takes to validate the system, and the system keeps running throughout the project.
What still depends on people are the decisions: defining the transition strategy, deciding which customizations still add value, validating critical business processes, managing change with users and making the go/no-go call on cutover. When there’s a very high volume of complex custom code, you also need specialists reviewing what the AI proposes.
The point was never to replace SAP experts. It’s to free them up for the decisions that really need their experience.
How does AI reduce migration risk in practice, for example in code analysis, data quality, testing, or cutover planning?
Most of the risk in a migration comes from manual execution and the variability that comes with it. Give the same problem to two people and you’ll get two different solutions. Multiply that across thousands of objects and variability becomes risk. What AI does is make execution consistent.
In code analysis, automation means we review the entire custom code base, not a sample. Every object is analyzed, adjusted under the same rules and documented, so there’s a clear record of what changed and why.
With data, the big lever is shrinking the volume before the conversion. If you archive and clean up technical waste, logs and inconsistent records first, you have a smaller, cleaner database to convert. That shortens downtime and cuts down on surprises.
In testing, automated, parallel execution lets you run more cycles in less time. That matters a lot, because testing is usually the first thing to get cut when a project is under pressure.
Cutover comes down to repetition. Once the process has been rehearsed and is largely automated, downtime becomes something you plan for instead of something you hope for.
At Volaris, the Mexican airline, our AI automatically remediated about 97% of the custom code in their SAP upgrade, and business downtime at cutover was just 1.6 days. At Gol, a Brazilian airline where SAP supports flight operations, the move from ECC to S/4HANA took eight months with zero operational impact.
And after go-live, a dedicated hypercare period catches issues before they reach the business.
Where do the cost savings come from, and how should a CIO measure them against a conventional migration plan?
I’d point to three places.
The first is effort. When around 85% of the conversion work and more than 97% of custom code updates are automated, the hours spent on manual, repetitive tasks drop significantly. On upgrades, our projects save around 50% in project costs on average.
The second is time. A shorter project means less time paying for parallel teams, consultants and environments. Assaí, a Brazilian retailer with more than 184 stores, migrated to S/4HANA in 37 days.
The third is the one people tend to ignore: the cost of things going wrong. Rework after go-live, extra test cycles, extended downtime. Rushed, emergency projects can end up costing up to 10 times more than planned ones.
So my advice to CIOs is to look beyond the initial quote. When you put a conventional plan next to an AI-assisted one, compare total cost of ownership, payback period, timeline variance, planned versus actual downtime, the number of issues during hypercare and how much of the code change is documented and traceable.
There’s also a long-term question that matters just as much: how much is the next upgrade going to cost? If the migration leaves you with a cleaner core, every future update gets faster and cheaper. That’s where the savings keep compounding.
What are the main risks of relying on AI in a migration, and what controls or human review should stay in place?
The biggest risk is treating AI as a black box. If you can’t explain what changed, why, and based on which rule, you’ve just swapped one kind of uncertainty for another.
Another risk is pointing automation at an environment nobody really understands. AI is very good at executing consistently, but if the data is poor or the scope is badly defined, it’ll just carry those problems into the new system faster.
And then there’s governance. As AI takes on more of the work, companies need to know what it can access, what it’s allowed to change and how those changes are monitored.
So some controls should never go away. Every automated change has to be traceable and documented. The rules need to be consistent and based on what’s already been validated, and that’s where machine learning makes a difference, because our AI applies patterns proven in previous projects instead of running isolated actions with no context. Specialists should review complex custom code and business-critical logic.
Functional and integration tests should validate the result, and business users should sign off on critical processes. Decisions about scope, cutover and go-live stay with people.
For me, the goal is a more predictable migration, not a more autonomous one for its own sake. The best results come when automation does the heavy lifting and experienced people stay accountable for the decisions.
What practical advice would you give a company that has not yet started its migration and has 12 to 18 months to act?
Twelve to eighteen months is still enough time, but there’s none to waste. If I were in that position, I’d focus on five things.
First, understand where you’re starting from, and do it now. Look at your system version, your custom code and how much of it is still used, your data quality and your integrations. Most delays start with a scope that was defined without proper analysis.
Second, build the business case early. Boards approve numbers, not urgency. Total cost of ownership, projected savings and payback make the decision a lot easier.
Third, pick your strategy and protect the scope. Choose the path that fits your reality, whether that’s a brownfield conversion, a selective approach or a new implementation. Then break the journey into clear phases and resist the “while we’re at it” temptation. A migration isn’t the moment to fix everything at once.
Fourth, clean up before you move. Look at which customizations still add value and which ones just add complexity. Wherever you can, modernize custom code with SAP BTP and current standards instead of carrying it over as is, in line with Clean Core principles.
Fifth, lock in capacity. Demand is far beyond what the market can deliver manually, so specialists will get scarcer and more expensive as 2027 gets closer. Automation is one of the few ways to buy back time.
And keep in mind that go-live isn’t the finish line. It’s the starting point for continuous updates and for the AI capabilities that only the latest SAP versions offer.
Editor’s note: Performance figures and customer results cited in this interview, including automation rates, cost savings, project timelines and cutover downtime at Volaris, Gol and Assaí, are reported by MIGNOW and have not been independently verified by AI Time Journal.
