The thesis: the scoping question is “is it used”, and finance answers it badly.
Most writing about the 2027 date is about the date. That part is settled and public. SAP announced it on 4 February 2020 and has published it on its support site ever since: mainstream maintenance for the SAP Business Suite 7 core applications until the end of 2027, optional extended maintenance from the start of 2028 to the end of 2030 at two percentage points more on the maintenance basis, and customer specific maintenance after that. Nothing about those dates is a surprise and there is no useful new thing to say about them.
The interesting question is what a finance team should do with the time. SAP’s own migration tooling gives a surprisingly precise answer, and it is not the one most programme plans assume. Before a conversion, custom code is scoped: the Custom Code Migration app compares the custom objects against usage data and helps identify which are actually used, and unused objects can be removed with a deletion transport during the conversion. The guide describes scoping as determining the ABAP custom code that is frequently used and needs to be taken over.
Frequently used is a reasonable test for most of an ERP and a poor one for finance. Year end revaluation runs once. Balance carryforward runs once. The statutory report layout that three entities depend on runs once. A quarterly disclosure extract runs four times. None of these is frequently used and none of them is optional. SAP knows this, which is why the same guide recommends collecting usage data with the ABAP Call Monitor and transaction SUSG for at least one year, and states the reason plainly: so that usage data of quarter and year ending functionality is considered.
That single sentence is the most actionable thing in the entire migration literature for a finance team, and it has a deadline attached that is much closer than 2027. If the sample has to cover a year, the collection has to start a year before the decision. Starting it in August 2026 produces a complete year in August 2027, comfortably inside the mainstream window. Starting it when the programme kicks off produces a scope built on a quarter of evidence and a lot of confidence.
The published dates, and what the installed base is actually doing.
Worth setting out precisely, because the shorthand version of this timeline is wrong in both directions. It is not a cliff at the end of 2027, and it is not open ended either.
| When | What is published | Worth knowing |
|---|---|---|
| 4 February 2020 | SAP announces a maintenance commitment for SAP S/4HANA until the end of 2040, and mainstream maintenance for SAP Business Suite 7 core applications until the end of 2027. | The dates have been public for six years. What has changed since is how much runway is left to use them well. |
| Through 31 December 2027 | Mainstream maintenance for the SAP Business Suite 7 core applications, including SAP ERP 6.0, SAP CRM 7.0, SAP SCM 7.0 and SAP SRM 7.0, covering the latest three enhancement packages. | This is the period most plans are drawn against. From August 2026 it is about sixteen months. |
| 1 January 2028 to 31 December 2030 | Optional extended maintenance, at a premium of two percentage points on the maintenance basis for all support offerings in scope of SAP Business Suite 7. | Three more years, priced. Choosing it is a budget decision that a finance team is well placed to make once it knows what is actually in scope. |
| After extended maintenance | Customers who do not take extended maintenance, or whose extended maintenance has ended, receive customer specific maintenance. | A different support posture rather than a cliff, and worth understanding precisely rather than by reputation. |
| 26 February 2026 | The DSAG Investment Report 2026 reports 54 percent of surveyed members still using SAP ECC or the older Business Suite, down from 68 percent in 2024, with 56 percent on S/4HANA on premise. | The installed base is moving steadily rather than suddenly. Both systems are live in a lot of landscapes at once. |
| Stated target dates | Among DSAG respondents still investing in SAP ECC, almost half plan to switch by the end of 2030, 37 percent by the end of 2027, and 4 percent by the end of 2033. | Almost half are therefore planning around extended maintenance. That is a deliberate purchase of time, and time is only useful if something is done with it. |
The DSAG figures are worth dwelling on because they describe a population that has already made this decision, rather than one that is avoiding it. Almost half of the respondents still investing in SAP ECC intend to move by the end of 2030, which is a choice to buy three extra years at a known price. DSAG’s own reading is that these are not organisations planning to wait, but organisations that need the time because their landscapes are complicated. That is a fair description of most groups with a real finance estate, and it means the planning horizon for a lot of teams is four years rather than sixteen months.
What the Simplification List actually says about finance.
SAP publishes the list of what changes. The Simplification List for SAP S/4HANA 2025 is a public white paper running to fifteen hundred pages, and each simplification item names the objects affected and points at the SAP Note describing the impact. Two items carry most of the weight for a finance team, and the distinction they draw is unusually clean.
| Change | What SAP publishes | What it means for custom code |
|---|---|---|
| The universal journal | Simplification item 6.1.23 states that General Ledger in SAP S/4HANA is based on the universal journal, with line items stored in table ACDOCA. Controlling is part of the same journal, so CO internal actual postings are visible in the General Ledger and secondary cost elements sit in the chart of accounts. | One document store instead of several. Custom reports that joined FI and CO by hand are solving a problem that no longer exists. |
| Totals and index tables removed | Item 6.1.4, Data Model Changes in FIN, records that totals records storing General Ledger, Controlling, Material Ledger, Asset Accounting, Accounts Payable and Accounts Receivable data by period have been removed, as have the index tables designed to optimise certain selections. | These are the tables custom finance code reads most: BSIS, BSAS, BSID, BSAD, FAGLBSIS, FAGLBSAS, COSP, COSS, FAGLFLEXT and the asset accounting set. |
| Reads keep working | The removed tables were replaced by identically named compatibility views generated from DDL sources. The document states that the compatibility views ensure database SELECTs work as before. | This is the good news and it is easy to underrate. A custom report that only reads is very likely to keep returning the same answer. |
| Writes do not | The same item states that write access, meaning INSERT, UPDATE, DELETE and MODIFY, was removed from SAP standard or has to be removed from custom code, and points at SAP Note 1976487. | The cleanest possible dividing line for a scoping exercise. Any custom object that ever wrote to a finance totals or index table is in scope, without argument. |
| Currency positions can move | Item 6.1.23 notes that new currencies cannot be introduced in the General Ledger during migration, and that the order and technical field names of currencies in ACDOCA may change, since the controlling area currency type determines the second currency. | Custom code that addresses a currency by field position rather than by currency type is the kind of defect that produces plausible numbers. |
| It is a conversion, not an upgrade | Item 6.1.23 says plainly that the move is not a normal upgrade but a system conversion which comes with some incompatible changes, referring to summary and index table usage and the update of table BSEG. | Worth quoting to anyone who has scheduled the finance testing effort as though it were a support package. |
The read and write split deserves to be the first slide of any finance scoping session. It means a large custom reporting estate, which is what most finance departments have accumulated over twenty years, is much less exposed than it feels. Compatibility views were built so that SELECTs keep working. It also means the exposure that does exist is precisely locatable: an object that writes to a totals or index table is in scope, and the question of whether it is in scope is not a matter of judgement.
The currency point is the one that tends to be found late. Item 6.1.23 states that new currencies cannot be introduced during migration and that the order and technical field names of the currencies in ACDOCA may change, because the currency type of the controlling area determines the second currency. Compatibility views keep the old reporting consistent, but custom code that addresses a currency amount by field position rather than by currency type will keep running and produce numbers that look reasonable. Those are the expensive defects.
The sampling problem, drawn out.
Every finance process has a cadence, and the cadence determines whether a usage sample can see it at all. This is arithmetic rather than opinion, which is what makes it useful in a planning conversation.
| Cadence | Typical finance objects | What a short sample sees |
|---|---|---|
| Daily and weekly | Order entry validations, invoice posting exits, payment proposal enhancements, bank statement mapping. | Seen by any usage sample. These are almost never the objects that get missed. |
| Monthly | Accruals, allocations, recurring entries, intercompany matching, foreign currency valuation, custom month end reports. | Seen by a three month sample, but with only two or three observations. Enough to appear, not enough to characterise. |
| Quarterly | Segment and disclosure extracts, tax provision inputs, covenant packs, quarterly consolidation adjustments. | A three month sample sees one of these at best, and may see none at all depending on when it starts. |
| Annually | Year end revaluation, balance carryforward variants, statutory report layouts, fixed asset year close, annual rate resets, the audit extract nobody has changed since it was written. | Invisible to any sample shorter than a year. This is the category SAP’s own guidance is written to protect. |
| Event driven | Acquisition integration mappings, restatement helpers, one off migration objects that were never retired. | May not run in a full year either. These need a human decision rather than a usage statistic, and naming them is half the work. |
The last row is the one that no amount of collection time solves. An acquisition mapping written in 2019, a restatement helper, a migration object that was never retired: these may not run in a full year and still cannot be deleted without someone confirming it. Usage data answers the question of what runs. It cannot answer the question of what matters, and a register that records the difference is what stops the two from being confused.
The register this asks for.
None of this needs a new tool. SAP Readiness Check, the Simplification Item Check and the Custom Code Migration app already produce the object list, the findings and the usage evidence, and the Getting Started guide recommends running them early in the project so that the required adaptations are known up front. What they cannot produce is the accounting meaning of each object, and that is the column the whole exercise turns on.
object_id
The technical name of the custom program, table, field, enhancement or exit. One row per object, so the register can be reconciled against the tool output rather than argued about.
accounting_rule
What this object actually does in accounting terms, written in a sentence a controller would recognise. Not the technical description. This is the field that turns an inventory into a register, and it is the one that only finance can fill in.
posting_effect
Whether the object changes a posting, changes a balance, changes a report, or changes nothing that reaches the ledger. The scoping conversation is completely different for each of these, and they are frequently conflated.
run_cadence
Daily, monthly, quarterly, annually, or event driven. Recorded from how the business uses it rather than from a usage counter, so that a low count and a low importance are not treated as the same fact.
usage_window_covered
The period the usage data actually spans. A register that says the sample covered ninety days is honest about what its own evidence can support.
writes_to
Which tables the object writes to, with the finance totals and index tables flagged explicitly. This is the field that maps straight onto the published simplification items.
standard_equivalent
Whether standard functionality now covers this, and which. A good share of custom finance code was written to work around a gap that the universal journal closed years ago.
decision
Rebuild, retire, replace with standard, or defer with a named reason and a date. Every row gets one, and a blank is itself a finding.
owner
The named person in finance who can defend the decision. Not the developer who wrote it, and not the programme manager. If nobody in finance will own a rule, that is useful information about the rule.
evidence_link
Where the supporting output lives: the ATC finding, the usage snapshot, the control narrative, the sign off. An auditor asking why a rule changed should reach the answer in one hop.
One row of a finance extension register, with its evidence attached
{
"object_id": "ZFI_FX_REVAL_YEAREND",
"object_type": "ABAP report",
"accounting_rule": "Applies the group year end rate to open items in three legacy entities where the standard valuation method was not configured, and posts the difference to a dedicated FX account.",
"posting_effect": "changes_a_posting",
"run_cadence": "annually",
"usage_window_covered": {
"source": "SCMON via SUSG",
"from": "2025-08-01",
"to": "2026-07-31",
"executions_observed": 1
},
"writes_to": ["BSIS", "ACDOCA"],
"totals_or_index_write": true,
"standard_equivalent": {
"exists": true,
"note": "Standard foreign currency valuation covers this once the three entities are configured consistently."
},
"decision": {
"outcome": "replace_with_standard",
"reason": "The rule is a configuration workaround rather than a policy difference.",
"target_date": "2027-03-31"
},
"owner": "group.controller@example.com",
"evidence_link": "https://internal.example.com/erp-register/ZFI_FX_REVAL_YEAREND",
"reviewed_at": "2026-08-18"
}Three fields in that record do most of the work. The accounting_rule field is the translation step, and writing it is where a surprising number of objects quietly resolve themselves, because a rule that nobody can state in accounting terms is usually a rule nobody needs. The usage_window_covered field keeps the evidence honest, so that a decision made on ninety days of data is visibly a decision made on ninety days of data. And the decision field forces a verdict on every row, with a blank counting as a finding rather than as a pass.
The standard_equivalent field earns its place for a different reason. A large share of custom finance code was written to work around a gap, and several of those gaps closed when the universal journal brought Controlling and the General Ledger into one document store. Asking the question per object rather than per module is what surfaces those, and each one found is an object that gets deleted rather than migrated.
Implementation checklist.
Turn on usage collection now, before anything else. SAP’s Custom Code Migration Guide recommends the ABAP Call Monitor, transaction SCMON, with aggregation through transaction SUSG in the production system, and it recommends collecting for at least one year. If aggregation is not already active, the guide says to activate it now. Starting the clock in August 2026 gives a full year that closes well inside the mainstream maintenance window.
Say out loud what the sample covers. If the decision has to be made before a year of data exists, that is workable, but the register should record the window rather than let a ninety day sample pass as a year. A documented gap is manageable. An undocumented one is what produces the surprise.
Run the published pre work early rather than as a gate. The Getting Started guide recommends running the Maintenance Planner, the Simplification Item Check and the Custom Code Migration worklists early in the project so that the required adaptations are known up front. These produce the technical inventory the register is built on.
Split the inventory by what the object does to the ledger before splitting it any other way. Objects that change a posting, objects that change a balance, objects that only change a report, and objects that touch nothing financial are four different conversations. Sorting by application component instead mixes them.
Flag every object that writes to a finance totals or index table. The Simplification List is explicit that reads through the compatibility views work as before and that writes had to be removed from standard or have to be removed from custom code. That single test partitions a large inventory into a small mandatory set and a large optional one.
Write the accounting rule for each surviving object in plain language. If nobody can say what a custom field means in accounting terms, the honest options are to find out or to retire it, and both are better than carrying it forward untranslated.
Check custom currency handling specifically. New currencies cannot be introduced during migration, and the order and technical field names of currencies in ACDOCA can change because the controlling area currency type determines the second currency. Code that reaches for a currency by position needs to reach for it by type.
Treat the retire pile as the main prize rather than the leftovers. The Custom Code Migration app can create a deletion transport for unused code during the conversion, which means the work of deciding is captured as an artefact rather than a memo. Every object retired now is one that never has to be tested, migrated or explained again.
Name a finance owner per surviving rule, and let a missing owner be a finding. An unowned custom posting rule is a control question regardless of what happens to the ERP, so the register earns its keep even if the migration date moves.
Book the extended maintenance decision as a dated choice with a number attached. Two percentage points on the maintenance basis for the years from 2028 to 2030 is a knowable figure. Comparing it against a scope that the register has actually measured is a much better conversation than comparing it against a fear.
Sequence it by what has a clock on it. Turning on usage collection is the only item here that gets worse the longer it waits, because the evidence it produces is measured from the day it starts. Everything else can be done in any order and improves whenever it happens. That makes the first step small, cheap and independent of whether a programme has been approved, which is a good property for a first step to have.
Constructive failure modes to design around.
Reading a low usage count as low importance. The year end revaluation that ran once in twelve months and the report nobody has opened since 2019 look identical in a usage table and could not be less alike. The cadence field exists to keep those two facts apart, and it has to be filled in by someone who knows the close.
Scoping from a short usage sample because the project timeline is short. SAP’s guidance names the reason for the one year window directly, which is that quarter and year ending functionality is considered. A shorter sample is a legitimate compromise as long as the register says so and the annual objects are enumerated by hand instead.
Assuming every custom finance object breaks. Compatibility views were built precisely so that SELECTs continue to work as before. A read only report is likely to survive, and saying so early keeps the effort pointed at the objects that genuinely need it.
Assuming no custom finance object breaks because the reads pass a test. Write access is the part that had to change. A test cycle that exercises reporting and never exercises a custom posting path will look clean and prove very little.
Treating this as an IT inventory with a finance review at the end. The technical tools produce object lists and finding counts. Deciding whether a rule is a policy or a workaround is an accounting judgement, and it is much cheaper to make it while the list is being built than to revisit it during a test cycle.
Rebuilding a workaround faithfully. A meaningful share of custom finance code exists because something was not configured, not because the business needed something different. The register makes that distinction visible by asking, for every object, whether a standard equivalent now exists.
Letting the deadline choose the transition path. SAP publishes three: system conversion, selective data transition, and new implementation. The right one depends on how much of the current design is worth keeping, which is exactly what the register measures. The measurement should come before the choice, not after it.
Losing the register once the project ends. The artefact being built here is a map of every place a posting is decided by something other than standard configuration. That has a life well beyond a migration, and filing it with the project closure documents wastes most of its value.
The common thread is treating a measurement as a judgement. A usage counter measures executions. A findings report measures syntax and object references. Both are accurate and neither knows whether a rule reflects an accounting policy or a configuration shortcut. The register exists to hold that second layer of information next to the first, so that the decisions are made by people who can defend them.
What to ask an implementation partner now.
Can we get the usage data and the ATC findings as data we can join, rather than as reports we read? The register only works if the technical inventory and the finance annotations live in the same place.
Which of these objects write to a finance totals or index table, listed explicitly? This is a mechanical question with a definite answer, and it should not require an interpretation.
How long does the usage sample behind this scope actually cover, and which annual processes fell inside it? A scope proposal that cannot answer this is a scope estimate.
For each custom posting rule, what is the standard equivalent today, and what stops us using it? Asking this per object rather than per module is what separates a real assessment from a summary.
Which objects are you proposing to carry forward unchanged, and what evidence supports that? Carrying forward is a decision like any other and deserves the same record.
How is the retire list captured, and does it become a deletion transport during the conversion rather than a spreadsheet nobody actions?
Who signs off the accounting meaning of each surviving rule, and what does that person get to read before signing? If the answer is a technical object list, the sign off is not a sign off.
If the extended maintenance window is taken, what does the plan look like across 2028 to 2030, and which parts of the register does the extra time actually change?
A partner who has run this work before will have good answers ready and will usually be pleased to be asked, because these questions make the scope smaller and more defensible rather than larger. Ask them during scoping rather than during a test cycle, while the answers can still change what gets built.
Practical takeaway.
There is more runway here than the headline date suggests, and the work that uses it best is unglamorous and cheap. Mainstream maintenance runs to the end of 2027 and three further years are purchasable at a published price. The list of what changes in finance is already written down, and it draws a clean line: reads through the compatibility views work as before, writes to the finance totals and index tables have to change. The one thing with a clock on it is evidence. SAP asks for a year of usage data so that quarter and year ending functionality is counted, which means the useful first move is to start collecting it and to write down, one object at a time, what each custom rule actually means in accounting terms. Do that and the migration scope becomes a measured number instead of an estimate. Do it and never migrate, and you still end up with a documented map of every place a posting is decided by something other than standard configuration, which is worth having on its own.
Sources.
- SAP Support Portal: Innovation Commitment for SAP S/4HANA until 2040, Clarity and Choice on SAP Business Suite 7. The source of the end of 2027 mainstream maintenance date, the 2028 to 2030 extended maintenance window, the two percentage point premium, and the customer specific maintenance position after that
- SAP News, 4 February 2020: SAP Extends Its Innovation Commitment for SAP S/4HANA, Provides Clarity and Choice on SAP Business Suite 7. The original announcement, naming the products in scope and the maintenance periods
- SAP Help Portal: Custom Code Migration Guide for SAP S/4HANA 2025, public how-to guide dated 25 February 2026. Downloaded and read directly, including the scoping recommendation to collect usage data with SCMON and SUSG for at least one year so that quarter and year ending functionality is considered
- SAP Help Portal: Simplification List for SAP S/4HANA 2025, Feature Pack Stack 1, public white paper version 1.36 dated February 2026. Source of simplification item 6.1.4 Data Model Changes in FIN, item 6.1.23 General Ledger, the compatibility view mechanism, and the removal of write access from the finance totals and index tables
- SAP Help Portal: Getting Started With SAP S/4HANA 2025, public guide version 2.0 dated 25 February 2026. Source of the three published transition paths, the recommendation to run the Maintenance Planner, Simplification Item Check and Custom Code Migration worklists early, and the scope of SAP Readiness Check
- DSAG, 26 February 2026: DSAG Investment Report 2026. Survey of 198 member company representatives across Germany, Austria and Switzerland between 8 December 2025 and 21 January 2026, source of the installed base and target date figures quoted here
Every date, percentage and simplification item reference above was taken from the primary document rather than from a summary. The three SAP guides are public PDFs and were downloaded and read directly rather than fetched through a summariser, which matters on documents of this size: the Simplification List alone runs past fifteen hundred pages and the finance items quoted here sit in section 6.1. The maintenance dates were read from SAP’s own support page and cross checked against the original press release of 4 February 2020. The DSAG figures were read from the association’s English language press release of 26 February 2026, including its stated survey basis of 198 respondents gathered between 8 December 2025 and 21 January 2026. No public posts on X are cited in this article. Candidate posts on the 2027 timeline and on custom code scoping could not be verified as current, public and relevant from a logged out session, and nothing has been invented to fill the gap. The register record shown above is a worked example of the shape being described and is not an extract from any customer system. SAP Notes referenced inside the public guides, including 1976487 on write access to the replaced tables and 2270333 on the finance data model changes, require an SAP login and are named here rather than quoted.