PetMeds’ Architecture Shift: Why CTO Umesh Sripad Chose a Fragmented Best-of-Breed Core

For 20 years, PetMeds sat atop a legacy platform that did its job but demanded a heavy tax on innovation. As a mid-market leader generating around $300 million in annual revenue, the company found itself at a familiar crossroads. It needed to scale, but the legacy technology stack had become an anchor. When Umesh Sripad arrived as CTO of PetMeds, he and his team chose to deploy a fragmented, best-of-breed architecture where every piece—from Salesforce for commerce to SAP S/4HANA Public Cloud for finance—does exactly what it was built to do, without being twisted into something it isn’t.

SAPinsider sat down with Sripad just six weeks before his team’s major Go-Live. In a candid conversation, he opened up about the nightmare of customization, the three frameworks he uses to filter scope creep, and why he believes leadership involvement is the only thing standing between a Clean Core and a technical debt disaster.

SAPinsider: Many CTOs seek a single silver-bullet platform. You took a deliberate, fragmented approach to your architecture. Why?

Umesh Sripad: We had to step back and look at the backend core of any e-commerce business. Generally, an e-commerce business has five critical components: a commerce engine, an Order Management System (OMS), inventory planning, a Warehouse Management System (WMS), and financial systems. SAP supports all of them.

We took a fragmented solution approach because we needed to be faster. Therefore, for our commerce engine and OMS, we went with Salesforce because it was the right fit for those specific needs at that time—commerce and OMS work very well together there. However, once we proved that the technology launch was successful, we still had to integrate the inventory and financial systems.

That’s where the choice became clear. We needed an ERP that could tackle those two specific use cases—finance and inventory—without us having to reinvent the wheel. Since we had already decoupled the other parts of the stack, choosing SAP Public Cloud was much easier. It wasn’t about bringing in SAP for the sake of it, but about solving the remaining business problems with the tool best suited for them.

SAPinsider: Moving to a fit-to-standard model is difficult because it forces humans to change how they work. How did you convince your stakeholders to adapt their processes to the software?

Sripad: It starts with education before you even pick the tool. I’ve been in this industry for 20-plus years; I’ve had conversations with peers who shared their horror stories. I know that the more you customize a core system, the heavier the maintenance becomes. We simply cannot continue to invest in technology maintenance when we need to move the business forward.

We sat down with merchandising, warehouse, finance, and accounting, and set a clear guardrail: we will not alter the core. We framed it as a necessity for reducing technical debt. When you explain that custom solutions mean hiring more people just to maintain the status quo, the mindset shifts. We told them: “We are building side-by-side functionality if absolutely needed, but we aren’t touching the engine.”

SAPinsider: Scope creep is the silent killer of projects like this. Did you have a specific framework to handle requests when a stakeholder said, “But we need it to work this way”?

Sripad: Yes, we established a three-framework discipline to filter every request. When a requirement comes in, we ask:

1. Is this standard? Can we do it with an out-of-the-box functionality?
2. Is there a partner app? If it’s not standard, do we have partners that exist as apps within the SAP ecosystem?
3. Build on SAP BTP. Only if the first two are no do we look at building something new through the SAP Business Technology Platform (BTP).

This architectural discipline helped us. In the early stages, particularly in finance, there were requests to replicate the process used in the older system. They wanted to adopt the old method because it was familiar. But because we had that framework, we could have the discussion and say: “Let’s not adopt an old process that requires manual work. Let’s learn the new way.”

SAPinsider: You’re operating two distinct brands, PetMeds and PetCareRx. How did that complexity factor into your architecture?

Sripad: That was a critical part of the puzzle. We are two brands working as a direct-to-consumer business, but we needed financial stability and an ERP as a universal solution. We had to break both businesses down and look at the different touchpoints and integrations required for each.

The discovery session was vital here. It helped us articulate an architecture in which SAP serves as the unifying layer for both. It’s not just about one business; it’s about ensuring the ecosystem supports the unique needs of both brands without creating two separate, divergent technical stacks.

SAPinsider: Now that the foundation is set, what can PetMeds do today that was technically impossible 12 months ago?

Sripad: If I look back 24 months, we might have done three or four releases in a quarter—maybe once a month. Today, we can deploy changes every single day. We have become nimble, faster, and agile.

But beyond speed, it’s about scale and data readiness. We work with hundreds of thousands of partners on the merchandising side. With this integration layer, managing those partnerships becomes much cleaner and faster. We’ve built a data framework that leapfrogs us into the digital era, ready to leverage automation and AI. We aren’t just patching a legacy system anymore; we have an infrastructure that can absorb new technology.

SAPinsider: For peer CTOs reading this who are terrified of being promised the world and being delivered a customization nightmare, what is the one question they should ask their implementation partner?

Sripad: Before you even talk to a partner, look at your internal readiness. You should know your own ecosystem and build it out so that SAP fits in like a puzzle piece, rather than being a roadblock.

However, when you do sit down with a partner, don’t ask if they can do something. The question you should ask is: “Does this partner understand my entire ecosystem?” Once they understand the business, they can help you articulate what should be built on SAP BTP versus what should be left out of scope. If the partner doesn’t understand the nuance of your specific business context, they can’t help you hold the line on scope discipline.

SAPinsider: Any final thoughts on leading a transformation of this magnitude?

Sripad: SAP—or any public or private cloud project—only works if leaders are willing to lead. Standardization is not a feature request; it’s a discipline.

If I hadn’t been deeply involved in the process and scope, the results might have been different. When leaders have the influence internally to say no to customization and yes to standardization, the positive results compound. It keeps the tech debt low and the architecture stable. That’s the legacy we want to build.