The Friday-to-Monday Test for SAP Transformation: A Conversation with SNP’s CTO

For SAP customers, transformation success is often measured by technical milestones like whether the migration completed, whether the cutover window held, whether the system came back online, and whether the project hit its target date. Those measures matter, but they do not capture the full operational test. 

The more practical question is whether the business can still do on Monday what it did on Friday. 

That was one of the clearest points from a recent conversation with Steele Arbeeny, CTO of SNP. SAP transformation is not only about moving SAP data, upgrading SAP ECC, or consolidating systems into SAP S/4HANA. It is about preserving the business’ ability to build, ship, maintain, invoice, report, comply, and adapt after the transformation event is complete. 

“You don’t just migrate data, you have to migrate a business,” Arbeeny told SAPinsider. 

That distinction is becoming more important as SAP customers prepare for SAP S/4HANA, cloud modernization, AI, M&A, divestitures, and application retirement at the same time. SAP has said mainstream maintenance for SAP Business Suite 7 core applications runs until the end of 2027, with optional extended maintenance available until the end of 2030. That timeline has kept SAP S/4HANA planning high on the agenda, but many enterprises are discovering the ERP move is only one layer of a larger business data problem. 

The Business Does Not Stop at SAP 

Most SAP customers do not run on SAP alone. Business processes often cross SAP and non-SAP applications, older systems, acquired line-of-business platforms, regional finance tools, manufacturing execution systems, and custom applications that have accumulated over years of growth and acquisitions. 

Arbeeny described a large aerospace customer that began with an urgent ECC-to-S/4HANA modernization challenge. The immediate priority was the SAP conversion. But the broader transformation goal was larger—consolidate old non-SAP systems, standardize manufacturing and plant maintenance, improve compliance, and reduce the need to reconcile business activity across disconnected environments. 

In a sector such as aerospace and defense, those process gaps carry consequences beyond system efficiency. Plant maintenance, equipment reliability, compliance, and bill-of-materials accuracy are not back-office abstractions. They influence safety, quality, reporting, and the speed with which the organization can respond to geopolitical and operational pressure. 

That is the reality many SAP teams face. The SAP migration may be the visible project, but the value depends on whether the organization can simplify the surrounding business landscape. 

Why the Business Case Has to Look Past Go-Live 

Many SAP transformation business cases still concentrate too heavily on the immediate event. Arbeeny argued that SAP customers should build the business case across multiple planning horizons: the immediate problem, the next one to three years, the three-to-five-year modernization path, and longer-term trends such as agentic AI, automation, and emerging data-intensive technologies. 

That does not mean organizations need a perfect 10-year roadmap. The plan will change. The value comes from forcing the business and IT to think through the dependencies before disruption arrives. 

For SAP leaders, that means asking different questions earlier in the program. Which business activities must continue immediately after cutover? Which SAP and non-SAP systems support those activities today? Which historical data is still operationally useful? Which systems should be retired, archived, or decommissioned? Which processes will still require reconciliation if only the SAP side is modernized? 

Those questions move the business case away from system replacement and toward business continuity. They also expose the second-order value that often sits outside the initial SAP program: faster closing cycles, fewer intercompany eliminations, better compliance, more consistent maintenance, cleaner analytics, and less dependence on redundant systems. 

Generic Data Movement Is Not Enough 

The Friday-to-Monday test also changes how SAP customers should think about tooling. Moving data from one system to another is not the same as preserving business meaning. 

Arbeeny distinguished between generic “Extract, Transform, Load” (ETL) and business-aware transformation. ETL tools can move and transform data, but they do not necessarily understand ERP business objects, process dependencies, or the context needed to reconcile data across SAP and non-SAP systems. 

SNP positions Kyano around that broader lifecycle. The platform combines capabilities for assessment, migration, integration, modernization, optimization, validation, archiving, decommissioning, and application retirement. For SAP customers, that broader scope matters because the work rarely ends at the initial SAP S/4HANA move. 

Arbeeny described Kyano as more than a software platform. It is also a process built around business data agility. The goal is to help enterprises analyze their landscapes, execute transformations, and then continue managing data after the main migration event through validation, decommissioning, archiving, and cloud data integration. 

Transformation is no longer a single event. An SAP customer may start with ECC-to-SAP S/4HANA, then move into non-SAP consolidation, application retirement, M&A separation, or data preparation for AI. If each phase requires a new tooling approach, new data model, or new migration partner, the organization can lose the continuity it was trying to create. 

The SAP S/4HANA Move Should Build Agility 

SAP S/4HANA remains a major modernization milestone, but it should not be treated as the finish line. For many enterprises, it is the first move in a longer program to simplify the business landscape, retire non-SAP systems, improve data quality, and build the agility needed for the next disruption. 

Arbeeny described a call with a large US auto parts manufacturer facing an emergency divestiture. The company had to deliver data to a buyer quickly and had no practical option to delay the work. Events like that expose whether the enterprise can separate data cleanly, understand process dependencies, and move at business speed. 

That is why the work has to start before the trigger event. Clean up unattributed customer records. Reduce duplicated master data. Untangle legal entities. Identify which non-SAP systems carry critical process dependencies. Decommission systems that no longer need to sit in the operational landscape. Arbeeny called these efforts “microtransformations,” and they prepare the organization for larger change before the timeline collapses. 

That is the real Friday-to-Monday test. A successful transformation does not simply prove that a new system works. It proves that the business can keep operating, adapting, and improving when the landscape changes around it. 

What This Means for SAPinsiders 

SAP transformation should be measured by business continuity. SAPinsiders should map the processes that must work on Monday before defining the migration scope. That includes SAP and non-SAP dependencies across finance, manufacturing, maintenance, procurement, compliance, and reporting. 

SAP S/4HANA business cases need to look beyond the initial migration. The move to SAP S/4HANA can create the foundation for non-SAP retirement, application decommissioning, cleaner master data, faster close cycles, and better AI readiness. SAPinsiders should include those second-order outcomes in the business case rather than treating them as later cleanup work. 

Business data agility has to be built before disruption arrives. M&A, divestitures, regulatory shifts, and AI programs expose whether enterprise data is separable, governed, and usable across systems. SAPinsiders should identify the microtransformations that can be done now, including master data cleanup, legal-entity untangling, selective history decisions, and application retirement, so the next forced event does not become a data rescue project.