SAP’s 2027 cutoff for mainstream support on its legacy ERP has turned that pressure into a migration wave. 59% of companies are now fully or partially live on SAP S/4HANA, up 13 percentage points in a single year.
The platform underneath those deployments is an in-memory database with performance characteristics that older sizing and recovery practices were not designed to handle.
Ratna Kumar Bonagiri is a staff software engineer, author of Powering E-Commerce Systems and a senior member of the IEEE with 18 years of experience across enterprise platforms, distributed databases and SAP infrastructure at a large U.S. retail enterprise.
Deploying a platform before the playbook exists
Early versions of SAP S/4HANA shipped while production practices were still forming, leaving sizing assumptions, high availability patterns and recovery procedures for the in-memory layer largely undefined for specific workloads.
Vendor guides describe how software is designed to behave. They do not always answer how a specific enterprise’s data, traffic and operational demands will stress the system.
Bonagiri joined the SAP Basis team for one of the enterprise’s first SAP Fashion Management deployments, built on S/4HANA Simple Finance and a broader SAP HANA landscape.
He worked on system architecture, platform readiness and operational setup across the components while operating as an early adopter in direct contact with SAP’s product and engineering teams.
“Being an early adopter sounds like an advantage until you are the one who has to keep the system running,” Bonagiri said. “You get the new platform, but you do not get the years of field experience that tell you how it fails. That part you build yourself, in production, with the business depending on it.”
Sizing a system with no precedent
The risk in a large ERP program often concentrates at go-live. On an in-memory platform, that risk can be more complex because memory-resident workloads behave differently under load than the disk-based systems many capacity models were built around.
Sizing a HANA environment by analogy to an older database can either waste expensive memory or leave the system underprepared at peak. With no settled reference, the sizing decision becomes an engineering judgment rather than a simple lookup.
Bonagiri performed system sizing, environment setup and infrastructure planning for HANA workloads directly, deriving capacity needs from actual system characteristics instead of a generic template.
He mapped how SAP components would consume memory and compute under enterprise conditions, then provisioned against that profile and adjusted as testing exposed real demand.
“Sizing is where early adoption gets expensive if you get it wrong,” Bonagiri said. “There was no chart that told me what this landscape would need at peak. I had to size it from the workload itself, prove the numbers under test, and leave headroom for the parts I could not yet predict.”
Engineering recovery for an in-memory platform
Data that must survive a failure has to be persisted and replicated in ways that account for the volatility of RAM. Recovery time depends on how quickly a large in-memory store can be reloaded and made consistent.
When SAP HANA was new, the patterns for doing this well were still maturing. A team could not assume that a recovery design proven on a disk-based system would translate cleanly to an in-memory platform.
Bonagiri designed and implemented the high availability and disaster recovery architecture for the SAP HANA systems rather than relying only on platform defaults.
He set failover behavior and recovery procedures against measurable objectives, then tested them under conditions close to live operation so the design was proven before the system carried real workloads.
Bonagiri is also a judge for the Beta AI Super Hackathon, evaluating technical projects built under real engineering constraints.
“A recovery plan on paper and a recovery you have actually tested are not the same thing,” Bonagiri said. “On a platform this new, the test is the only proof you have. I would rather find the gap during a controlled failover than during a real one with customers waiting.”
Readiness as the deliverable
Many SAP customers remain on the legacy ERP generation, which means a large number of high-stakes deployments are still ahead. Programs compressed into the final years before support changes may face the same unsettled questions early adopters did, but with less time to answer them.
Bonagiri treated validation and readiness as the deliverable, not as a step added after the build.
He supported platform validation, testing readiness and operational planning for the production rollout. He also helped establish the monitoring and stability practices the landscape would run on after deployment.
“Installing the software is the part everyone can see,” Bonagiri said. “The real work is proving the system holds under your own conditions and handing the operations team something they can run with confidence. Skip that, and you have not finished. You have moved the risk to go-live.”
Readiness belongs to the platform team
More teams will be asked to stand up platforms before the field has fully agreed on how to operate them. That puts more responsibility on internal engineering teams to size systems against real workloads, test recovery procedures and establish readiness standards where vendor guidance is incomplete.
The method Bonagiri worked through on an early SAP HANA program offers a template for deployments now arriving under deadline: size from real workloads, design and test recovery for the in-memory platform, and work with product engineering through stabilization and cutover.
For systems that carry core enterprise operations, that approach can turn an unproven platform into a dependable one. The advantage of going early is not simply the technology. It is learning how to make the system production-ready before the rest of the market has to.
“A vendor ships you a platform. It does not ship you a system that is ready for your business,” Bonagiri said. “That distance is the job. Whoever sizes it, tests it, and stands behind it on go-live day decides whether the early move was worth making.”
©2026 Cox Media Group
