When the Database Team Doesn't Choose the Cloud: Architecting Resilience for Vendor-Constrained Apps

Most enterprises no longer run on a single cloud. 89% of organizations now operate across more than one cloud provider. That number reflects a quieter operational truth: companies rarely sit down and choose a clean, unified infrastructure. They inherit one. A finance system arrives bundled with one provider, an analytics suite with another, and a customer-facing application brought in from a third-party vendor carries its own hosting requirements that the buyer does not get to negotiate. For the engineers responsible for keeping those systems available, the cloud underneath a mission-critical application is often a decision someone else already made. The reliability problem that follows is different from the one most cloud-native playbooks were written to solve.

Ratna Kumar Bonagiri is a Staff Software Engineer with 18 years of experience across distributed databases, cloud architecture, and enterprise platforms at a leading national retailer, where he leads database design and operational readiness for systems that customers touch directly. Bonagiri has spent much of his career on the part of the stack that does not get to pick its own environment: the databases beneath applications whose hosting was set by a vendor contract or a platform requirement. His work on the company's customer service and contact center systems put that constraint at the center of a hard engineering problem.

The Cloud You Didn't Choose

Customer service has moved into the cloud faster than almost any other enterprise function. The market for cloud-based contact center platforms reached $5.82 billion in 2024 and is on track to hit $17.12 billion by 2030, a 20.3% annual growth rate driven by enterprises retiring on-premise call center hardware for subscription software. The shift solves real problems. It also changes who controls the infrastructure. When a company buys a contact center platform from a specialized vendor, the vendor frequently dictates where the underlying databases live, which cloud they run on, and how they can be configured. The buyer owns the customer outcome but not the platform decisions that determine whether the system stays up.

The contact center platform Bonagiri supported ran on MySQL databases hosted on Microsoft Azure, a placement set by the third-party application's vendor requirements rather than by the retailer's own infrastructure strategy. Customer service teams used the system every day to resolve orders, handle returns, and manage interactions that shape whether a shopper stays loyal after a problem. Bonagiri owned database support, performance, and availability for that system. The complication was structural: the enterprise's standard cloud was Google Cloud, its internal tooling and operational expertise were built around it, yet this revenue-adjacent system sat on a different provider because a software contract said so. Reliability had to be engineered inside a boundary the database team did not draw.

"You can be fully accountable for a system's uptime without owning a single decision about where it runs," Bonagiri says. "The vendor picks the platform, the contract picks the cloud, and you are handed a database you have to keep alive on someone else's terms. The first job is to stop treating that as a limitation and start treating it as the actual design problem."

Designing Failure Into a System You Don't Fully Control

High availability and disaster recovery are easy to document and hard to prove. Fewer than 1 in 3 organizations conduct any failover testing, which means most companies discover whether their recovery design works during an actual outage rather than before one. For a system the engineering team controls end to end, that gap is dangerous. For a vendor-constrained system it is worse, because the team cannot assume the vendor's reference architecture was validated against its own failure conditions, traffic patterns, or recovery targets. Assumptions that hold in a vendor's lab do not always hold in production.

Bonagiri designed and tested the high availability and disaster recovery architecture for the contact center databases rather than accepting the platform's defaults. He defined failover behavior for the MySQL layer, set recovery procedures against measurable objectives, and validated those procedures under production-like conditions instead of leaving them on paper. That work included mapping which failure modes the system could absorb without customer impact and which required intervention, then confirming each recovery path actually behaved as designed. In a system bound by vendor configuration limits, the engineering value sat less in choosing components and more in proving how the assembled system fails and recovers.

"Documented disaster recovery and validated disaster recovery are two completely different things," Bonagiri explains. "A runbook tells you what should happen. A failover test under real load tells you what does. On a system you do not fully control, the test is the only honest answer you have."

Proving the Failover Before You Need It

The distance between a recovery plan that exists and one that works is where most production incidents actually begin. Vendor-supplied systems add a particular kind of risk: the integration points between the third-party application and the database often carry undocumented behavior that only surfaces under stress. A failover that looks clean at the database tier can still strand the application above it if the connection logic, retry timing, or session handling was never tested against a real failure. The lesson tends to arrive through a single small defect that no design review predicted.

Bonagiri's approach treats the integration layer as the real test surface, not the database in isolation. He validates how dependent services behave when a failure is injected, measures how long each one takes to recover, and rewrites the ones that fall outside an acceptable window before a migration or cutover proceeds. He co-authored "The 47-Record Bug Nobody Documented: What Enterprise Integration Actually Teaches You", a technical breakdown of the defects this kind of work surfaces. The piece argues that the failures worth studying are rarely the dramatic ones; they are the quiet, undocumented edge cases that compound when nobody is watching.

"The bug that teaches you the most is almost never the one in the design document," Bonagiri notes. "It is the record that fails to sync, the retry that fires a beat too late, the edge case that only appears when one zone goes dark under load. Find those before the cutover, or they find you during it."

Migrating a Locked-In System to the Standard Cloud

Vendor lock-in is rarely permanent, but it loosens on the vendor's schedule, not the customer's. Many enterprise platforms eventually become cloud-agnostic, able to run on whichever provider the customer prefers, which opens a window to consolidate a stranded system back onto the company's standard infrastructure. That window is also the highest-risk moment in the system's life, because moving a live customer-facing database means changing the foundation while the application keeps serving real interactions. The migration cannot ask customer service to pause.

When the contact center platform became cloud-agnostic, Bonagiri helped plan and execute the migration of its databases from Microsoft Azure to a managed database service on Google Cloud, aligning the system with the enterprise's standard cloud at last. He sequenced the move to preserve data consistency, hold downtime to a minimum, and keep the service available through the cutover, then established monitoring, backup, and recovery procedures in the new environment. He coordinated application, infrastructure, and vendor teams through go-live and supported the databases directly through peak retail periods, including the high-volume stretch around Thanksgiving. Bonagiri is also a judge for the IBM Z x UNSA Hackathon 2026, evaluating technical work built under real engineering constraints.

"Migration without a reason is just risk you volunteered for," Bonagiri observes. "We did not move the system because the cloud was newer. We moved it because consolidating onto our standard platform meant the team operating it finally had the tooling, the visibility, and the recovery options the system always should have had."

Reliability Belongs to the Architect, Not the Vendor

As more of the enterprise stack arrives as purchased platforms rather than systems built in-house, the vendor-constrained reliability problem stops being an exception and becomes a standard condition of the job. The database architect's role shifts accordingly. Less of the work is greenfield design, where every choice is open, and more of it is engineering resilience inside boundaries set by someone else's product decisions. The skill that matters most is making a system you did not fully choose behave the way the business needs it to.

The pattern Bonagiri has worked through, validating recovery on a system before trusting it, treating integration points as the real failure surface, and consolidating stranded systems onto standard infrastructure when the constraint lifts, forms a repeatable method for any team inheriting a vendor-bound database. None of it depends on owning the original platform decision. It depends on refusing to confuse a vendor's defaults with a validated design, and on proving behavior under failure rather than assuming it. For customer-facing systems where a database outage means a customer who cannot get help, that distinction decides whether reliability is real or merely documented.

"The cloud a system runs on is sometimes out of your hands," Bonagiri reflects. "Whether it survives a bad day is not. That responsibility belongs to whoever designs and tests the thing, and it does not transfer to the vendor just because the vendor picked the platform."