SAP 2027 seen from Morocco: a decision date before it is a migration date.

Everyone knows the deadline. SAP has announced the end of mainstream maintenance for ECC at the end of 2027, with a paid extension possible beyond that for those who choose it. On paper, there is still time. In practice, a transformation of the core management system is scoped, arbitrated, contracted, then executed, and each of those steps is counted in quarters. Those who think in terms of the end-of-maintenance date are already behind. Those who think in terms of their programme’s launch date keep control of the calendar, the budget and the choice of their partners.

Why 2027 reads differently from Casablanca.

Moroccan and African companies share the same technical constraint as European ones. They share neither the same starting point nor the same environment. Three differences weigh on the decision.

• Landscapes that are often younger, but more heterogeneous. Many ECC systems in the region were deployed in waves, subsidiary after subsidiary, sometimes by successive integrators. The result is a core that is less old than in Europe, but less harmonised: several process models coexist under the same logo.
• Local requirements that are non-negotiable. Evolving tax rules and electronic invoicing, chart of accounts, reporting obligations, personal data protection, payroll or customs specifics depending on the country: a programme that deals with them at the end of the journey pays for them dearly.
• A narrower skills market. As the deadline approaches, S/4HANA profiles become scarcer everywhere. In the region, where the talent pool is smaller, latecomers will negotiate their programme under the worst availability conditions.

These differences do not make the decision harder. They make it more urgent, and more local: a scenario copied from a European group without filtering it through your own reality is a scenario that will fail at the first regulatory obstacle.

Three scenarios, no doctrine.

Public debate readily pits the “fast and risk-free” conversion against the “ambitious but never-ending” new implementation. The ground reality is less clear-cut. There are three families of trajectories, and the right choice follows from your existing landscape, not from a vendor’s or an integrator’s conviction.

Conversion

Converting the existing system preserves history, processes and developments. That is its strength, and its limit. It suits companies whose ECC core has remained healthy: harmonised processes, custom developments under control, clean data. Converting a disorderly system amounts to moving house without opening the boxes: the mess arrives intact in the new home, where it costs more to maintain.

New implementation

Starting from a new system makes it possible to adopt the S/4HANA standard, purge years of custom developments and rebuild processes on a clean base. It is the most transformative path, and therefore the most demanding: it assumes the company agrees to change its ways of working as much as its tool. For groups in the region that finally want to unify their subsidiaries on a common model, it is often the opportunity not to be missed. Provided the greenfield is not run as a disguised conversion, where every departure from the past is renegotiated line by line.

Selective transition

Between the two, selective approaches make it possible to sort: keep the history and the processes that have value, redesign the rest. For multi-country groups with heterogeneous landscapes, where no single answer exists, it is frequently the relevant path. It is also the most demanding in terms of architecture, and the one that forgives improvisation the least.

The scenario is not chosen from a catalogue. It follows from an honest diagnosis of your processes, your custom developments, your data and your capacity to absorb change.

RISE, public cloud: reading the offers through the buyer’s eyes.

The question of the target is now coupled with a question of commercial offering. RISE with SAP bundles licence, infrastructure and services into a subscription, in a private cloud. The public cloud, with GROW, imposes the standard and an update rhythm dictated by the vendor. These offers are neither good nor bad in themselves; they suit different company profiles.

Seen from the region, three points deserve particular attention. Data location first: where is your data hosted, under which jurisdiction, and what do the regulations of your country and your regulated sectors say? Connectivity next: a core management system in the cloud assumes network links whose quality and redundancy are not assumed, they are verified. The economic model finally: the subscription smooths the expense, but commits it over time and in foreign currency. A CFO must be able to compare scenarios on total cost over several years, not on the price of the first one.

Our position: the public cloud is an excellent answer for an entity that accepts the standard and wants to move fast, a new subsidiary for example. The private cloud remains the natural path for complex landscapes. What matters is not the word “cloud”, it is the architectural discipline that goes with it: a clean core, extensions alongside the standard and not inside it, so that the new system does not reproduce the drift of the old one.

Local requirements, up front and not in an appendix.

We see too many programmes where local compliance arrives at the end of design, as a separate work package handed to the country teams. It is the opposite that must be done. The chart of accounts, tax and reporting obligations, electronic invoicing where it is mandatory, personal data protection, the management of currencies and intra-group flows must be set out from the scoping stage, country by country, because they condition the data model and the split into waves.

For a Moroccan group operating in West or Central Africa, this means one concrete thing: the common model must be designed to absorb local differences without turning each of them into a custom development. That is a job of functional architecture, and that is where the presence of teams who know these contexts makes the difference between a deployment that expands and a deployment that bogs down.

Deciding in a few weeks, not in a few quarters.

Our conviction is simple: the first step is neither a tender nor a choice of tool. It is a short and decisive scoping exercise, which delivers three things to general management.

• An unsparing assessment of the existing system: processes, custom developments, data, costs, risks, local obligations. A diagnosis that draws consequences, rather than one more inventory.
• Scenarios that are genuinely compared, in total cost and expected benefits, with their conditions for success made explicit. A scenario without conditions for success is a sales pitch.
• A roadmap in waves, sequenced according to dependencies, the teams’ capacity to absorb change and the regulatory deadlines of each country, where each step delivers intermediate value.

This scoping changes the balance of power. The company that knows what it wants, in what order and on what conditions, chooses its partners instead of enduring them. And that is where the constraint becomes an opportunity: the deadline offers what no programme obtains easily, the alignment of the whole company, head office and subsidiaries, on a single date. It would be a pity to make it a mere technical migration.

One last thing, which comes down to the way we work: those who scope must be those who deliver. A scenario recommended by a team that will never carry out its execution is a scenario without an owner. We prefer to put our name on both.

What to remember

2027 is a decision date. Waiting for the maintenance extension without a trajectory means letting the market, the skills and the calendar decide for you.

The scenario

Conversion, new implementation or selective transition: the choice follows from a diagnosis of your processes, your custom developments, your data and your capacity to absorb change, never from a doctrine.

Local first

Each country’s tax, regulatory and data requirements at the head of the scoping, not in an appendix. The common model must absorb the differences without turning them into custom developments.

The first step

A scoping exercise of a few weeks: assessment, compared scenarios, roadmap in waves. Then a decision at general management level.

To go further: our SAP S/4HANA offering, our approach from scoping to delivery, and our point of view on the data foundation, which is most often built in the same movement.