Migration Urgency Is Not Binary
Every SAP leader knows the calendar. ECC mainstream maintenance ends in December 2027. Extended maintenance buys time through 2030, maybe 2033 if you negotiate hard enough. The question of whether to migrate has been settled for years.
What has not been settled is when. And the honest answer is that most organizations are terrible at answering it. They default to "soon" without defining what soon means, or they build a timeline backward from the deadline without accounting for their actual system complexity. Both approaches fail in predictable ways.
The problem is that migration urgency is not binary. It is not a switch that flips from "we have time" to "we are in trouble." It is a gradient, and most organizations drift into the danger zone without recognizing the signals. By the time the urgency is obvious, the timelines have already compressed past the point of comfortable execution.
What follows are five diagnostic indicators — based on patterns we see repeatedly across SAP landscapes — that distinguish "plan to migrate" from "migrate now." If you recognize three or more of these in your own environment, your window is narrower than you think.
Sign 1 — Your Custom Code Exceeds 20,000 Objects
Custom code is the single largest variable in any S/4HANA migration timeline. Not the database size. Not the number of company codes. Not even the integration complexity. It is the volume and depth of custom ABAP that determines whether your migration takes 12 months or 36.
Here is why the 20,000-object threshold matters. SAP provides the Custom Code Migration Worklist — a tool that analyzes your custom objects against a catalog of incompatibilities with S/4HANA. Objects that reference deprecated data models, obsolete function modules, or removed transactions all get flagged for remediation. The remediation itself ranges from trivial (swapping a function module call) to significant (rewriting entire custom transactions built on data structures that no longer exist in S/4HANA).
At fewer than 10,000 custom objects, remediation is typically manageable within a standard project timeline. Your developers can work through the worklist in parallel with other migration activities. Between 10,000 and 20,000 objects, you need a dedicated remediation workstream and should plan for surprises. Above 20,000 objects, custom code remediation becomes a project unto itself — one that needs to start before the formal migration project kicks off.
Use transaction SCMON (Custom Code Migration Analysis) to get a realistic picture. Do not rely on rough estimates or the number of transports in your system. SCMON gives you an actual count of affected objects, categorized by the type of change required.
The math is straightforward. If you have 25,000 custom objects and even 30% require some form of remediation, that is 7,500 objects to touch. At an optimistic rate of 5 objects per developer per day, you need 1,500 developer-days of remediation work. That is 7 developers working full-time for almost a year — just on custom code, before you even start the technical migration.
If your custom code count is above 20,000 and you have not started remediation analysis, you are already behind. Every month of delay adds to the compression at the end.
Sign 2 — You Cannot Apply Support Packs Within 90 Days
This is the diagnostic signal that most Basis teams feel in their gut but rarely articulate to leadership: if applying a support pack stack takes longer than 90 days from release to production, your system has accumulated enough technical debt to make migration significantly harder than it needs to be.
Support pack application is a proxy for system health. A well-maintained ECC system with clean modifications, proper upgrade adjustments, and documented dependencies can absorb a support pack in a few weeks of testing and a weekend cutover. When that process stretches to months, it reveals structural problems:
- Modification adjustments that no one understands — someone modified standard SAP code years ago, and the person who did it is long gone. Every support pack triggers SPAU adjustments that require archaeology to resolve.
- Test coverage gaps — there is no reliable regression test suite, so every support pack requires extensive manual testing across business processes. The testing itself takes longer than the technical work.
- Environment sprawl — the landscape has accumulated extra systems (sandboxes, training clients, project systems) that all need to be patched in sequence, multiplying the effort.
- Downtime sensitivity — the business cannot tolerate the maintenance windows that patching requires, so patches get deferred, which makes the next round even harder.
Every one of these problems will be amplified during an S/4HANA migration. Modification adjustments become full custom code remediation. Test gaps become migration validation gaps. Environment sprawl becomes landscape consolidation complexity. Downtime sensitivity becomes cutover weekend planning nightmares.
If your organization treats support packs as an annual grudge match rather than a routine quarterly activity, that friction is telling you something about your migration readiness. The technical debt that makes patching painful is the same debt that will blow up your migration timeline. Address it now, or budget for it later at a premium.
For guidance on tackling the underlying performance and technical health issues, our SAP HANA performance tuning guide covers the database layer, and the principles apply equally to pre-migration system optimization.
Sign 3 — Your Basis Team Is Spending More Than 40% of Time on Maintenance
Ask your Basis team lead a simple question: what percentage of your team's time goes to keeping the current system running versus improving it or preparing for the future?
If the answer is above 40% on maintenance and firefighting, you have a capacity problem that directly threatens your migration timeline. Here is the vicious cycle:
- High maintenance load means Basis has no bandwidth for migration planning.
- No migration planning means the project starts later, with a shorter runway.
- A compressed timeline means the migration project demands intense Basis involvement.
- Intense migration demands on top of existing maintenance load means something breaks — either the migration timeline slips, or production stability suffers. Usually both.
The signs of an overtaxed Basis team are specific and measurable:
- Recurring unplanned downtime — the same types of issues keep coming back because there is no time for root-cause analysis
- Transport backlogs — changes pile up in queues because Basis cannot process them fast enough
- Deferred operating system and database patches — the team knows they should patch, but there is always something more urgent
- No disaster recovery testing — everyone assumes the DR setup works, but no one has tested a failover in the last 12 months
- Documentation debt — system configurations, landscape diagrams, and runbooks are outdated or nonexistent
A Basis team that is treading water cannot simultaneously run a migration. You have two options: reduce the maintenance burden (through automation, system consolidation, or managed services) or add dedicated migration capacity (through hiring or engaging an external partner). Doing neither and hoping the existing team can absorb a multi-year migration project on top of BAU operations is how migrations fail.
This is where our S/4HANA migration services can help — augmenting your internal team with dedicated migration capacity so your Basis staff can keep production stable while the migration moves forward.
Sign 4 — Your Integration Landscape Has Undocumented Interfaces
This sign is the sleeper. It does not feel urgent until you are three months into a migration project and discover that a critical business process depends on an RFC connection that nobody knew existed.
Modern SAP landscapes do not operate in isolation. Your ECC system talks to dozens — sometimes hundreds — of external systems through a mix of integration technologies: IDocs, RFC connections, BAPIs, web services, flat file interfaces, middleware platforms, direct database connections, and API calls. In a well-governed environment, every interface is documented, monitored, and owned by someone.
In reality, most landscapes have shadow integrations — interfaces that were set up years ago for a specific project, never formally documented, and now silently support a business process that someone depends on. Common culprits include:
- Direct RFC connections between ECC and satellite systems, set up by a developer who has since left the company
- Flat file exports running on OS-level scheduled jobs that feed downstream reporting systems
- Database-level integrations where an external system reads directly from SAP tables (a support nightmare during any database migration)
- Middleware routes in PI/PO or third-party tools that were configured outside of change management
- Spreadsheet extracts that someone automated with a macro and an SAP GUI script
Before migration planning can begin in earnest, you need a complete interface inventory. This means running transaction SM59 for RFC destinations, WE20/WE21 for IDoc partner profiles and ports, reviewing PI/PO configuration, and scanning for OS-level jobs and scripts. But the technical scan is only half the work — you also need business process owners to validate which interfaces are still active and which are artifacts of past projects.
If your integration landscape includes PI/PO and you have not yet planned for its migration, our PI/PO to Cloud Integration migration guide lays out the decision framework. Integration middleware migration is often a project within the project, and discovering it late is a common source of timeline overruns.
The rule of thumb: if you cannot produce a complete, current interface map within two weeks, your integration landscape is not ready for migration planning. Start the discovery process now, even if the migration itself is a year or more away.
Sign 5 — Key Personnel Are Within 3 Years of Retirement
This is the signal that no one wants to talk about, and it is the one that cannot be recovered from once it plays out.
Your SAP system was configured and customized over 15 to 25 years by people who accumulated deep institutional knowledge along the way. They know why that one pricing condition type has a special routine. They know which batch jobs must run in a specific sequence on month-end. They know the workaround for that one ABAP program that breaks when a certain material type is used. None of this is written down.
When those people retire — and in many organizations, the core SAP team skews toward the 50-60 age bracket — that knowledge walks out the door permanently. This is not a gradual fade. It is a cliff. One day you have someone who can explain every customization decision made since the 2005 implementation. The next day you do not.
The migration implications are severe:
- Custom code remediation requires understanding why the code was written, not just what it does. Without the original developer's context, remediation takes 2-3x longer.
- Business process validation during migration requires someone who knows how the process actually works versus how it was documented (these are rarely the same thing).
- Cutover planning depends on people who understand the interdependencies between systems, batch jobs, and business calendars.
- Post-migration support needs people who can distinguish "the system is working differently because of S/4HANA changes" from "something is actually broken."
The planning horizon matters. If key personnel are within 3 years of retirement and you have not started the migration, you are betting that you can complete an 18-30 month migration project while those people are still available. That math does not leave room for delays, scope changes, or the normal messiness of large SAP projects.
Start knowledge transfer now. Document tribal knowledge systematically. And factor personnel availability into your migration timeline as a hard constraint, not an assumption.
The Self-Assessment Scorecard
Rate your organization on each of the five signs using the scale below. Be honest — this scorecard is only useful if it reflects reality.
| Sign | 0 Points | 1 Point | 2 Points |
|---|---|---|---|
| Custom code volume | Fewer than 10,000 objects | 10,000–20,000 objects | More than 20,000 objects |
| Support pack velocity | Applied within 90 days | Applied within 6 months | Takes longer than 6 months or skipped |
| Basis maintenance load | Under 30% on maintenance | 30–40% on maintenance | Over 40% on maintenance |
| Integration documentation | Full, current interface map exists | Partial documentation with known gaps | No comprehensive inventory |
| Personnel risk | Key staff 5+ years from retirement | Key staff 3–5 years from retirement | Key staff within 3 years of retirement |
Interpreting Your Score
0–3 points: Plan mode. You have time to be deliberate. Build a solid migration roadmap, evaluate your brownfield vs. greenfield options, and start pre-migration activities like custom code analysis and integration documentation at a comfortable pace.
4–6 points: Accelerate. Your window is narrower than the calendar suggests. Start migration planning activities immediately, even if the formal project has not been approved. Run SCMON, begin interface discovery, and get Basis capacity planning on the leadership agenda. The true cost of delaying migration compounds faster than most organizations realize.
7–10 points: Urgent. Multiple compounding risk factors are present. A standard 24-month migration timeline may not be available to you given your starting position. You need to engage migration partners now, secure executive sponsorship immediately, and consider parallel workstreams (custom code remediation, integration discovery, and knowledge transfer running simultaneously) rather than sequential phases.
What Comes Next
If your score landed in the accelerate or urgent range, the worst thing you can do is treat this as information to file away. The signals described above are compounding — they get worse over time, not better. Custom code grows. Technical debt accumulates. People get closer to retirement.
The next step is a structured assessment. Not a generic slide deck from a vendor — a diagnostic that maps your specific landscape, quantifies your remediation effort, models your realistic timeline, and identifies the resource gaps you need to fill.
Our team specializes in exactly this kind of pre-migration assessment. Whether you need a full S/4HANA migration engagement or a strategy for ECC extended support while you prepare, we can help you build a plan that accounts for your actual starting position — not a theoretical one.
The deadline is fixed. Your preparation timeline is not. Start now.