Lift. Shine. Modernize.
Modernization doesn't always start with transformation. A pharmacy chain's entire operation ran on legacy Oracle, held together by one overworked DBA. Here's how a phased "Lift and Shine" approach - stabilize first, transform next moved them to the cloud without breaking what already worked, and gave their team room to plan what's next.
- Enterprises running critical workloads on 10–20 year old systems face a real dilemma: stay on-prem and keep maintaining, or move to the cloud and start modernizing.
- Case in point: a large pharmacy chain ran its entire pharmaceutical management system, including inventory, supply chain, and store transactions, on legacy Oracle, held together by a single DBA.
- Lift-and-shift alone just relocates the operational burden. Full re-architecture is high-risk, slow, and disruptive. Neither fit.
- Tessell's answer: Lift and Shine, which migrates to the cloud with zero application refactoring, while layering in a modern, automated database operating model (provisioning, patching, backups, HA) at a lower TCO.
- The immediate win wasn't transformation, it was stabilization. Routine operational overhead dropped to near zero.
- That freed the DBA from constant firefighting, creating "breathing room": space to actually think about the future instead of just keeping the present running.
- With that space, the real modernization questions surfaced naturally: open-source database options, independently modernizing services, long-term architecture.
- Core takeaway: modernization is a journey, not a single leap. Continuity first, then clarity, then change.
Modernization doesn’t always start with transformation
Over the past year, I’ve had several conversations with enterprises that are running critical workloads on systems built over 10–20 years. Systems that are deeply embedded into the business. Systems that still work - but are increasingly difficult to sustain.
One recent example stood out.
A large pharmacy chain was running its entire Pharmaceutical management information system (PMIS) on legacy Oracle databases. This wasn’t just another application - it was the backbone of their operations. Inventory, supply chain, store-level transactions - everything depended on it.
Like many organizations in a similar position, they were at a crossroads.
Their private cloud infrastructure was aging, support timelines were becoming a concern, and the internal expertise to manage and maintain the system was limited - in this case, a single DBA who had been holding things together for years.
They had two broad options:
Stay on-prem and continue investing in maintaining the status quo
Or move to the cloud and begin the journey toward modernization
On paper, the second option sounds obvious. In reality, it’s rarely that simple.
Because the real challenge isn’t whether to modernize.
It’s how to do it without breaking what already works.
When “Lift and Shift” isn’t enough - and full “transform” carries too much risk.
In many such cases, we see two extremes.
On one end, a basic lift-and-shift - moving the database to cloud infrastructure, but carrying forward the same operational burden with little meaningful improvement. Customers are looking for more than this
On the other, a full transformation - re-platforming or re-architecting the database stack, which often comes with high risk, long timelines, and significant internal disruption.
Neither felt right for this customer. What they needed was a middle path.
A more practical starting point: stabilize, simplify, then evolve → LIFT & SHINE
We worked with the customer on a phased approach.
The first step was not transformation - it was stabilization .
We migrated their database workloads into their cloud environment using the Tessell platform)
Upgraded it to a fully supported Oracle version, eliminating the risk of running on unsupported version
Automated provisioning, patching, backups, and high availability ( 1-click), reducing the operation overheads to near zero of routine tasks.
This may sound operational. But for the customer, it changed a lot. Their DBA no longer had to spend disproportionate time on maintenance and firefighting tasks
Most importantly, it created breathing room..
Room to think. Room to plan. Room to innovate.
Modernization becomes possible only when teams are freed up
One of the most overlooked aspects of modernization is this:
“You cannot expect teams to redesign the future while they are fully occupied keeping the past running”
Replatforming a database is not just a technology decision - it’s a time and focus problem. When critical business logic lives inside the database, the DBA who can enable that transition is often the same person buried in patching, backups, and daily firefighting
By removing the undifferentiated heavy lifting - the team could start thinking about what comes next.
Not in a rushed, forced way.
But in a structured, deliberate manner.
Should parts of the system move to open-source databases?
Are there services that can be broken out and modernized independently?
What does long-term architecture look like?
These are the right questions - but they only come into focus once stability is in place.
Transformation is a journey, not a starting point
In conversations around cloud and data, we often jump too quickly to the end state.
But in reality, most enterprises don’t need disruption on Day 1.
They need continuity first, then clarity, and finally change.
This is where we’ve seen the most success - helping customers take that first step:
Modernize how their databases are run
Without forcing them to immediately modernize what is built on top
Tessell’s mantra is LIFT - SHINE - MODERNIZE
