The 2027 SAP ECC deadline: what data reduction looks like 18 months out

he slide has been on the wall in every SAP customer's planning room for two years: SAP ECC mainstream maintenance ends in 2027. The teams have looked at it, planned around it, and discussed it.

What most of them have not done is back the calendar out. If the migration must complete by end-of-2027, and a typical brownfield conversion runs nine to twelve months from cutover-design lock, then the design lock is mid-2026. Every workstream that feeds the design lock — including the archiving design that determines the sizing — is on the same calendar.

Sitting in mid-2026, the question is no longer when do we start the archiving design? It is have we already missed the window where archiving makes a difference to the migration we are committing to?

This is the calendar conversation that has not been load-bearing until now, and is suddenly the most load-bearing decision the program has left to make.

Step One — The Wrong Assumption

We have until end of 2027.

"The deadline is 2027. We have time to plan the archiving in the next phase."

— Position held in many programs through 2025

The assumption treats the maintenance deadline as the program deadline. They are different. The maintenance deadline is when SAP stops providing standard support; the program deadline is when the migration has to be in production, which is earlier — typically a quarter ahead — to allow stabilization. And the design-lock date that drives the migration is earlier still. By the calendar, mid-2026 is the design-lock window for an end-of-2027 production date.

Step Two — The Partial Signal

The migration timeline gets backed out, and the archiving window collapses.

The partial signal is the migration plan itself. Once the program team backs out the calendar from the maintenance deadline, the design-lock date appears, and the archiving design has to be complete by that date — because the archiving design determines the HANA sizing, which determines the procurement, which determines the lead time on the platform that the migration will land on. Programs that have not started the archiving design by the back-out date are committing to migration sizing that does not reflect any data reduction.

Step Three — The Failed Fix

Extended maintenance as the relief valve.

The failed fix is the maintenance extension. SAP has published an option for extended mainstream maintenance through end-of-2030 for a fee.[1] The extension is real, and it gives the program three more years of standard support. It does not, however, change the underlying calendar pressure: the program still has to complete the migration eventually, the archiving design still has to feed the sizing, and the recurring HANA cost on the unreduced dataset compounds every quarter of delay. The extension buys time; it does not buy reduction.

The fix is failed when the extension is treated as a way to defer the archiving design, because the archiving design becomes more expensive — not less — every quarter of delay, as the dataset grows.

Fig. 1 — The maintenance deadline is end-2027. The design-lock date that determines the migration sizing is mid-2026. The archiving design has to be on the same calendar.

Step Four — The Real Failure

The actual failure is calendar separation.

The real failure is treating the archiving design and the migration design as two separate workstreams on two separate calendars. They are one workstream on one calendar, with the archiving feeding the sizing that drives the migration. Programs that have run them together are entering 2026 with the design lock close to ready and the HANA sizing close to optimal. Programs that have run them apart are entering 2026 with a design lock that reflects an unreduced dataset, which fixes the recurring cost at the highest end of the available range for the platform's lifetime.

Eighteen months out, the calendar still permits a productive archiving design. Twelve months out, the calendar starts to compress. Six months out, the design is whatever can fit in the time available, which is usually "none" — and the migration crosses the unreduced dataset by default.

Step Five — The Definition

Now the definition lands.

Pre-migration archiving on the SAP maintenance calendar is the discipline of running the archiving design on the same calendar as the migration design, so that the data-reduction work feeds the migration sizing rather than following it.

The discipline is fundamentally a sequencing claim: the archiving design has to be ahead of the migration sizing, which has to be ahead of the procurement, which has to be ahead of the cutover. Reversed, the archiving has no effect on what the program commits to.

What Solix Enforces

Archiving design on the same calendar as the migration design, not behind it.

What Solix runs here is the calendar-aligned model: archiving design started against the live ECC system on the same timeline as the migration design, ILM policy and NLS scoped in time to feed the sizing, and the migration sized to a dataset the business actually operates on. The maintenance deadline becomes a date the program meets at the right cost, rather than a date that compresses the program into accepting whatever cost the timeline allows.

Three things to do this week

• Back the calendar out from end-of-2027. Map production date, stabilization window, cutover, design lock, and archiving design against the maintenance deadline. The exercise produces a date for the archiving design that is almost always sooner than the program assumed.
• Treat extended maintenance as time, not as reduction. If the program elects extended maintenance to end-of-2030, treat the extra time as room to do the archiving design properly, not as room to defer it. The archiving has to happen eventually; doing it on a defined calendar is cheaper than doing it under pressure.
• Make the archiving design a steering-committee status item. Add the archiving design to the migration steering committee's regular status, not to a separate workstream's review. The two designs share a calendar and a sizing dependency; the steering visibility should reflect that.

References

• SAP press release — SAP Extends Mainstream Maintenance for SAP S/4HANA and Updates Its Maintenance Strategy. SAP's published maintenance timeline: mainstream maintenance for ECC through end-2027; optional extension to end-2030.
• SAP Help Portal — SAP Information Lifecycle Management (ILM) — Overview. ILM governs the retention design that feeds the archiving on the program calendar.
• SAP Help Portal — Nearline Storage for SAP BW and SAP BW/4HANA. NLS is the cold-tier mechanism that the archiving design has to scope by the design-lock date.
• Gartner press — Gartner Forecasts Worldwide Data Management Software Spending. Gartner's research on SAP migration timelines establishes the broader pattern of design-lock vs. cutover spacing.
• IDC press — IDC Worldwide Global DataSphere Forecast. IDC's analysis of SAP customer migration cadence frames how the maintenance deadline is being interpreted across the install base.