Know what was tested before your SAP ECC migration goes live
In this Help Net Security interview, Guilherme Joventino, COO of MIGNOW, explains why some large companies plan to stay on ECC past the 2027 deadline and pay SAP for extended support until 2030. The interview covers what that choice may cost, why fear of disruption stalls projects more often than budget, and what the first ninety days of a phased migration involve. It also looks at staff who hold years of knowledge about the old system, and a Central American project that passed every quality gate but still had a difficult go live.
Give an example of a company that treated the 2027 deadline purely as an insurance policy. What specifically did that cost them, in dollars, time, or lost opportunity?
This comes up most often with our rollout clients. One of them, a large global manufacturer, visited us not long ago. They run a formal corporate rollout plan that says which countries go live and in what order, and 2027 simply isn’t part of that conversation. The reason is straightforward: SAP sells you additional years of support if you are willing to pay for it, so you can stay where you are until 2030. For big companies, the extra support fee is small next to the cost of the migration project itself, and they would rather protect the sequence of the rollout than compress everything to hit a date.
I want to be careful about what that has cost them, because we haven’t reached 2027 yet and I don’t think anyone can put a credible number on it today. What I can tell you is that the answer depends almost entirely on how the company uses the system. If the ERP is carrying innovation, new product launches, new business models, then every year of delay has a cost, even if it never shows up on an invoice. If the system is essentially a financial back office, the risk really is low, because those processes barely change from one year to the next. That is the variable that decides whether waiting costs you anything at all.
That said, we do see a pattern, and it points in one direction. The companies that treat SAP strategically have already moved. The ones that chose to wait are, almost without exception, the ones running it as back office. So even though the financial impact isn’t fully measurable in 2026 and will only be visible later, we are convinced the strategic users are getting real value out of having gone first. They are already building on the new platform while the others are still planning the move.
The one number that is concrete today is on the support side. SAP charges roughly 2% on top of the standard enterprise support fee to extend maintenance, and that fee is already a percentage of the license value paid every year. On a one million license you are paying around 22% annually, so the extension is a real line item, just not a large enough one to change most people’s minds on its own. That is why we frame this as a strategic decision with our clients instead of letting it turn into a question about buying insurance on a deadline.
When a client tells you they’re not ready to migrate, what’s the real reason underneath the reason they give you? Is the delay usually a budget problem, a staffing problem, or a fear of disruption problem? Which one is hardest to solve, and why?
Budget is rarely the real blocker, it is usually just the easiest thing to say out loud. Underneath, the more common driver is fear of disruption, and specifically the fear that the migration will interrupt something the business cannot afford to interrupt. In practice that fear tends to centre on a handful of very concrete moments: financial close dates, peak operational windows, inventory or logistics commitments already in motion. Teams are afraid of the day the system goes live and something breaks inside a window they cannot reschedule.
The staffing shortage is real too, but it usually shows up later, once the decision has been made and the company realises how few people internally still understand the full extent of the customisations built up over the last ten or twenty years.
Fear of disruption is the hardest of the three to solve, because reassurance on its own does not fix it. What moves the decision is proof: seeing another company of similar size and complexity go through it without the business breaking, and having a tested plan for the exact operational windows that matter most. Until that proof exists, no business case closes the gap by itself. That is where our track record does more work than any argument we can make.
What does the first ninety days of a phased migration look like at a mid-size company, task by task?
The first ninety days are not the migration itself, they are what we call the pre-project, the setup and explore phase, and in our experience they decide how the rest of the project goes. On an upgrade project, the window is even shorter, closer to the first thirty days, because those projects move faster.
The first task is knowledge transfer on the methodology itself: walking the client through how a conversion is done, step by step, from preparing the environment through to final delivery. That can sound like a process for its own sake, but it is the single biggest success factor we have, because it aligns every stakeholder around the same sequence and keeps the project from stalling. That is what lets our AI run without interruptions, and that is where the real acceleration comes from: the technology only delivers the speed it is capable of when the process around it does not keep stopping.
From there the work is technical and functional preparation: planning the project in detail, standing up and configuring the environments according to what the pre-project defines, and building the functional understanding of what is in scope. This is also where the test plan gets defined, which processes have to be validated and who signs off on them, because testing is the part that decides how quiet the go live is, and it is far too late to organise it once the conversion is already running. What determines whether that lands on time is almost always on the client side, the client’s own time and attention, and the availability of resources, people as much as infrastructure and system access, so the project can be executed.
That is also why we spend the early days on the methodology. Once a client understands how the conversion works, they understand why the pre-project matters, and the preparation stops being treated as overhead and starts being treated as part of the migration.
What happens to the people who know the old ECC system inside and out once the migration is done? Do companies plan for that, or does it become a scramble?
Honestly, it becomes a scramble more often than it gets planned for. The people who know the old system best are usually the ones whose knowledge is least documented, because it lives in their heads after years of working around the system’s quirks and patching the gaps between finance, logistics and reporting by hand.
A common example, and a telling one: someone whose job for years was manually pulling data from different areas into a single spreadsheet so leadership could see one consolidated number, work that used to take days. After the migration that same output takes minutes. That person’s old job effectively disappears, and whether that is a win or a loss depends entirely on whether the company planned for it.
The companies that handle it well identify those people early and give them a dual role for the length of the project, part operations and part institutional memory for the migration team, and then deliberately move them into higher value analysis work once the manual task is automated. The ones that do not plan for it either lose that expertise to attrition partway through the project, which causes delays because nobody else can explain why a given customization exists, or they leave the person in a role that no longer needs to exist, which is its own quiet cost.
What’s a migration you worked on that technically succeeded but that you’d still call a disappointment, and why?
The one that comes to mind is a manufacturing and distribution company in Central America. It is a relationship that worked out well in the end, they are still with us and we are running an upgrade for them right now, and on paper the original project was a success: delivered, in production, every quality gate in our methodology met. I still call it a disappointment because the go live was harder than it needed to be, and the reasons had very little to do with the technology itself and everything to do with how prepared the environment around the project was.
In short, the environments were not sized the way a conversion of that size needs, so what should have been one go live became two. And the team on the client side was small and carried the project on top of their day to day, so the test coverage in a few operational areas ended up thinner than any of us realized at the time. The issues we saw in the first days in production were concentrated almost entirely there.
What I take from it is that the quality of a go live is decided well before go live, and it is decided by preparation. Our AI makes the conversion predictable and our methodology makes everything around it predictable, and a smooth go live needs both. A conversion only looks smooth when the environments are ready, when testing covers the processes the business runs on, and when the results of that testing are recorded in a way that tells you something. Where a client has the technical depth and the bandwidth to own that, the go live is quiet, usually one or two tickets in the first hours. Where they do not, it is a capacity gap, and it is our job to see that early and close it instead of assuming it will be covered. That is exactly what we did here, which is why the relationship held and why they came back to us for the upgrade, and it is why we now spend real time at the start of an engagement on readiness and bring our own people into the testing phase.
Organizations should look for a solution that automates a large part of the testing effort in a conversion. The idea is to generate and execute the test coverage automatically and give both sides real visibility into what has been validated, so that an organization which does not have a deep technical team is not the one carrying that risk. For companies in that situation, it takes the single biggest variable in a migration and makes it far more predictable.
