When Oracle released a critical security patch last week, our team patched over 70 PeopleSoft environments in a single day with just three people. That’s not a typo. And while the circumstances were urgent, the outcome wasn’t luck—it was the result of architectural decisions made months and years earlier.
John Marcus, our Principal System Engineer, recently walked through the methodology behind results like this in a PeopleSoft webinar on maintenance strategy. The session covered everything from foundational architecture to automation tooling, and the throughline was clear: how you build and structure your environment matters more than almost anything else when it comes to maintenance.
Define What Maintenance Means for Your Environment
Before you can build a maintenance plan, you need to understand where your environment sits in its lifecycle. A fresh deployment with no customizations has very different needs than a mature environment with active modifications across HCM, Financials, and Campus Solutions.
John breaks environments into a few categories: fresh deployments that want bleeding-edge everything, retired environments that exist solely for regulatory retention and need only security patches, near-end-of-life systems that need regulatory and security updates but no new features, and mature environments that require the full maintenance stack—tools, PUMs, security, and regulatory patches.
The definition you choose determines your approach. And it’s not static. Every time your environment enters a new stage of its lifecycle, you need to reevaluate what maintenance means and what architectural changes might be required to achieve it.
Architecture Is the Foundation
The most important slide in John’s presentation was also the most direct: “The architectural foundation of your system matters more than nearly anything else.”
A poorly architected environment is miserable to maintain. And humans are naturally disincentivized to do miserable things. If your architecture makes maintenance painful, it won’t get done as well or as often as it should.
Three modern patterns make the biggest difference:
Decoupled homes. John still occasionally encounters PeopleSoft systems with coupled homes, which require touching the entire deployment to change a few files. For regulatory or security updates, that’s a recipe for problems. Decoupled homes isolate changes and reduce risk.
Disposable environments. If the thought of killing and rebuilding an environment scares you, that’s a sign your architecture isn’t optimized for maintenance—or disaster recovery. Properly architected environments should be treated like cattle, not pets. If one is misbehaving, you should be able to tear it down and rebuild it without drama.
Standardized deployments. Production should be a clone of test, which should be a clone of dev. Every environment should have identical software and configuration—other than environment-specific settings. This means code behaves the same everywhere, problems that appear in production should have appeared in dev, and you can test fixes reliably.
If you’re inheriting a legacy environment, these changes won’t happen overnight. But every maintenance window is an opportunity to nudge the architecture closer to modern standards. Over time, these incremental improvements compound into dramatically easier operations.
Security Patches Are Not Optional
In today’s threat landscape, deferring security patches isn’t a choice you get to make. The recent CVE that drove our 70-environment patch day made that abundantly clear. Any unsecured system is a potential pathway into your PeopleSoft environment.
The same applies to regulatory patches—tax updates, compliance changes, and similar requirements carry legal and operational risk if delayed.
This is why GT Keep Current exists as a service. Organizations that don’t have the internal bandwidth to maintain a consistent patching cadence need a partner who can keep them current without creating additional burden on already-stretched teams.
Create a Sustainable Maintenance Tempo
One of the most common failure patterns John sees is what he calls maintenance fatigue. A new environment gets stood up, everyone is enthusiastic, and the team jumps in with an aggressive schedule—PUMs, CPUs, security patches, regulatory patches, the works.
Within about two cycles, fatigue sets in. Within 18 months, many organizations have stopped doing updates altogether because the business is tired of testing.
The solution is to create a maintenance plan that works for you, your business, and your end users—and then stick to it. That last part is the hard part.
For a typical four-pillar environment (HCM, Financials, Campus Solutions, and Interaction Hub), John recommends rotating which pillar gets the full tools and PUM treatment each quarter, while the others receive regulatory and security patches. By the end of the year, every pillar has been fully updated, and no single quarter overwhelms the testing team.
The key insight: if you defer a PUM or tools upgrade, you’re adding testing debt to the next cycle. Two or three quarters of deferral can create a backlog so large that catching up becomes a multi-month project. Some organizations have taken so long to test and approve a tools update that by the time they finish, they’re already out of date again.
Automation and Containerization Are Force Multipliers
The 70-environment patch day wouldn’t have been possible without automation. John’s team uses Ansible (specifically Oracle Linux Automation Manager) combined with Kubernetes to execute maintenance tasks across dozens of instances simultaneously.
Automation doesn’t require perfect architecture—you can automate against any environment. Start with low-hanging fruit: domain restarts, minor config changes, database administration. John has automations that let other teams at GT restart their own domains and manage database users without any intervention from the infrastructure team.
Containerization requires more commitment. It came from the developer world, and you have to think a bit like a developer to get comfortable with it. But the payoff is substantial: automated tools upgrades that complete in 30 minutes instead of hours, OS patches that happen automatically as part of image rebuilds, and significantly reduced attack surface.
A word of caution: automation and containerization are magnifying glasses, not silver bullets. They will absolutely magnify any inefficiencies or architectural problems you already have. You have to be good at doing things manually before you automate them, and your architecture has to be solid before you containerize. As John put it, giving someone poor automation skills is like giving a 16-year-old a Corvette for barely graduating driving school.
Plan for When Things Go Wrong
Something will eventually break during maintenance. That’s not pessimism—it’s just the nature of touching complex systems. The question is whether you’ve prepared for it.
John uses the PACE framework: Primary plan (what you’d like to see happen), Alternate plan (how you handle predictable problems), Contingent plan (what you do if both primary and alternate fail), and Emergency plan (how you respond to severe failures like database corruption).
The point is to make decisions before you’re in the middle of a crisis. Every maintenance window should have a clear rollback mechanism. Even if the maintenance itself fails, a good rollback plan means the system comes out intact on the other side.
Disaster recovery and maintenance are intertwined. You can’t have good maintenance planning without also having a DR plan—and you need to exercise that DR plan occasionally. One of our customers actually moves their entire system to a different cloud region for two weeks every year just to verify their DR plan works. That takes organizational courage, but it also means they know their plan works when it matters.
Watch the Blind Spots
A few gotchas that trip up even experienced teams:
Oracle sometimes releases a PUM revision without clear announcement, so an older ISO you built might stop working. Release notes are essential reading.
Certification lists matter. John has seen customers inadvertently wander off the certification list and end up in a precarious position—things still work, but Oracle support will point to the certification issue first if something breaks.
Post-maintenance validation rarely gets enough attention. After every maintenance window, verify that what you did had the effect you intended. Check that features work, that DMS scripts completed, that the business can actually use what you deployed. This keeps you from handing an environment back in a bad state.
If you’re looking at your current maintenance situation and feeling behind, you’re not alone. Most organizations didn’t inherit perfectly architected environments, and most teams don’t have unlimited bandwidth for patching.
Where to Start
The path forward is incremental: identify the highest-impact architectural improvements, start automating repetitive tasks, and establish a maintenance tempo that’s sustainable for your team and your business.
For organizations that need help—whether that’s full managed services, mentoring on containerization, or a one-time assessment of your maintenance readiness—our consulting team has been doing this for over 25 years. We’re happy to share what we’ve learned.
This post is based on John Marcus’s session “How to Apply PeopleSoft PUM Images and CPUs with Minimal Downtime” from our monthly Lunch and Learn series. View upcoming sessions and past recordings on our webinars page.
