Sixteen countries went live on the same date
SAP says Colombina, a Colombian food multinational, moved from SAP ERP Central Component to SAP S/4HANA Cloud Private Edition through RISE with SAP, and did it across all 16 countries the company operates in at the same time. SAP's account of the migration, written by Paul Taylor, calls it a full, simultaneous migration. For anyone staring at a wave plan, that detail matters more than anything else in the write-up.
Most advice points the other way. Pick one country, prove the template, then roll the rest out in waves by region or legal entity and let each wave teach the next. Colombina took the opposite bet, and the case for it is stronger than the standard advice tends to admit.
Two country numbers appear in the piece and they measure different things. Colombina operates in 16 countries, and that is the migration scope. It serves 750,000 customers in more than 90 countries, which is a sales footprint rather than a set of ERP go-lives. The company reports more than 8,000 staff and almost US$1 billion in annual sales. More on the target product sits on the S/4HANA hub.
What a phased rollout costs while it runs
A wave plan looks safer on a slide because the scope of each go-live is small. The cost sits in the months between the waves. Two ERP systems run at once, both holding live master data, both feeding the group close, and finance reconciles between them every single period until the last country lands.
Then there are the interfaces nobody wants to own. Bank files, warehouse systems, tax reporting and customer portals all need connections into both systems, plus mapping to keep the two in step. That middle layer gets built, tested, supported and then deleted.
Template drift is the third charge. Wave one goes live, wave two asks for a change, and wave three inherits a template that no longer matches what wave one runs. A simultaneous cutover removes all three of those costs on the day it succeeds.
The same-date bet only pays if everything is ready
The demand is unforgiving. Every country's master data has to be cleansed and loaded at once. Customers, vendors, materials and open items from all 16 countries have to reach a state somebody will sign off on the same weekend, and a clean Colombian ledger says nothing about the records in a small sales office elsewhere.
Local statutory requirements are the hardest part to compress. Tax determination, electronic invoicing formats, payroll interfaces and statutory reporting differ by country, and each has to be configured, tested and accepted before the shared go-live. In a wave plan, a country that is not ready slips to the next wave. In a simultaneous cutover it either holds the whole programme or goes live broken.
What you give up is the rehearsal a first wave provides for free. No earlier country's payroll surprise warns the next fifteen. That has to be bought back with mock cutovers, which is why a full migration rehearsal becomes the only place the programme finds out what breaks. A payroll parallel run has to pass in every country before that date, not after it.
The 45 minute figure is about support after go-live
The article reports that with double the number of application servers, downtime has been reduced and most customer issues can be resolved within 45 minutes. Read that carefully. It describes how quickly issues get closed in the running business, and says nothing about how long the cutover weekend took.
Resolution time is a support metric, and a good one, measured after the programme had already ended. If your steering committee gets shown a number of that kind, ask what the clock starts on, which issue types are counted, and what the same measure looked like on ECC before the move. Doubling application servers is a sizing decision, and buying that capacity without buying hardware is one of the plainer arguments for a hosted private edition.
What the article does not tell you
The write-up carries no preparation duration, no cost, no go-live date and no description of the rollback plan. Those gaps are ordinary for a customer story and each of them matters to anyone copying the approach. A cutover that took three years to prepare is a different proposition from one that took nine months, and the article does not say which.
The bigger omission is what went wrong. Vendor customer stories almost never record it. Every large cutover has a country that loaded late, a tax report that failed in the first close, or an interface somebody ran by hand for a fortnight. Colombina's programme very likely had its own version of that list.
There is also no verbatim comment from anyone at the company. The programme was led by CIO Jesús Brand, and the piece describes the work rather than quoting him. If this turns up in your business case, label it SAP's account of a customer outcome and nothing firmer.
Where this leaves your own wave plan
Alongside SAP Fiori, SuccessFactors, Integrated Business Planning, Analytics Cloud and Ariba, Colombina is implementing Joule for SAP SuccessFactors and preparing Joule Agents and SAP Databricks. Agents and analytics sit on the data model and the extension layer you land with, so sixteen countries running one template cost less to build on than sixteen carrying wave-specific exceptions. That is the argument behind clean core as a budget decision, and the product picture sits on the Joule hub.
None of this makes a simultaneous cutover right for your programme. It makes the phased default worth arguing about rather than assuming. An honest comparison puts the parallel-run months, the throwaway interfaces and the reconciliation effort next to the risk of a bad weekend, and most business cases only show the second.
So price both sides. Take your wave plan, cost the months of dual running and the interfaces that exist only to bridge the two systems, and put that figure next to the cost of a cutover weekend that fails. Then ask your finance lead which number they would rather explain to the audit committee. The throwaway interface count comes straight off the integration map, and most teams have never counted it.
