The ERP programme steering pack has a go-live date on its first page. For the CFO the more important date sits a few weeks later: the first quarter-end close on the new system, when the auditors arrive, the blocked-invoice list has a new shape, and some of the reports finance relied on no longer exist. SAP ECC end of maintenance is what put that date in the plan, so it is worth being precise about what SAP has said.
The SAP ECC end of maintenance dates
SAP announced its current maintenance strategy on 4 February 2020. Its Support Portal states that "SAP will provide mainstream maintenance for SAP Business Suite 7 core applications until end of 2027". SAP ERP 6.0, the release most people mean by ECC, is among them. Customers can then buy optional extended maintenance "from beginning of 2028 until end of 2030", at "a premium of two percent points on the maintenance basis".
| Period | What SAP's page says | Question for finance |
|---|---|---|
| Until end of 2027 | Mainstream maintenance for Business Suite 7 core applications, including SAP ERP 6.0 | Is the finance design for the new system agreed, and is go-live clear of year-end? |
| 2028 to end of 2030 | Optional extended maintenance, at a premium of two percentage points on the maintenance basis | Is the premium in the budget, and what does it cover for your releases? |
| After 2030 | Outside the dates on this page | What does your contract with SAP say? |
Two cautions. Check the releases and enhancement packages you run against SAP's page, because the dates apply to what the page lists. And ask SAP or your implementation partner what each phase includes for your releases, in particular the legal and tax changes finance depends on.
What the deadline means for finance teams
An ERP migration is often run as a technology programme. For finance it is a change to where the controls live.
Controls move. Every automated control tested on ECC, from tolerance settings to approval workflows to duplicate invoice checks, has to be rebuilt and retested in the new system. If you are subject to external reporting on internal control, the auditors will want evidence that the new controls work, not that the old ones did.
Reports disappear. Custom ECC reports finance relies on, often built years ago and owned by nobody, may not be carried across. Inventory them early.
Open items have to move. Open payables, open purchase orders, the GR/IR clearing account and unapplied cash all need a migration approach and a reconciliation at cutover. Master data, vendor records in particular, is a chance to clean up, and a risk if it is copied over as it is.
Timing collides with the calendar. Go-live near a year-end puts cutover, close and audit in the same weeks.
Keep controls and exception management stable through the move
The control objectives do not change because the ERP does. Invoices should still match orders and receipts, bank detail changes should still be verified, and payments should still be approved by someone with authority. Write those objectives down independently of ECC before the programme starts, with an owner for each. Then map how each will be met in the new system and how it will be tested.
Exception queues are the other thing to protect. Blocked invoices, unmatched receipts and unapplied cash often rise around cutover, while people are learning new screens. A few practical steps help:
Why a read-only layer can carry across the move
A management layer that reads the ERP, shows exceptions, owners and age, and keeps its own record of decisions is described in business terms: an invoice, an order, a receipt, a vendor. Those objects exist on both sides of a migration. When the ERP changes, the data connection has to be rebuilt and tested against the new system's data model. The queues, the owners and the history of decisions can stay as they were.
So the exception process people know keeps running while the system underneath changes. There are limits. The connector is real work, and data model changes in the new system, such as how vendors are held, need careful mapping. A layer does not replace the ERP's own controls, and it is no reason to delay the migration.
SAP's own direction is also visible. Its Joule accounts payable page, published on 6 October 2026, lists agents including an "Accounts Payable Payment Exception and Resolution Agent", a "Bank Account Validation Agent" and a "Payment Risk Insights Agent". Teams moving to SAP's current products will want to assess these alongside anything they build or buy. The questions about access, logging and sign-off are the same for each.
What a new ERP will not fix
It will not fix master data or unclear ownership. Moving a process nobody owns into a newer system gives you an unowned process with a newer interface.
It will not make exceptions go away. They change shape, and for the first few closes there may be more of them, so staff for that.
Frequently asked questions
When does SAP ECC mainstream maintenance end?
SAP's Support Portal states that mainstream maintenance for SAP Business Suite 7 core applications, including SAP ERP 6.0, runs until the end of 2027.
What is SAP extended maintenance and what does it cost?
Extended maintenance is an optional period from the beginning of 2028 until the end of 2030, which SAP prices at a premium of two percentage points on the maintenance basis.
Do the 2027 dates apply to every ECC system?
Not necessarily in the same way. Check the releases and enhancement packages you run against SAP's maintenance page and your contract, because the dates apply to what SAP lists.
What should finance do before an ECC migration?
Write down the control objectives and exception owners independently of ECC, inventory the reports finance relies on, plan how open items will move, and keep go-live clear of year-end where possible.
Can finance controls stay the same through a migration?
The control objectives can stay the same, but their implementation changes. Each automated control has to be rebuilt and retested in the new system before it can be relied on.
Where CFOLogic fits
We design and build management layers over finance processes that read from the ERP without changing it, so the exception routine and its record are not tied to one system. Anything sent outside finance is signed off by a person. Our purchase-to-pay Command Center, shown on a fictional company, is designed to read from SAP in production and never write to it.