There are about eighteen months left.
On December 31, 2027, SAP’s mainstream maintenance for Business Suite 7 core applications — including ERP 6.0 on Enhancement Packages 6 through 8 — comes to an end. Extended maintenance can buy three more years, to the end of 2030, at roughly a two-percentage-point premium on your maintenance basis. After that, customer-specific maintenance: same invoice, no new security patches, no new legal or regulatory updates, no new HR compliance drops.
Canadian enterprises have watched this date approach for years. Many are still watching. And when you ask CIOs at Canadian manufacturers, utilities, retailers and Crown corporations what’s actually holding up the move to S/4HANA, the answer is rarely licensing, rarely infrastructure, and rarely executive appetite.
It’s the custom code.
Why the deadline lands harder in Canada
The 2027 date is global. The exposure is not evenly distributed. Regulatory updates are not a nice-to-have here. After mainstream maintenance lapses, SAP stops shipping legal change packages. For a Canadian organization, that’s not an abstraction — it’s GST/HST rate and rule changes, provincial sales tax divergence across BC, Saskatchewan, Manitoba and Quebec, CRA electronic filing format changes, T4 and Relevé 1 updates, provincial WCB/WSIB rate tables, EI and CPP thresholds that move every January. Organizations running SAP HCM Canadian payroll are the most acutely exposed: payroll is the one module where “we’ll patch it ourselves next year” translates directly into remittance errors and employee-facing failures. Bilingual and Quebec-specific obligations add surface area. French-language output requirements under Quebec’s Charter — tightened materially by Bill 96 — touch invoices, purchase orders, employee communications, contracts and customer-facing documents. In most Canadian ECC landscapes, that logic lives in custom SAPscript and Smart Forms, custom output determination, and Z-tables of French translations that were never maintained in the standard text repository. Every one of those objects is a migration item. Privacy law has moved underneath the estate. Quebec’s Law 25 and the ongoing federal reform conversation have raised the bar on consent, retention, breach notification and data residency. Running a business-critical ERP with no forward path for security patches is an increasingly awkward position to defend to a board, a privacy officer, or a cyber insurer at renewal. The talent pool is thin and getting thinner. Canada has a comparatively small SAP consulting market. Nearly half of SAP’s installed base globally intends to be off ECC by 2030, which means demand for S/4HANA and ABAP conversion skills peaks precisely in the window most Canadian organizations are currently planning to use. Rates rise, timelines stretch, and the good teams get booked eighteen months out. Starting in late 2027 means competing for the same scarce people as everyone else who waited.The real blocker: twenty years of Z
Most Canadian ECC systems in production today were implemented between 2002 and 2012. They have accumulated somewhere between 8,000 and 40,000 custom objects. Nobody in the current IT organization wrote most of them. The people who did have retired. That code is not evenly problematic. It breaks down into roughly four buckets, and the difference between them determines whether your program is a twelve-month effort or a thirty-month one.- Dead code. In most estates we see, a large fraction of custom objects — frequently 40% or more — have not been executed once in the past year. Reports built for a plant that closed. Interfaces to a system decommissioned in 2015. Copies of copies of a Z-program that was itself a copy. This is the single largest and cheapest win available, and it requires no S/4HANA knowledge at all.
- Code broken by the S/4HANA data model. This is the mechanical, unavoidable category. The simplified data model eliminates aggregate and index tables — BSEG’s index tables, MSEG’s aggregates, KNA1/LFA1 replaced by the Business Partner model. Any custom program that selects directly from those structures, or performs a native SQL join against them, will fail or return wrong results. Canadian estates are particularly heavy here because of custom tax determination logic: a great deal of Canadian GST/HST/PST/QST handling was implemented as Z-routines against condition tables and FI structures rather than through standard tax procedures, precisely because the standard was awkward for multi-jurisdiction Canadian scenarios in 2005.
- Modifications and enhancements to standard. Repairs to SAP objects, user exits, BAdI implementations, and enhancement points. These usually encode real business logic — Canadian freight and customs handling, bilingual document output, provincial payroll rules, industry-specific processes in mining, forestry, oil and gas or utilities. They cannot simply be deleted. They must be re-hosted, and the question is where.
- Code that should never have been code. Requirements met with a Z-program in 2006 that are standard functionality in S/4HANA 2023. Every hour spent remediating these is an hour wasted.
The trap: lift-and-shift the custom code
The most common failure mode in Canadian conversion programs is deciding, under schedule pressure, to remediate everything into the core and move on. Fix the syntax, adjust the selects, get it green, go live. This works. It also reproduces, inside your brand new S/4HANA system, the exact condition that made your ECC system impossible to upgrade — and does so at a moment when SAP has moved to a two-year release cadence with a seven-year support window per release. You will be doing this again. The alternative discipline is the clean core: keep custom logic out of the digital core wherever possible, use released APIs and extension points rather than direct table access, and move genuinely differentiating logic to side-by-side extensions on BTP where it can evolve on its own cycle. Not every object justifies that treatment. But the categorization decision — remediate in core, rebuild as an in-app extension, move side-by-side, replace with standard, or delete — should be made deliberately, object by object, not defaulted by a developer under deadline.What to do in the next ninety days
You do not need a business case to start. You need evidence. Turn on usage instrumentation now. SAP’s Usage Procedure Logging and coverage analysis tools capture which custom objects actually execute in production. This data needs a full business cycle to be trustworthy — including year-end close, which for most Canadian organizations means December or March. If you have not started collecting, every month of delay pushes your decommissioning decisions later. Run the readiness and custom code analysis. The SAP Readiness Check and the ABAP Test Cockpit’s S/4HANA remediation checks will produce an object-level inventory of what breaks. Combined with usage data, this gives you the only number that matters: not “we have 22,000 custom objects” but “we have 3,100 objects that are both used and broken.” Scope Canadian compliance separately. Tax determination, bilingual output, and Canadian payroll deserve their own workstream, their own subject-matter experts, and their own timeline. If you run SAP HCM Canadian payroll, decide early whether you are converting it, moving to Employee Central Payroll, or going to a Canadian payroll provider — this decision has long lead times and drives the rest of the sequence. Decide your end state before you decide your approach. Brownfield conversion, greenfield rebuild, and selective data transition each imply radically different custom code strategies. Choosing the technical approach before you have the code inventory is how programs end up re-scoping in month nine. Book the capacity. If your target go-live is 2028, your integrator selection and contracting should be happening in the next two to three quarters, not the next two to three years.The honest arithmetic
A typical S/4HANA conversion runs 12 to 24 months for a focused brownfield effort, and 18 to 36 months for a program that touches data, integrations and a heavily customized estate. Add three to six months for the discovery and code analysis that should precede it. Count backward from December 31, 2027. If your organization has not yet completed a custom code assessment, the deadline you are actually planning against is 2030 — which means budgeting for extended maintenance, and accepting that you will be buying scarce consulting capacity in the most expensive market this ecosystem has ever had. That is a legitimate choice. It is only a bad one when it’s made by default, in month thirty-four, because nobody looked at the Z code in time. The custom code standing between your current ECC landscape and a clean S/4HANA future is a solvable problem. The variable is not whether AI can accelerate the analysis and remediation. It already can. The variable is whether your team has a human review gate at every step so the output is trustworthy and audit-ready. On August 5, 2iSolutions is running a live executive session showing exactly how this works inside a real SAP landscape. Aditya, Praveen and Richard walk through the workflow, the results, and the governance model. If the 2027 deadline is on your planning horizon, this is a practical hour worth protecting. Schedule an AI Discovery Session to explore how these ideas apply to your specific ABAP estate. The first step costs almost nothing: instrument your production system, pull the custom code inventory, and find out how much of the problem is real. In most Canadian estates, a meaningful share of it isn’t. Reserve your seat: https://events.teams.microsoft.com/event/cf188334-1430-4c35-b369-c06c3f013749@285ec7f4-9284-406f-a32a-c2a386222076
