☕ This Week’s Focus

Edition 29 highlights a growing tension in the ERP and cloud space: acceleration versus alignment.

Oracle is pushing aggressively into AI, with infrastructure investments, partnerships, and now large-scale agent-based automation. At the same time, workforce changes and market reactions remind us that transformation always comes with trade-offs.

Subscribe now

Across the ERP landscape, the conversation is shifting toward ecosystems and composability. Organizations are no longer asking “Which ERP should we choose?” but rather “How should our ERP fit into a broader architecture?”

Meanwhile, the PeopleSoft community continues to move forward with clarity by leveraging OCI, expanding Cloud Manager capabilities, and aligning with the 2026 roadmap.

⚙️ Oracle, AI & Market Signals

🔗 Oracle Layoff Plan Raises Questions (Yahoo Finance)
https://finance.yahoo.com/news/oracle-layoff-plan-raises-questions-011119909.html
Reports of layoffs are raising questions about how Oracle is balancing cost management with its aggressive investments in AI and the cloud. It’s a reminder that large-scale transformation often includes difficult operational decisions.

🔗 Oracle + NVIDIA at GTC 2026: Key Announcements (OCI Blog)
https://blogs.oracle.com/cloud-infrastructure/oracle-nvidia-gtc-2026-key-announcements
Oracle and NVIDIA announced deeper collaboration around AI infrastructure, including expanded GPU capabilities and performance optimizations. The focus remains clear: enable enterprise-scale AI workloads with high-performance compute.

🔗 Oracle Unleashes 1,000 AI Agents (CloudWars)
https://cloudwars.com/ai/oracle-unleashes-1000-ai-agents-to-automate-entire-industries/
Oracle is introducing a large portfolio of AI agents designed to automate complex business processes across industries. This marks a significant step toward agentic ERP, where systems don’t just process data; they act on it.

📊 ERP Strategy & Architecture

🔗 Why ERP Ecosystems Are a Strategic Architecture Decision (Forbes)
https://www.forbes.com/councils/forbestechcouncil/2026/03/20/why-erp-ecosystems-are-a-strategic-architecture-decision/
This piece makes a strong case that ERP is no longer a standalone system, it’s part of a broader ecosystem. Integration strategy, data flow, and platform alignment now matter as much as core functionality.

🔗 Composable ERP: Architectural Reality or Executive Imperative? (ERP Today)
https://erp.today/composable-erp-architectural-reality-or-executive-imperative/
Composable ERP continues gaining attention as organizations look to assemble capabilities rather than replace entire systems. The challenge is balancing flexibility with governance and long-term maintainability.

👩‍💻 PeopleSoft Community & Practice

🔗 Enabling AI for PeopleSoft with OCI (PeopleSoftCareer)
https://blog.peoplesoftcareer.com/enabling-ai-for-peoplesoft-with-oci/
A practical guide to integrating AI capabilities into PeopleSoft using Oracle Cloud Infrastructure. It outlines how AI services can enhance existing workflows without disrupting the core system.

🔗 Cloud Manager Image 21 (Oracle PeopleSoft Blog)
https://blogs.oracle.com/peoplesoft/cloud-manager-image-21
Oracle highlights updates to Cloud Manager Image 21, including improvements to provisioning, lifecycle management, and automation. Cloud Manager continues evolving into a key platform tool for PeopleSoft operations.

🔗 PeopleSoft 2026 Product Roadmap (PeopleSoftCareer)
https://blog.peoplesoftcareer.com/peoplesoft-2026-product-roadmap/
An overview of the 2026 roadmap, including continued investment in UX, AI capabilities, and platform enhancements. The roadmap reinforces Oracle’s long-term commitment to PeopleSoft.

💬 Aaron’s Take

Edition 29 reinforces a shift that’s been building for a while: ERP is no longer a destination; it’s a component of a larger system.

Oracle’s AI push, NVIDIA partnerships, and agent-based automation are all part of a broader strategy to move beyond traditional ERP boundaries. But those moves come with real operational considerations, including cost, workforce alignment, and execution risk.

At the same time, the ERP conversation itself is evolving. Ecosystems and composability are replacing monolithic thinking. The question isn’t whether ERP changes, it’s how well it integrates with everything around it.

PeopleSoft continues to fit into this new model in a very practical way. Instead of being replaced, it’s being extended and connected to AI services, managed through Cloud Manager, and aligned with a clear roadmap.

The organizations that succeed won’t be the ones chasing the biggest changes. They’ll be the ones who thoughtfully architect, deliberately integrate, and consistently evolve.

🌐 Join the Community

If you want to stay current on ERP strategy, PeopleSoft innovation, and cloud platform trends, subscribe at PeopleSoftCloud.com.

Each week you’ll receive:

✅ Curated ERP and PeopleSoft insights
✅ Context around AI and cloud developments
✅ Practical guidance for enterprise technology teams

See you next week for Edition 30.

☕ This Week’s Focus

Edition 28 highlights a theme that continues to define ERP strategy in 2026: evolution over disruption.

Subscribe now

Across the industry, the most successful organizations aren’t abandoning their ERP foundations. Instead, they’re layering AI, automation, and modern architecture patterns on top of stable platforms. Oracle’s financial performance and market momentum reinforce the scale of its cloud ambitions, while analysts and practitioners alike encourage enterprises to modernize intelligently rather than rush into costly replacements.

Meanwhile, the PeopleSoft ecosystem continues to deliver practical updates, from tax reporting changes to developer automation techniques, demonstrating that modernization often happens through incremental capabilities rather than sweeping change.

Let’s look at the signals shaping the landscape this week.

⚙️ Oracle, Cloud & Market Signals

🔗 Well-Architected Design for Resiliency with Oracle Database@AWS
https://aws.amazon.com/blogs/database/well-architected-design-for-resiliency-with-oracle-databaseaws/
AWS outlines architecture guidance for running Oracle Database workloads with resiliency and high availability. The takeaway is clear: hybrid and multicloud patterns are becoming normal for enterprise workloads, especially when reliability and geographic redundancy are priorities.

🔗 Oracle Stock Surges on AI and Cloud Momentum (Axios)
https://www.axios.com/2026/03/10/oracle-stock-ai-cloud-computing
Axios reports renewed investor confidence in Oracle as AI and cloud demand continue driving revenue expectations. Markets are increasingly viewing Oracle not just as a database company, but as a major infrastructure provider for enterprise AI workloads.

🔗 Oracle Announces Fiscal Year 2026 Third Quarter Financial Results
https://investor.oracle.com/investor-news/news-details/2026/Oracle-Announces-Fiscal-Year-2026-Third-Quarter-Financial-Results/default.aspx
Oracle’s quarterly results reinforce the same trend: cloud infrastructure and AI-related demand remain key growth drivers. The company continues investing heavily in capacity and infrastructure as enterprise workloads scale.

📊 ERP Strategy & Industry Direction

🔗 Don’t Rip and Replace PeopleSoft—Pair It with Emerging Tech Instead (CIO.com)
https://www.cio.com/article/4132315/dont-rip-and-replace-peoplesoft-pair-it-with-emerging-tech-instead.html
CIO.com reinforces a strategy many experienced ERP leaders already follow: extend PeopleSoft with modern tools rather than replacing it prematurely. Integrations, automation layers, and AI services allow organizations to modernize while protecting the stability of their core systems.

🔗 AI in ERP: How Intelligence Is Reshaping Enterprise Platforms (NetSuite)
https://www.netsuite.com/portal/resource/articles/erp/ai-erp.shtml
This overview highlights how AI is becoming embedded across ERP workflows—forecasting, automation, anomaly detection, and decision support. The shift isn’t toward replacing ERP systems, but toward making them more intelligent.

🔗 Gartner: Embedded AI in Cloud ERP Will Accelerate Financial Close by 30%
https://www.gartner.com/en/newsroom/press-releases/2026-02-24-gartner-predicts-embedded-ai-in-cloud-erp-applications-will-drive-a-30-percent-faster-financial-close-by-2028
Gartner predicts that embedded AI capabilities will significantly accelerate financial close processes by 2028. Automation of reconciliations, anomaly detection, and workflow orchestration is expected to reshape finance operations.

👩‍💻 PeopleSoft Community & Practice

🔗 IRS FIRE to IRIS: What PeopleSoft Customers Need to Know for 2026 Filings
https://blogs.oracle.com/peoplesoft/irs-fire-to-iris-what-peoplesoft-customers-need-to-know-for-2026-filings
Oracle outlines the transition from the IRS FIRE system to IRIS for tax reporting. Organizations using PeopleSoft must understand the changes and prepare their reporting processes accordingly to ensure compliance.

🔗 PeopleTools Sessions of Interest at Blueprint 4D 2026
https://blogs.oracle.com/peoplesoft/peopletools-sessions-of-interest-at-blueprint-4d-2026-2
Oracle highlights key PeopleTools sessions at Blueprint 4D, including topics on platform capabilities, automation, and modernization strategies. These sessions provide a good roadmap for teams planning upgrades or exploring new features.

🔗 PeopleSoft 2026 Product Roadmap Overview
https://blog.peoplesoftcareer.com/peoplesoft-2026-product-roadmap/
This overview summarizes major roadmap directions for PeopleSoft in 2026, including continued UX improvements, AI integrations, and platform modernization initiatives.

🔗 Automating Document Merges in PeopleSoft with Java and PeopleCode
https://newpeoplesoft.wordpress.com/2026/03/11/automating-document-merges-in-peoplesoft-pdf-jpg-and-png-consolidation-with-java-and-peoplecode/
A practical technical guide showing how to automate document merging processes inside PeopleSoft. It’s a great example of how PeopleCode and Java integration can streamline operational workflows.

💬 Aaron’s Take

Edition 28 reinforces something that’s becoming increasingly obvious across the ERP landscape: the future of ERP isn’t replacement—it’s augmentation.

Organizations that rush into rip-and-replace transformations often underestimate the complexity and cost involved. Meanwhile, teams that thoughtfully integrate modern technologies, including AI services, automation layers, and observability tools, can dramatically improve their ERP environments without destabilizing them.

Oracle’s market momentum reflects the infrastructure side of this story. Demand for cloud capacity and AI platforms is growing rapidly, and Oracle is positioning itself as a key provider of that infrastructure.

But the more interesting story may be happening inside existing ERP platforms like PeopleSoft. Incremental improvements, better integrations, and smarter automation are quietly transforming how these systems deliver value.

In other words, modernization doesn’t always look dramatic. Sometimes it looks like disciplined progress.

🌐 Join the Community

If you want to stay current on ERP strategy, PeopleSoft innovation, and cloud platform trends, subscribe at PeopleSoftCloud.com.

Each week you’ll receive:

✅ Curated ERP and PeopleSoft insights
✅ Context around cloud and AI trends
✅ Practical guidance for enterprise technology teams

See you next week for Edition 29.

Subscribe now

PeopleSoft remains one of the most deeply embedded enterprise platforms in higher education, the public sector, and complex commercial environments. The investment is not limited to licensing or infrastructure. It includes decades of configuration, alignment of business logic, reporting maturity, and institutional knowledge. Replacing that foundation means replicating it elsewhere, often at a higher cost and with greater risk. The executive question should not be whether the platform is new, but whether it continues to deliver measurable value.

Total Cost of Ownership Versus Total Cost of Change

Most ERP replacement conversations focus on subscription pricing comparisons. Vendors highlight lower licensing costs or bundled features to create the impression of savings. However, the total cost of ownership rarely tells the full story without considering the total cost of change. Implementation, retraining, integration rebuilds, and stabilization periods often dwarf projected licensing differences.

The total cost of change includes both visible and hidden components. These typically include:

• Multi-year implementation services and integration rebuilds

• Productivity loss during transition and retraining cycles

• Temporary parallel system costs and stabilization overhead

Organizations frequently underestimate the duration of these transition costs. Even successful implementations can take years for operational efficiency to match the pre-migration baseline. From an executive standpoint, staying on PeopleSoft may represent the lower-risk, higher-return decision when these full lifecycle costs are modeled honestly.

The ROI of Existing Customization and Process Alignment

PeopleSoft environments often reflect years of business process refinement. Customizations, bolt-ons, and integrations are rarely random. They represent accumulated decisions that align technology with organizational reality. Replacing the platform means re-evaluating or recreating that alignment from scratch.

While customization is sometimes portrayed as technical debt, it is often institutional intelligence encoded in software. That intelligence carries real value. Eliminating it without a compelling return introduces operational friction and compliance risk. The ROI of staying on PeopleSoft includes preserving the alignment that has been built up.

When CIOs quantify the cost of rebuilding custom integrations and reporting structures in a new system, the financial case becomes clearer. Even modest environments can represent thousands of hours of development and configuration work. Preserving that investment is not conservatism. It is disciplined capital management.

Stability as a Financial Asset

Stability is frequently undervalued because it lacks a marketing narrative. When a system runs consistently, it does not generate headlines. However, stability has measurable economic value. Predictable operations reduce incident costs, improve audit performance, and protect institutional reputation.

Financial leaders understand the value of reduced volatility. A stable ERP reduces the likelihood of large, unplanned expenditures tied to system failures or rushed remediation. It also reduces executive distraction during periods of organizational change. These benefits compound quietly over time.

Staying on PeopleSoft allows organizations to redirect capital from reactive system replacement toward proactive modernization. Cloud migration, automation, and analytics enhancements often produce higher marginal returns than wholesale reimplementation. Stability, when leveraged intentionally, becomes a funding source for innovation rather than an obstacle.

Leveraging Modernization Without Replacement

Remaining on PeopleSoft does not imply stagnation. Modernization can occur at the infrastructure, integration, and operational layers without replacing the core system. Cloud deployment, observability tooling, and automation pipelines can materially improve cost efficiency and delivery speed. These improvements generate measurable operational gains without destabilizing business processes.

CIOs can often capture modernization value through targeted initiatives such as:

• Infrastructure optimization in public cloud environments

• Standardized deployment pipelines and automation frameworks

• Data integration enhancements that improve reporting velocity

Each of these investments strengthens the platform while preserving institutional alignment. This approach maximizes return on existing investment instead of resetting the balance sheet. It also reduces the execution risk associated with large-scale transformation programs.

The Strategic Advantage of Optionality

Perhaps the most underappreciated benefit of staying on PeopleSoft is the optionality it offers. By avoiding a forced replacement, CIOs preserve strategic flexibility. They retain the ability to modernize incrementally, test new platforms selectively, and respond to regulatory or market shifts without being locked into a single trajectory.

Optionality has financial value because it reduces irreversible commitments. Large ERP replacements often represent multi-year bets with limited exit paths. Staying on PeopleSoft allows organizations to evaluate alternatives from a position of strength rather than from a position of urgency. That leverage improves negotiation power and long-term resilience.

From an executive standpoint, the decision to remain on PeopleSoft should not be framed as defensive. It can be a proactive capital-allocation decision grounded in returns, risk mitigation, and strategic flexibility.

A Disciplined Approach to ERP Leadership

The executive case for staying on PeopleSoft rests on disciplined analysis rather than nostalgia. It requires modeling full lifecycle costs, valuing institutional alignment, and recognizing stability as an asset. When these factors are considered honestly, the narrative shifts. Staying on PeopleSoft often emerges as a rational and financially responsible strategy.

This does not mean that replacement is never appropriate. It means that replacement should be justified by a clear, measurable advantage rather than external pressure or perception. CIOs who make this distinction lead with clarity and credibility. In the next article, we will explore how to communicate this case effectively to boards and executive peers.

The Hidden Costs of ERP Migration

The Costs That Rarely Make the Slide Deck

ERP migration proposals often present a clean financial narrative. Licensing projections, implementation timelines, and high-level efficiency gains dominate the executive summary. What receives far less attention are the secondary and tertiary costs that surface only after contracts are signed. These costs are not theoretical. They are structural consequences of large-scale system replacement.

Hidden migration costs rarely appear as line items labeled “risk” or “disruption.” Instead, they emerge through extended stabilization periods, increased reliance on consulting, and declining internal confidence. By the time these effects are visible, reversing course is no longer practical. For CIOs, understanding these hidden dimensions is critical before committing to replacement.

Productivity and Institutional Knowledge Loss

One of the most underestimated costs of ERP migration is the decline in productivity. During transition periods, teams operate in parallel modes of learning and delivery. Business users must adapt to new workflows, new interfaces, and new reporting structures. Even when training is thorough, confidence drops before it rises.

Institutional knowledge is another invisible asset that erodes during migration. Long-tenured administrators and analysts often carry contextual understanding that cannot be easily documented. When those individuals disengage or exit during transformation cycles, organizations lose operational memory. That loss translates into slower troubleshooting, longer cycle times, and increased dependency on external advisors.

The financial impact of knowledge erosion is rarely modeled. Yet it directly affects delivery speed and decision quality. Over time, this erosion compounds into measurable performance drag.

Integration Rebuild and Data Realignment

ERP systems rarely operate in isolation. They anchor dozens or even hundreds of integrations across finance, HR, analytics, and operational systems. Migration requires either rebuilding or rearchitecting these connections. Each rebuild introduces new testing cycles, new failure points, and new governance requirements.

Data realignment also presents hidden complexity. Historical data structures often do not map cleanly into new platforms. Transformation logic must be rewritten and validated, frequently under tight deadlines. Even minor discrepancies can create audit concerns and reporting inconsistencies.

These integrations and data adjustments extend well beyond initial go-live. Organizations often spend years refining connections that previously operated reliably. The cost of rebuilding trust in data is rarely included in financial models.

Escalating Vendor and Consulting Dependency

Migration initiatives typically require significant external expertise. Implementation partners, system integrators, and vendor specialists become central to delivery. While this support accelerates initial deployment, it can create a long-term dependency if internal capability is not intentionally rebuilt. Consulting costs often exceed original projections.

Vendor dependency also shifts leverage dynamics. Contract structures, licensing adjustments, and roadmap alignment may become more constrained after migration. Organizations that once exercised autonomy over their ERP environment may find themselves navigating predefined boundaries. That shift can affect innovation timelines and negotiation strength.

The strategic cost of reduced leverage is difficult to quantify, but it is very real. Over time, limited flexibility can restrict competitive advantage.

Organizational Fatigue and Cultural Impact

Large ERP migrations demand sustained attention from leadership and operational teams. Multi-year programs often compete with other strategic initiatives for funding and executive focus. This prolonged intensity creates organizational fatigue. When fatigue sets in, risk tolerance declines and innovation slows.

Cultural impact is equally significant. Teams that experience repeated disruptions may become hesitant to embrace future transformation efforts. Confidence in IT leadership can weaken if promised outcomes are delayed. These cultural effects influence long-term performance more than short-term budget overruns.

Unlike infrastructure costs, cultural impact does not appear in financial statements. However, it shapes the organization’s ability to execute future strategy. Ignoring this dimension creates blind spots in executive planning.

A Framework for Evaluating Hidden Costs

CIOs can mitigate hidden migration costs by expanding evaluation frameworks beyond licensing comparisons. A disciplined assessment should include:

• Modeled productivity decline during transition periods.

• Institutional knowledge retention strategies and succession planning.

• Full integration rebuilds inventories and data validation timelines.

• Multi-year consulting and vendor dependency projections.

Including these dimensions produces a more honest financial model. It also strengthens credibility with boards and executive peers. When leaders clearly articulate hidden costs, decision quality improves.

Migration may still be justified in certain scenarios. However, it should proceed with full awareness of both visible and invisible implications. Hidden costs do not eliminate modernization as an option. They simply require it to be evaluated with greater rigor.

Read more

☕ This Week’s Focus

Edition 27 centers on a theme that keeps resurfacing in 2026: ERP modernization is less about replacement and more about refinement.

Oracle continues to land major public-sector wins and expand its cloud footprint in federal modernization initiatives. At the same time, real-world ERP implementation stories remind us that success depends on thoughtful customization—not over-customization, not blind standardization.

Inside the PeopleSoft ecosystem, Cloud Manager continues to mature, PeopleTools 8.62 capabilities are expanding, and natural language experiences are moving from concept to delivered functionality.

Let’s break it down.

⚙️ Oracle, Public Sector & Cloud Expansion

🔗 Oracle Lands Air Force Win (Yahoo Finance)
https://finance.yahoo.com/news/oracle-lands-air-force-win-152003927.html
Oracle secured a significant contract win with the U.S. Air Force, reinforcing its position in federal cloud and infrastructure services. Public-sector validation remains one of Oracle’s strongest credibility anchors in 2026.

🔗 OCI to Support CMS Modernization Initiative (Oracle Press Release)
https://www.oracle.com/news/announcement/oracle-cloud-infrastructure-to-support-centers-for-medicare-and-medicaids-modernization-initiative-2026-02-11/
Oracle Cloud Infrastructure will support the Centers for Medicare & Medicaid Services’ modernization efforts. This is another large-scale healthcare transformation backed by OCI, signaling continued trust in Oracle’s ability to deliver secure, scalable environments.

Together, these stories reinforce an important point: while AI narratives dominate headlines, it’s infrastructure reliability and compliance capabilities that win major contracts.

📊 ERP Strategy: Why Smart Customization Matters

🔗 What Midwest Groundcovers Learned from Implementing a New ERP System (Greenhouse Grower)
https://www.greenhousegrower.com/technology/what-midwest-groundcovers-learned-from-implementing-a-new-erp-system/

This implementation story highlights a lesson seasoned ERP teams already understand: the danger isn’t customization. Rather, it’s unintentional customization.

Midwest Groundcovers discovered that blindly replicating legacy processes inside a new ERP system can stall transformation. At the same time, refusing all customization in the name of “best practice” can create operational friction.

The sweet spot is disciplined customization. Where processes are evaluated, simplified where possible, and extended only when business value justifies it.

For PeopleSoft teams, this lesson resonates. Event Mapping, Page & Field Configurator, and delivered frameworks exist precisely to enable thoughtful extension without destabilizing the core. Smart customization preserves upgradeability. Reactive customization destroys it.

👩‍💻 PeopleSoft Community & Practice

🔗 Image Highlights: Cloud Manager Image 21 (YouTube)

This video walks through key updates in Cloud Manager Image 21, including refinements in environment lifecycle automation, provisioning enhancements, and improved orchestration capabilities. For teams managing PeopleSoft in OCI, Cloud Manager continues evolving into a true platform operations tool—not just a deployment assistant.

🔗 Mastering Notification Composer & Landing Page Notifications in PeopleTools 8.62 (NewPeopleSoft Blog)
https://newpeoplesoft.wordpress.com/2026/02/11/mastering-notification-composer-and-landing-page-notifications-in-peopletools-8-62/
A detailed guide to using Notification Composer and landing page alerts effectively. These features are powerful when governed well, and distracting when overused. The key is intentional communication design.

🔗 Is GenerateComponentPortalURL Still Relevant? (JSMPros)
https://blog.jsmpros.com/2026/02/is-generatecomponentportalurl-still.html
A thoughtful technical exploration of whether older PeopleCode patterns remain appropriate in modern Tools releases. The answer isn’t binary. Some patterns evolve; others remain valuable when used properly. Modernization requires understanding, not reflexively replacing, core capabilities.

🔗 Natural Language Assistant in PeopleSoft (Oracle Blog)
https://blogs.oracle.com/peoplesoft/natural-language-assistant-in-peoplesoft
Oracle introduces Natural Language Assistant capabilities within PeopleSoft, enabling users to interact with the system more conversationally. This marks a tangible step toward embedded AI experiences inside PeopleSoft—not as an external bolt-on, but as part of the user workflow.

💬 Aaron’s Take

Edition 27 reinforces something I’ve seen repeatedly across ERP programs: durability beats drama.

Oracle’s public-sector wins demonstrate that reliability, compliance, and scale still matter more than hype. At the implementation level, stories like Midwest Groundcovers highlight that success comes from disciplined decisions, not extremes.

And inside the PeopleSoft world, the pattern continues: Cloud Manager gets stronger, Tools capabilities deepen, and AI becomes more practical.

The organizations that win in 2026 won’t be the ones chasing the newest acronym. They’ll be the ones who:

• Standardize where possible
• Customize where justified
• Automate where repeatable
• Govern where necessary

That’s not flashy. It’s effective.

🌐 Join the Community

If you’re finding value in these weekly breakdowns, subscribe at PeopleSoftCloud.com for:

✅ ERP and PeopleSoft modernization insight
✅ Cloud infrastructure and automation strategy
✅ Practical AI context for enterprise systems

See you in Edition 28.

The reality is this:

PeopleSoft didn’t fail us.
Our operating model failed PeopleSoft.

When organizations struggle with PeopleSoft, the root cause is rarely the software itself. It’s almost always the way we deploy, govern, and own it. If you moved this same legacy mindset and operating model to any other ERP, it would look slow, brittle, and outdated, too.

Subscribe now

Legacy Thinking Creates “Legacy Systems”

For years, many PeopleSoft environments have been run with habits formed in a very different era:

* Manual builds that only one or two people understand.
* Environment drift that makes every change risky.
* Release processes held together by spreadsheets and tribal knowledge.
* Monitoring that relies on users reporting problems after the fact.

None of that is a PeopleSoft limitation. That’s an operating model problem.

If you applied those same practices to a modern SaaS-adjacent platform, it would degrade just as quickly. Complexity compounds when discipline is missing.

Modernization Is an Operating Shift, Not a Rip-and-Replace

True PeopleSoft modernization starts with a mindset shift: treating PeopleSoft as a platform, not just an application.

Platform thinking changes the questions leaders ask. Instead of “How fast can we get off PeopleSoft?” the question becomes “How do we operate this platform in a modern, resilient way?”

That leads directly to fundamentals:

* Automation instead of hand-built environments
* Repeatable infrastructure instead of one-off fixes
* Version control instead of shared folders
* Observability instead of reactive troubleshooting

When these elements are in place, PeopleSoft behaves very differently. Deployments become predictable. Failures become visible early. Teams spend less time firefighting and more time improving.

Governance and Ownership Matter More Than Tools

Another quiet failure point is ownership. In many organizations, PeopleSoft sits in an awkward gap between infrastructure, applications, and the business. No single group owns the full lifecycle, so decisions get fragmented and slow.

Modern platforms require clear ownership models. Someone must be accountable for how the system is built, operated, secured, and improved over time. Without that clarity, even the best tooling can’t compensate. This is why many “modernization” efforts stall. They focus on technology choices while leaving governance untouched.

The Real Question Leaders Should Be Asking

The most important question isn’t whether PeopleSoft is still viable.

It’s this: Are we operating it in a way that would succeed on any platform?

If the answer is no, moving to the cloud or to SaaS won’t fix the underlying issue. It will just shift the pain and usually increase the cost.

PeopleSoft didn’t fail us.
Our operating model failed PeopleSoft.

And the good news is that operating models can be redesigned, without starting over. If you fix the operating model, PeopleSoft is a differentiator, not an anchor.

Today, that framing creates friction. When PeopleSoft is viewed only as an application, investment decisions focus on maintenance rather than capability. Teams optimize for minimizing disruption instead of enabling outcomes. Over time, the system becomes isolated from broader enterprise strategy, even though it remains central to business operations.

An application mindset also limits leadership imagination. It encourages CIOs to think defensively rather than strategically. As enterprise architectures evolve, this narrow framing increasingly fails to reflect how PeopleSoft is actually used.

What It Means to Treat PeopleSoft as a Platform

A single interface or deployment model does not define a platform. It is defined by its ability to enable other systems, teams, and capabilities. When PeopleSoft is treated as a platform, it becomes an anchor point for data, process, and integration rather than a standalone workload. This shift changes how leaders evaluate value.

Platform thinking recognizes that PeopleSoft already powers critical enterprise workflows. It also acknowledges that those workflows generate data and events that other systems depend on. Instead of insulating PeopleSoft from change, a platform mindset exposes it in controlled and intentional ways. APIs, integration frameworks, and automation become first-class design considerations.

Most importantly, platform thinking reframes PeopleSoft as an enabler of innovation rather than an obstacle. That reframing unlocks new conversations between IT and the business. The system stops being something to work around and starts being something to build on.

Read more

The CIO arrived at 8 AM sharp, along with CFO Patricia Winters and VP of Business Operations James Chen. Maya had the conference room set up with her laptop connected to the projector, the infrastructure repository open in one window, a terminal in another.

“Good morning,” Harrison said, settling into his chair. “I understand you have a demonstration.”

“We do,” Maya said. “Three weeks ago, you gave us twelve weeks to prove PeopleSoft modernization could compete with SaaS migration. I want to show you what we’ve accomplished in the first three weeks.”

She pulled up her summary slide:

Weeks 1-3: Foundation Complete

• Week 1: Honest assessment, baseline metrics, quick wins

• Week 2-3: Infrastructure as Code implementation

• Result: 99.7% faster environment provisioning, $178K annual savings (dev only)

“Show me the demo,” Harrison said—no preamble, straight to business.

Maya opened her terminal. “I’m going to provision a complete PeopleSoft environment from scratch. When I run this command, Terraform and Chef will build a database, application servers, web servers, networking, storage, and configuration—everything needed for a functional PeopleSoft instance.”

She typed the command and hit enter.

“How long will this take?” Winters asked.

“About seventy-five minutes,” Maya said. “Our baseline three weeks ago was eighteen days.”

Winters blinked. “Eighteen days to seventy-five minutes?”

“Correct. And I’m not doing anything during these seventy-five minutes except watching automated processes run. Previously, this would have required multiple engineers working across multiple teams for days.”

They watched as infrastructure was provisioned in real-time. Harrison asked sharp questions—What happens if it fails? How do you validate correctness? Can you rebuild production this way? Maya answered each question confidently, occasionally pulling in Jake or Tom for technical details on database configuration or application-tier setup.

Seventy-three minutes later, the PeopleSoft sign-in screen appeared.

Harrison was quiet for a moment. “That’s… impressive. Walk me through the business value.”

Maya pulled up her cost analysis. “This dev environment costs us $110 per month to run versus $14,000 in our data center. Admin time to maintain it drops from forty hours per quarter to near zero. Total savings for this one environment: $178,000 annually. We have four environments. Extrapolating—”

“Seven hundred thousand per year,” Winters finished, doing the math. “That’s significant.”

“And that’s before we account for improved velocity,” Maya added. “When our developers can spin up test environments in an hour instead of waiting weeks, they move faster. When we can rebuild from disaster in ninety minutes instead of hoping our untested backup scripts work, we reduce risk. When our infrastructure knowledge lives in version-controlled code instead of tribal memory, we eliminate key person dependencies.”

Harrison leaned back. “What’s your plan for the next nine weeks?”

“Week 4, which starts today: CI/CD pipelines for automated testing and deployment of customizations. Week 5: Database modernization using managed services. Weeks 6-7: Observability and monitoring infrastructure. Week 8-9: Security automation and integration modernization. Weeks 10-12: Cost validation, scaling tests, and final presentation.”

“You’re on track?” Harrison asked.

“We’re ahead of track,” Maya said honestly. “I expected the infrastructure as code work to take three weeks with lots of struggles. We completed it in two weeks, delivering high-quality results. The team is learning faster than I anticipated.”

Harrison stood. “Good. Keep going. I want weekly updates. And Maya—this is good work. Genuinely impressive. But you’re still proving a concept. I need to see this working in production before I can take it to the board as an alternative to the SaaS plan.”

“Understood,” Maya said. “By Week 12, we’ll have production evidence.”

After the executives left, Maya’s team emerged from their desks where they’d been nervously monitoring the demo.

“How’d it go?” Tom asked.

“Harrison called it genuinely impressive,” Maya said. “Which from him is practically a standing ovation.”

“So we’re good?” Jake asked.

“We’re good for now,” Maya said. “But he’s right—we’re still proving a concept. We need production validation. Which means everything we build in the next nine weeks needs to be production-ready, not just demos.”

She pulled up the Week 4 plan on the screen. “Speaking of which: CI/CD pipelines. This week, we’re going to automate the testing and deployment of PeopleSoft customizations. No more manual exports and imports. No more emailing project files around. No more deployments that take six hours. We’re building a pipeline.”

“Before we dive into that,” Sarah said carefully, “we need to talk about something that happened over the weekend.”

Maya’s stomach dropped. “What happened?”

“Production incident. Saturday at 2:47 AM. Integration Broker went down. Took forty-three minutes to detect. A batch job had failed, and someone checked their email. Took another ninety minutes for Marcus to troubleshoot and fix. Total outage: two hours, thirteen minutes.”

“What caused it?” Maya asked.

“Web server ran out of memory and crashed,” Marcus said. “Took the IB domain with it. We don’t have memory monitoring, so I didn’t know what was wrong until I SSH’d into each server, checked logs, found the out-of-memory errors, and restarted services.”

“Two hours to diagnose a memory issue,” Maya said flatly.

“In my defense, the logs are spread across seventeen servers with no aggregation,” Marcus said. “I had to check each one manually. And our monitoring only watches whether processes are running, not whether they’re healthy.”

Maya walked to the whiteboard and wrote in large letters: “WEEK 4 REVISED PLAN: OBSERVABILITY FIRST.”

“Here’s the thing,” Maya said, turning to face her team. “We can build the prettiest CI/CD pipeline in the world, but if we can’t see what’s happening in production, we’re still operating blind. Saturday’s incident proved that. We need observability before we need CI/CD.”

“What’s the difference between monitoring and observability?” Priya asked.

“Great question,” Maya said. “Monitoring tells you something is broken. Observability tells you why it’s broken and helps you understand system behavior. Right now, we have basic monitoring—we know when a process dies. But we don’t have observability. We can’t answer questions like ‘Why is the system slow?’ or ‘What changed before this error started?’ or ‘Which integration is causing database contention?’”

She drew three columns on the whiteboard: Logs, Metrics, Traces.

“These are the three pillars of observability,” Maya explained. “Logs tell you what happened—detailed records of events, errors, transactions. Metrics tell you how the system is performing, including CPU, memory, response times, throughput. Traces tell you the path a request takes through your system—from web server to app server to database and back.”

“We have logs,” Tom pointed out.

“We have logs scattered across seventeen servers in different formats with no way to search them efficiently,” Maya corrected. “Marcus spent ninety minutes manually grepping through log files on Saturday. That’s not observability. That’s archaeology.”

“So what does good observability look like?” Lisa asked.

Maya pulled up her laptop and opened a screenshot she’d saved from her previous role—a Grafana dashboard with colorful charts showing system metrics, error rates, and response times, all in real-time.

“This is what we’re building toward,” she said. “A single pane of glass where we can see everything happening in our PeopleSoft environment. Application server health. Database performance. Integration throughput. User experience metrics. Error rates. Everything.”

“And when something breaks?” Jake asked.

“We see it immediately,” Maya said. “The dashboard shows the anomaly. We can drill into logs filtered by timeframe and component. We can see what changed right before the problem started. We can correlate events across different systems. Instead of spending ninety minutes figuring out what’s wrong, we spend five minutes confirming what we already suspect and fifteen minutes fixing it.”

“That sounds expensive,” Tom said. “Enterprise monitoring tools cost a fortune.”

“It would be,” Maya agreed, “if we were buying commercial tools. But we’re going to build it using open source: OpenSearch for log aggregation and analysis, Prometheus for metrics collection, Grafana for visualization, and Tempo for distributed tracing. Total cost: mostly our time to implement, plus about $200/month in infrastructure to run it.”

Sarah was nodding enthusiastically. “This is actually going to make our lives so much better. I’ve worked with observability stacks before. Once you have good observability, you can’t imagine working without it.”

“Okay,” Maya said. “Here’s the Week 4 plan, revised. Monday through Wednesday: we implement centralized logging with OpenSearch. Every log from every PeopleSoft component flows into a single location where we can search it. Thursday through Friday: we implement metrics collection with Prometheus and build our first Grafana dashboards. Next week, we’ll add distributed tracing and alerting.”

“That’s a lot for one week,” Marcus said.

“It is,” Maya admitted. “But we’re not building perfection. We’re building ‘better than Saturday night.’ If by Friday we have centralized logs and basic metrics, we’ve massively improved our ability to troubleshoot. The rest can evolve.”

“Who’s doing what?” Priya asked.

“Marcus, you’re leading the OpenSearch implementation since you already researched it in Week 1. Sarah, you’re helping Marcus with the technical architecture. Jake, you’re instrumenting the database to export metrics—Oracle has built-in monitoring views we can scrape. Tom, you’re configuring log shipping from all the application servers. Priya and Lisa, you’re documenting what we learn and building runbooks for using the observability tools.”

“And you?” Tom asked.

“I’m building the Grafana dashboards and figuring out what we need to measure to prove our system is healthy,” Maya said. “Plus, I’m talking to other teams who might want to consume our metrics. If we’re building an observability platform, we should make it useful beyond just PeopleSoft.”

She capped the marker. “Questions?”

“Yeah,” Jake said. “What do we do about Saturday’s incident? Do we need to file some kind of post-mortem or incident report?”

“We do,” Maya said. “And we’re going to use it as a teaching moment. Let me show you what a blameless post-mortem looks like.”

Read more

👋 Welcome Back

After a short hiatus, The Modern ERP Digest is back with Edition 26.

Sometimes a pause is useful. It gives space to see which stories actually matter after the initial headlines fade. Coming back into 2026, one thing is clear: the ERP conversation has sharpened. AI hype is colliding with legal scrutiny, capital markets are watching Oracle closely, and enterprises are making more deliberate, modular decisions about how ERP fits into their future.

Subscribe now

This edition reflects that shift. It blends market pressure, AI ambition, and very real PeopleSoft progress—exactly where ERP leadership lives today.

☕ This Week’s Focus

Edition 26 centers on credibility and consequence.

Oracle’s AI narrative is being tested by lawsuits and investor scrutiny, even as enterprises continue adopting Oracle technologies at scale. At the same time, PeopleSoft continues to move forward with meaningful HCM enhancements, and the broader ERP market is openly embracing best-of-breed and agentic AI models.

This isn’t a step backward. It’s a sign of maturity.

⚙️ Oracle, Markets & AI Pressure

🔗 Investors Sue Oracle, Alleging Executives Sold $18.7B Amid AI Hype (InvestmentNews)
https://www.investmentnews.com/regulation-legal-compliance/investors-sue-oracle-allege-executives-dumped-187b-amid-ai-hype/265164
Investors have filed lawsuits alleging that Oracle executives sold significant stock during peak AI enthusiasm. Regardless of outcome, the story underscores how closely Oracle’s AI messaging is being examined—and how accountability follows ambition.

🔗 Oracle Plans $50B Capital Raise to Support Cloud Infrastructure Demand (ERP Today)
https://erp.today/oracle-plans-50b-capital-raise-to-support-cloud-infrastructure-demand/
Oracle’s reported plan to raise $50B for cloud infrastructure highlights the scale of demand it’s betting on. This move reinforces Oracle’s belief that AI and cloud workloads will continue to grow, but also raises expectations around execution and returns.

🔗 U.S. Enterprises Increasingly Adopting Oracle Solutions (Yahoo Finance)
https://finance.yahoo.com/news/u-enterprises-increasing-adopting-oracle-180845415.html
Despite market noise, adoption data tells a steadier story. U.S. enterprises continue expanding their use of Oracle platforms, suggesting that while sentiment swings, operational decisions remain grounded in capability and trust.

📊 ERP, AI & Industry Direction

🔗 Reimagining ERP for the Agentic AI Era (MIT Technology Review – Report Overview)
https://www.technologyreview.com/2026/01/20/1129965/reimagining-erp-for-the-agentic-ai-era/
This downloadable report explores how ERP systems are evolving from systems of record into systems of action. Agentic AI, orchestration layers, and autonomous workflows are central themes. The key takeaway: ERP isn’t being replaced—it’s being repositioned.

🔗 ERP in 2026: More AI, More Best-of-Breed Add-Ons (CIO.com)
https://www.cio.com/article/4121113/erp-in-2026-more-ai-more-best-of-breed-add-ons.html
CIO.com outlines a clear trend for 2026: core ERP platforms paired with specialized tools. Rather than monolithic replacements, organizations are layering AI, analytics, and niche capabilities on top of stable ERP foundations.

🔗 ERP Survey Shows Customers Re-Evaluating Vendor Value (The Register)
https://www.theregister.com/2026/01/19/erp_survey_rimini_street/
Survey results highlighted by The Register show growing scrutiny of ERP vendor costs and roadmaps. Customers are demanding clearer value, longer viability, and less forced migration—signals that favor platforms teams truly understand.

👩‍💻 PeopleSoft Community & Practice

🔗 What’s New in PeopleSoft HCM Update Image 54 (Oracle Blog)
https://blogs.oracle.com/peoplesoft/whats-new-in-peoplesofts-hcm-update-image-54-key-enhancements-and-features
Oracle details the latest HCM Image 54 enhancements, including usability improvements, feature refinements, and continued investment in employee and manager self-service. It’s another reminder that PeopleSoft HCM remains an actively evolving platform.

🔗 Cornell’s Duffield Gift Highlights Long-Term PeopleSoft Impact (WSJ)
https://www.wsj.com/us-news/education/cornell-duffield-gift-engineering-donation-peoplesoft-fc1894a3
The Wall Street Journal recounts how Cornell’s engineering program benefited from alum success tied in part to PeopleSoft’s early growth. It’s a rare mainstream acknowledgment of PeopleSoft’s lasting influence in higher education and enterprise technology.

💬 Aaron’s Take

Edition 26 reinforces a pattern that’s becoming impossible to ignore: ERP is no longer about promises—it’s about proof.

Oracle is betting big on AI and cloud, and the markets are watching closely. Lawsuits, capital raises, and adoption metrics all tell different parts of the same story. Ambition attracts scrutiny, and scrutiny demands results.

At the same time, PeopleSoft teams are quietly moving forward—adopting new HCM features, modernizing selectively, and operating within architectures they actually understand. Across the industry, organizations are choosing composition over replacement and intention over impulse.

That’s not hesitation. That’s maturity.

If 2025 was about sorting hype from signal, 2026 is shaping up to be about earning trust—technically, financially, and operationally.

I’m glad to be back. Let’s keep going.

🌐 Join the Community

If you’re reading this after the break, now’s a great time to subscribe at PeopleSoftCloud.com for:

✅ Weekly ERP, PeopleSoft, and cloud insights
✅ Practical context around AI and platform decisions
✅ Signals that matter for real enterprise teams

Thanks for sticking around—and welcome back to The Modern ERP Digest.

Every major cloud provider can technically run PeopleSoft. That fact alone does not make them equivalent. Each platform encodes assumptions about control, customization, pricing, and governance. CIOs need to understand those assumptions before committing the organization to a multi-year operating model.

The most crucial cloud question is not whether PeopleSoft will run. The real question is what kind of enterprise you are building once it does.

Cost Is More Than Infrastructure Pricing

Cloud cost conversations often start with compute and storage pricing. While those numbers matter, they rarely determine long-term spend. The most significant cost drivers tend to be operational complexity, licensing interactions, and the degree of automation an organization can realistically sustain. These factors vary significantly by cloud platform.

Some environments encourage standardization and infrastructure-as-code, which lowers marginal costs over time. Others rely more heavily on managed services that trade simplicity for long-term expense. CIOs must look beyond first-year projections and understand how costs behave at scale. A platform that looks inexpensive early can become restrictive and expensive as requirements grow.

Cloud cost discipline depends on visibility, governance, and internal capability. The more control the organization retains, the more options it has to optimize. That control is not evenly distributed across providers.

Read more

What has changed is how leaders think about that reality. Instead of forcing everything into a single platform, CIOs increasingly focus on orchestration, integration, and clear ownership. Hybrid ERP enables organizations to continue innovating while preserving stability in core systems. This balance matters because it helps ensure that the pace of change is manageable across all systems. Treating every system as equally disposable creates unnecessary risk.

Stability and Innovation Are Partners

A common misconception in ERP strategy is that stability and innovation sit on opposite ends of a spectrum. In this framing, stable systems are slow, and innovative systems are fragile. This thinking leads organizations to push core platforms aside in pursuit of speed. Over time, that approach undermines both reliability and confidence.

In practice, stability enables innovation when intentionally used. A reliable system of record provides clean data, predictable processes, and trusted outcomes. Innovation builds more effectively on that foundation than on constantly shifting platforms. When leaders recognize this relationship, strategy shifts from replacement to enablement.

Hybrid ERP works because it assigns different roles to different systems. Core ERP remains focused on transactional integrity and governance. Surrounding platforms handle experimentation, user experience, and rapid iteration. Each system plays to its strengths instead of competing for relevance.

Read more

Sarah and Priya had demonstrated a working Python script that automated the PeopleTools patch download process. This was a task that typically consumed half a day of manual clicking through Oracle Support, checking versions, and organizing files into the correct directory structure. Their script took twelve minutes.

Jake had completed his disaster recovery test. The actual RTO? Fourteen hours and twenty-two minutes, which was better than his pessimistic estimate, but still unacceptable by modern standards. He’d documented every step, identified three configuration errors in the backup scripts, and updated the runbooks. “At least now we know,” he’d said.

Marcus had delivered a compelling one-page proposal for OpenSearch-based log aggregation, including a cost estimate ($3,200/year for hosted OpenSearch vs. $0 for self-hosted on existing infrastructure) and a clear value proposition: “Instead of SSHing into seventeen servers and grepping logs for forty minutes, we could search centralized logs in under two minutes.”

Tom had documented the development environment’s configuration, covering everything from Oracle initialization parameters to Tuxedo domain settings to web server tuning. “It was even more complicated than I thought,” he’d admitted. “No wonder new people take six months to understand our environment.”

Lisa had thoroughly tested Sarah’s patch script, found two edge cases that broke it, and worked with Sarah to fix them. “It actually works,” she’d reported, sounding surprised. “We could use this for real.”

Maya had sent her first weekly status report to Robert Harrison with actual metrics: baseline deployment time (6.5 hours average), baseline MTTR (2.3 hours), baseline environment provisioning time (18 days), baseline DR RTO (14.4 hours). All of these were terrible numbers. But now they were documented, measured, and ready for improvement.

Harrison’s response had been brief: “Good start. Show me better numbers next week.”

Now it was Monday morning of Week 2, and Maya had gathered the team for what she knew would be the hardest conversation of the twelve-week challenge.

“Week 2,” she announced, “is when we stop scripting and start engineering.”

Tom looked up from his coffee. “What’s the difference?”

Maya pulled up a slide on the conference room screen. “Scripts are how you automate a task. Infrastructure as Code is how you automate an entire system. Scripts are what got us through Week 1. IaC is what gets us to Level 3.”

She clicked to the next slide: a comparison table.

Scripts vs. Infrastructure as Code:

Scripts

• Procedural (do this, then this)

• Imperative commands

• Hard to maintain

• Environment-specific

• No version control standard

• Manual sequencing

• Hope it works

Infrastructure as Code

• Declarative (make it look like this)

• Desired state

• Self-documenting

• Portable

• Git-native

• Dependency management

• Testable and repeatable

“Here’s our goal for Weeks 2 and 3,” Maya said. “We’re going to take Tom’s 847 lines of documentation and turn it into infrastructure code that can provision a complete PeopleSoft environment, including database, application tier, web tier, and everything else, from scratch. On Google Cloud Platform.”

The room went very quiet.

Jake broke the silence. “Using what tools?”

“Terraform for infrastructure provisioning,” Maya said. “Chef for configuration management. Git for version control. Industry standard stack used by thousands of companies.”

“I don’t know Terraform,” Jake said flatly.

“None of us do,” Maya replied. “We’re going to learn.”

“Maya,” Tom said carefully, “I’ve been doing PeopleSoft infrastructure for fifteen years. I’ve written hundreds of shell scripts. Bash, PowerShell, and even some Perl back in the day. I know how to automate. Why do I need to learn a new tool?”

Here it was. This was the resistance Maya had been expecting.

She sat down across from Tom. “Tell me about your shell scripts. The ones that provision environments.”

“What about them?”

“How many do you have?”

Tom thought. “Maybe… twenty? Thirty? For different tasks.”

“And when you need to provision a new environment, you run them in sequence?”

“Right. First, the OS configuration script, then the Oracle install script, then the PeopleSoft app tier script—”

“And if one fails partway through?”

“I fix whatever broke and rerun it. Sometimes I have to clean up partial installations first.”

“And if someone else needs to run your scripts?”

Tom shifted uncomfortably. “They’d need to know the sequence. Some scripts use hard-coded paths that need to be updated across environments. And there are dependencies between scripts that aren’t obvious unless you know what you’re doing.”

“So your scripts work great,” Maya said, “if you’re the one running them, in the right order, with the right environment-specific changes, and nothing fails. How long would it take to teach someone else—say, Sarah—to provision an environment using your scripts?”

“I don’t know. A few weeks? She’d need to shadow me through a few builds.”

“And if you got hit by a bus tomorrow?”

“Please stop using that example,” Tom said.

“The point stands,” Maya replied. “Your scripts are better than nothing. They’ve served us well. But they’re not infrastructure-as-code. They’re Tom Patterson as code. And we can’t build a modern operation on tribal knowledge, no matter how well-scripted.”

Jake jumped in. “I’ve got the same thing with my Oracle automation. My scripts work because I wrote them and I know all the gotchas. But Maya’s right; they’re not transferable. When we hire someone new, it takes six months before I trust them to run a database build without me watching.”

“Exactly,” Maya said. “Infrastructure as Code solves this. With Terraform, we declare what infrastructure we want and how we want it. The Terraform code says we want these VMs with these specs, this database with these parameters, these network routes, these firewall rules. Terraform figures out how to make it happen. The code is self-documenting. It’s in Git, so we have version control and change history. It’s testable. And most importantly, it’s repeatable. Run it once, run it a thousand times, you get the same result.”

“But I don’t know how to write Terraform,” Tom repeated.

“You didn’t know how to write shell scripts fifteen years ago either,” Maya said. “You learned.”

“I was thirty then. I’m forty-five now. Learning gets harder.”

Sarah spoke up. “I’m twenty-six, and I’m learning this stuff alongside you. If you want, I can help. Terraform syntax is different from bash, but the concepts aren’t that foreign. You’re still describing what needs to happen. You’re just doing it in a different language.”

Tom looked at Sarah, then at Maya. “This is really happening? We’re throwing out fifteen years of scripts and starting over?”

“Not throwing out,” Maya corrected. “Evolving. Your scripts taught us what to automate. Now we’re making that automation maintainable, scalable, and cloud-native. By Week 3, we’ll have infrastructure code that can spin up a complete PeopleSoft environment in under two hours instead of eighteen days.”

“Two hours?” Tom’s skepticism was evident. “For a full PeopleSoft stack?”

“Two hours,” Maya confirmed. “That’s the power of IaC on cloud infrastructure. No waiting for the infrastructure team. No manual installations. No configuration drift. Just code, version control, and automation.”

Jake leaned back in his chair. “Okay, I’ll bite. Walk us through what this actually looks like. Not the code itself; just conceptually, what are we building?”

Maya smiled. She’d prepared for this.

The Architecture Conversation

Maya pulled up a diagram she’d sketched over the weekend. “Let’s talk about how we’re going to structure this. The key to good infrastructure-as-code is modularity. You start by breaking the whole system into logical, reusable pieces.”

She pointed to the diagram showing five boxes: Network, Compute, Database, Storage, and Configuration.

“We’re going to build five modules,” Maya explained. “Each one is responsible for one piece of the puzzle. The Network module handles VPCs, subnets, firewall rules, and load balancers. The Database module provisions our Oracle Cloud SQL instance with all the right parameters. Compute handles the VMs. This’ll build application servers, web servers, and process schedulers. Storage manages our file shares and backup buckets. And Configuration is where Chef comes in, actually, to set up the software.”

“Why break it up that way?” Marcus asked.

“Reusability,” Maya said. “Let’s say we get the Network module working for dev. That exact same module can be used for QA, stage, and prod. All we need to do is pass in different parameters. Same code, different inputs, different environments. That’s how we guarantee environmental parity.”

“And it’s maintainable,” Sarah added. “If we need to change how networking works, we change the Network module. We don’t have to hunt through seventeen different shell scripts trying to find where firewall rules are configured.”

“Okay,” Tom said slowly. “I can see the value in organization. But what’s the actual workflow? How does this replace what we do today?”

Maya walked to the whiteboard. “Today, when you need to build an environment, what’s the process?”

Tom recited from memory. Submit a ticket to the infrastructure team for VMs. Wait a week. Get VMs. Spend two days installing and configuring the OS. Call Jake to install Oracle, which takes him two days. Wait for Jake to finish. Install the application tier, which takes me three days if nothing breaks. Configure domains, set up web servers, which takes another two days. Testing connectivity and fixing issues takes another day. So, best case, seven to eight days of actual work spread across three weeks of calendar time.”

“And every environment is slightly different because they were built at different times by different people using slightly different procedures,” Maya said.

“Right,” Tom admitted.

“Now here’s the new workflow,” Maya said. “Someone, it really doesn’t matter who it is, goes to the infrastructure repository in Git. They navigate to the environment they want to build. They run three commands: terraform init, terraform plan, and terraform apply. Then they go get coffee for ninety minutes. When they come back, the environment is running.”

“That’s it?” Lisa asked.

“That’s it,” Maya said. “Terraform reads the infrastructure definition, figures out what needs to be created and in what order, provisions everything in GCP, then hands off to Chef to configure the software. Everything we do manually today gets encoded into the infrastructure definition. Tom’s OS configuration knowledge goes into Chef recipes. Jake’s Oracle setup expertise goes into database configuration files. My domain setup procedures become Chef cookbooks.”

“Wait,” Jake said. “You keep mentioning Chef. Why Chef specifically? I’ve heard of Puppet, Ansible, all these configuration management tools. What makes Chef the right choice?”

“Good question,” Maya said. “Chef has a few things going for it for our use case. It’s mature and battle-tested; it’s been around since 2009. It has strong enterprise support. The Ruby-based DSL is actually pretty readable once you get past the initial learning curve. And critically, it has good patterns for managing the kind of complex, stateful configuration that PeopleSoft environments need.”

“Plus,” Sarah interjected, “Chef has this concept of cookbooks and recipes that maps really well to how we think about PeopleSoft configuration. You have a cookbook for Oracle setup, a cookbook for PeopleTools installation, a cookbook for domain configuration. Each cookbook contains recipes for specific tasks. It’s very modular.”

“Isn’t the learning curve steep?” Priya asked.

“All of these tools have a learning curve,” Maya acknowledged. “But Chef’s actually not bad. The DSL reads almost like plain English; you’re declaring resources and their desired state. ‘This file should exist with these contents and these permissions.’ ‘This service should be running.’ ‘This package should be installed.’ It’s declarative, like Terraform, which means you describe what you want, not how to get there.”

Tom was taking notes. “So Terraform provisions the infrastructure, including the VMs, the database, and the network. And Chef configures the software on that infrastructure?”

“Exactly,” Maya said. “They’re complementary tools. Terraform is great at infrastructure provisioning, but not great at managing complex application configuration. Chef is great at configuration management, but it is not designed for infrastructure provisioning. Together, they cover the full stack.”

“How do they work together?” Marcus asked. “Like, mechanically?”

“Terraform provisions a VM and can run Chef automatically as part of the provisioning process,” Maya explained. “So Terraform creates your application server VM, and as part of the creation process, it installs the Chef client and runs the appropriate cookbooks. By the time Terraform finishes, you have a fully configured application server ready to join the domain.”

Jake was nodding. “Okay, I’m starting to see how this fits together. But here’s my concern: I know how to configure an Oracle database. I know every parameter, every tablespace setting, every tuning option. How do I translate that knowledge into Chef recipes?”

“That’s actually the beauty of it,” Maya said. “You don’t have to learn Chef deeply to contribute your Oracle knowledge. Sarah’s going to become our Chef expert, and she’ll learn the syntax and the patterns. Your job is to tell her what a properly configured PeopleSoft database looks like. She will need to know things like what parameters need to be set, which tablespaces need to exist, and which users need to be created with what privileges. She translates your expertise into Chef recipes. You review them to make sure they’re doing the right thing.”

“So I don’t have to become a Chef programmer?” Jake sounded relieved.

“You should learn enough to read and understand Chef recipes,” Maya said. “But you don’t need to be an expert. We’re playing to everyone’s strengths. Jake knows Oracle. Tom knows application server configuration. Priya knows the PeopleSoft domain setup. Sarah knows coding patterns and modern tooling. We combine that knowledge.”

“What about testing?” Lisa asked. “With my manual builds, I can see each step happening. How do I test infrastructure that builds automatically?”

“That’s one of the biggest advantages of IaC,” Maya said. “We build automated validation into the process. After Terraform provisions the database, we run tests—can we connect? Is the tablespace configuration correct? Are the backup jobs scheduled? After Chef configures an application server, we test—did the PeopleTools installation complete? Is the domain configured correctly? Are the processes running?”

“And if something fails?” Tom asked.

“Then the build fails, and we know exactly where it failed and why,” Maya said. “No more ‘I think it’s configured correctly.’ We have automated validation that proves it’s configured correctly. And because everything’s in code, we can test changes before we apply them to production. Want to change an Oracle parameter? Change it in the code, apply it to dev, and run your validation tests. If it works, promote the same code change to QA, then to prod. The code that builds dev is the same code that builds prod, just with different size parameters.”

“That’s environmental parity,” Sarah said. “It’s a big deal. Right now, our dev environment is kind of like prod, but not exactly. Different Oracle patches, slightly different configurations, different disk layouts. So sometimes things work in dev and break in prod. With IaC, dev and prod are identical except for scale. Same configurations, same versions, same everything. That massively reduces ‘works on my machine’ problems.”

Tom was quiet for a moment. “Okay. I’m starting to see the value. But I need you to be honest with me about something, Maya. How hard is this going to be to learn? Because I’m looking at two weeks to learn Terraform and Chef well enough to build production-grade infrastructure, and that seems… ambitious.”

Maya sat down next to him. “It’s going to be hard,” she said honestly. “The first few days, you’re going to feel lost. Terraform has its own language—HCL—and its own way of thinking about infrastructure. Chef has Ruby DSL and its own concepts. You’re going to write code that doesn’t work. You’re going to get error messages you don’t understand. You’re going to want to just write a bash script because it’s faster and you know how.”

“That’s not a great sales pitch,” Tom said.

“But here’s the thing,” Maya continued. “You’re not learning to become a Terraform expert or a Chef expert. You’re learning enough to encode your infrastructure knowledge in a maintainable way. By the end of Week 2, you won’t be an expert. But you’ll be able to read infrastructure code and understand what it’s doing. By the end of Week 3, you’ll be able to write basic modules. That’s sufficient. Expertise comes with time.”

“And we’re all learning together,” Priya added. “I don’t know this stuff either. None of us does except Sarah. So when you get stuck, you’re not the only one struggling.”

Jake raised his hand. “One more conceptual question before we dive in. Why are we doing this specifically on GCP? Why not AWS or Azure?”

“Honestly? Partly because I have more experience with GCP,” Maya admitted. “But also, GCP has really strong Oracle support now with the new Oracle Exadata at GCP offering. This provides Oracle databases with the ability to do automated backups, patching, and high availability, which is already built in. That’s huge for us. AWS has Oracle, too, and Azure has managed Oracle, so we’re not locked in. But for learning, we needed to pick one and go deep.”

“Here’s the thing though,” Sarah said. “Once we have IaC working on GCP, porting it to AWS or Azure isn’t that hard. The concepts translate. Terraform supports all the major cloud providers. Chef works the same everywhere. So we’re learning patterns that are portable.”

“The specific cloud provider matters less than you think,” Maya said. “What matters is the operational model—infrastructure as code, version-controlled configurations, automated validation, repeatable builds. That model works on any cloud. We’re just using GCP as the learning platform.”

Marcus leaned forward. “So what’s the actual plan? How are we spending the next two weeks?”

Maya pulled up the schedule she’d built. “Today and tomorrow: intensive training. We’re all going through the HashiCorp Terraform tutorials and the Chef learning resources. Not trying to become experts—just getting familiar with the concepts and syntax. Wednesday through Friday this week: hands-on experimentation. Everyone picks one piece—Jake, you’re exploring Terraform’s database provisioning. Tom, you’re looking at compute resources. Marcus, you’re diving into networking. Priya, you’re prototyping Chef cookbooks for PeopleSoft configuration.”

“What about Week 3?” Lisa asked.

“Week 3 is building for real,” Maya said. “Monday through Thursday, we’re writing the actual infrastructure code for our dev environment. Each person owns their module. We do code reviews—yes, we’re reviewing infrastructure code just as we do application code. Friday, we do the demo. We run the infrastructure build from scratch in front of each other and prove it works.”

“And if it doesn’t work?” Tom asked.

“Then we debug and fix it,” Maya said simply. “But I don’t think it will work, I know it will. Because we’re going to test as we build. Every module gets validated independently before we integrate it.”

She stood up and walked to the whiteboard. “Here’s what success looks like at the end of Week 3: We can provision a complete PeopleSoft environment from code in under two hours. We have version-controlled infrastructure that anyone on the team can deploy. We have automated validation that proves the environment is configured correctly. And we have evidence—real, demonstrable evidence—that we’re operating at a higher level than we were three weeks ago.”

“That’s a lot for two weeks,” Tom said.

“It is,” Maya agreed. “But look at what we did in Week 1. Sarah and Priya automated patch downloads. Jake validated our DR process. Marcus designed our logging strategy. Tom documented 847 lines of configuration. You all did hard things last week. This week is just a different kind of hard.”

“What if we fail?” Jake asked quietly.

“Then we learn why we failed and adjust,” Maya said. “But here’s what I know about this team: you’re all capable of way more than you think you are. Three weeks ago, how many of you would have said you could write a Python script to automate patch downloads?”

Sarah raised her hand. No one else did.

“And now Priya’s comfortable enough with Python to pair with Sarah on that script,” Maya said. “That’s growth. That’s what these twelve weeks are about—discovering that you can learn things you thought were beyond you.”

She grabbed the marker. “Okay. Let’s talk about what each person is focusing on. Jake, you’re building the database module for Terraform and the Oracle configuration cookbook for Chef. Your expertise is Oracle, and now you’re encoding that expertise in infrastructure code.”

Jake nodded slowly. “I can do that. Tell Terraform what database we need, tell Chef how to configure it.”

“Exactly. Tom, you’re on the compute module and the application tier Chef cookbooks. Everything you documented last week about how app servers should be configured—that becomes Chef recipes.”

“So I’m writing down what I normally do manually, just in Chef’s language instead of a runbook,” Tom said.

“Right. Marcus, you’re handling networking, including the VPCs, subnets, firewall rules, and load balancers. All the network configuration that’s currently scattered across different systems and tickets? That all becomes Terraform code.”

“And Priya,” Maya continued, “you’re the Chef expert for PeopleSoft-specific configuration. Domain setup, process scheduler configuration, and web server setup. You know PeopleSoft configuration better than anyone. Now you’re teaching Chef how to do it.”

“What about me?” Lisa asked.

“You’re QA and validation,” Maya said. “As each module gets built, you’re testing it. You’re writing automated tests to verify that the infrastructure is configured correctly. And you’re documenting the gotchas. We need documentation about what broke, how we fixed it, and what we learned.”

“Sarah, you’re our technical lead on this,” Maya said. “You’re learning Terraform and Chef at an expert level, and you’re helping everyone else. You’re also setting up the Git repository structure, the code review process, and the CI/CD pipeline for testing infrastructure code.”

“Wait, we’re doing code reviews on infrastructure?” Tom sounded surprised.

“Absolutely,” Maya said. “Infrastructure is code now. We review code. Jake proposes a change to the database module? It goes through a pull request. I review it, or Sarah reviews it, or you review it. We ask questions: ‘Why this parameter?’ ‘What happens if this fails?’ ‘Is this tested?’ Same discipline we’d use for application code.”

“That’s… actually going to catch mistakes,” Tom admitted. “How many times have I made a manual configuration change without a second set of eyes on it?”

“Exactly,” Maya said. “Code review isn’t about distrust. It’s about quality and knowledge sharing. When Jake submits a database module change, I learn about Oracle configuration by reviewing his code. When Tom submits an app tier change, Jake learns about application server setup. We all get smarter.”

She capped the marker. “Questions before we dive into training?”

“Yeah,” Jake said. “What happens when we hit Week 4 and we’re supposed to be building CI/CD pipelines, but we’re still struggling with IaC?”

“Then we adjust,” Maya said honestly. “The twelve-week timeline is aggressive. We’re going to hit roadblocks. But we can’t let perfect be the enemy of good. If at the end of Week 3 we can build an environment in four hours instead of two, that’s still a massive win. If our Chef cookbooks don’t cover every edge case, but they cover 80% of the configuration, that’s progress.”

“We’re not trying to be perfect,” Sarah said. “We’re trying to be better. And we’re trying to prove to Harrison that modernizing PeopleSoft is possible and valuable.”

“Exactly,” Maya said. “The goal isn’t perfection. The goal is demonstrable improvement plus a pathway to keep improving. If we can show Harrison that we’ve cut environment provisioning from 18 days to 4 hours, reduced configuration errors, and eliminated tribal knowledge dependencies, we’ve made the case.”

Tom stood up. “Alright. I’m in. But I reserve the right to complain when my Terraform code doesn’t compile or whatever the right term is.”

“Complaining is encouraged,” Maya said. “Giving up is not. Everyone clear on the plan?”

Nods around the room.

“Good. Training resources are linked in Slack. Sarah’s got office hours 2-4 PM daily if you get stuck. And remember—we’re all learning together. I’ll be going through the same Terraform tutorials you are. There are no stupid questions.”

As the team dispersed to start their training, Jake lingered behind.

“Maya,” he said quietly. “I need you to know something. I’m scared.”

Maya turned. “Scared of what?”

“That I can’t do this,” Jake said. “I’ve been an Oracle DBA for twenty-six years. I know Oracle inside and out. I know every parameter, every wait event, and every performance tuning trick. But Terraform? Chef? Infrastructure as code? I feel like I’m starting over. And I’m not twenty-five anymore. What if I can’t keep up?”

Maya sat down next to him. “Jake, do you remember Week 1? Your disaster recovery test?”

“Yeah.”

“You found three errors in backup scripts that had been running for seven years. Errors no one else would have caught because they don’t understand Oracle the way you do. That expertise doesn’t disappear just because you’re learning new tools.”

“But—”

“Infrastructure as code doesn’t replace your Oracle knowledge,” Maya continued. “It amplifies it. Right now, your expertise lives in your head and in scripts only you understand. After Week 3, your expertise will be codified, version-controlled, and teachable. You’re not starting over. You’re multiplying your impact.”

“What if I slow everyone down?”

“Then we slow down,” Maya said simply. “But I don’t think you will. You know what I think? I think you’re going to struggle for a few days, get frustrated, maybe write some Terraform code that doesn’t work. But then something’s going to click. And by Week 3, you’re going to be teaching the rest of us the right way to architect database infrastructure in code. Because you understand Oracle databases at a level none of us do.”

Jake was quiet for a moment. “You really believe that?”

“I know it,” Maya said. “I wouldn’t have put you on the database module if I didn’t think you could do it. You’re not just learning Terraform, Jake. You’re becoming the person who can bridge traditional Oracle DBA expertise with modern cloud operations. That’s a rare and valuable skill. In five years, every company will want DBAs who can do both. You’re going to be ahead of the curve.”

“Okay,” Jake said, standing up. “I’m going to go start this training. But I’m going to complain a lot.”

“That’s the spirit,” Maya said.

After Jake left, Maya sat alone in the conference room, looking at her twelve-week timeline on the whiteboard. Week 1: Assessment—complete, with green checkmarks next to each deliverable. Week 2-3: Infrastructure as Code—in progress.

Her phone buzzed. An email from Robert Harrison: “Heard you’re moving the team to new tools. Make sure this doesn’t disrupt production operations. Can’t afford incidents during the transformation.”

Maya typed back: “Understood. All IaC development is happening in isolated dev environments. Production untouched until Week 8+ and fully tested.”

She didn’t mention that “not disrupting production” would be the hardest part. They still had to maintain current operations while learning an entirely new operational model. It was like rebuilding an airplane mid-flight.

But that’s what the next ten weeks were going to be: running production on the old model while building the new model in parallel, then executing a clean cutover when the new model was proven.

No pressure.

Maya opened her laptop and navigated to the HashiCorp learning portal. If she was going to ask her team to learn this, she needed to be able to help them when they got stuck.

Two weeks. By the end of Week 3, they’d have an infrastructure that used to take eighteen days, now provisioned in hours.

And her team would have learned that they were capable of more than they thought.

One Terraform module at a time.

Read more

The reality, however, is far more complex. Large ERP modernization efforts frequently exceed budgets, stretch timelines, and generate disruption well beyond initial projections. Even when implementations technically succeed, organizations often struggle to realize the expected benefits. Teams spend years stabilizing, retraining, and reworking processes that once ran smoothly. This gap between promise and outcome marks the beginning of the modernization paradox.

Why ERP Modernization Efforts Fail More Often Than Expected

Most ERP modernization failures are not the result of poor leadership or a lack of effort. Instead, they stem from the fact that ERP systems are deeply embedded in daily organizational operations. Over time, these systems accumulate countless decisions, exceptions, and adaptations—many of which are undocumented and invisible in process diagrams. When leaders misjudge the extent of this embedded complexity, they also misjudge the scale of risk involved. As a result, that risk escalates rapidly once implementation is underway.

Another contributing factor is decision pressure. CIOs face constant signals that modernization is urgent and delay is dangerous. Vendor messaging, peer announcements, and executive expectations can compress evaluation timelines and discourage dissent. In those environments, skepticism is often interpreted as resistance instead of prudence. The resulting decisions may look decisive, but they are frequently under-informed.

Failure rarely presents itself as a single dramatic event. Instead, it appears gradually through prolonged stabilization periods, missed delivery goals, and growing frustration across IT and business teams. Over time, leaders realize that the organization is no more agile than before. In some cases, it is less adaptable due to new constraints that were not fully visible at the start.

Subscribe now

Read more

The word “legacy” has become a weapon in enterprise software sales. Consultants wield it to create urgency. Vendors use it to manufacture obsolescence. And somewhere in the middle, CIOs are being pressured to abandon functional, mission-critical systems based on fear rather than fact.

But here’s what nobody wants to tell you: the distinction between “legacy” and “modern” has almost nothing to do with when the software was written.

It has everything to do with how it’s architected, deployed, and operated today.

Subscribe now

What “Legacy” Actually Means

Let’s be precise about terminology. A system is legacy when it exhibits these characteristics:

It can’t integrate. Modern systems expose APIs and connect seamlessly with other platforms. Legacy systems are data islands that require expensive middleware or manual processes to exchange information.

It can’t scale. Modern systems leverage cloud infrastructure to grow with demand. Legacy systems hit capacity walls that require months of procurement and provisioning to address.

It can’t evolve. Modern systems support rapid iteration, automated testing, and frequent releases. Legacy systems require change freezes, maintenance windows measured in hours, and risk tolerance that slows innovation to a crawl.

It can’t be maintained. Modern systems have active communities, current documentation, and available talent. Legacy systems depend on tribal knowledge and vendors who charge premium rates for basic support.

Notice what’s missing from this list? The year the codebase was created.

Read more

🎉 Edition 25 – A Milestone Worth Celebrating

This week marks a small but meaningful milestone: Edition 25 of The Modern ERP Digest.

I started this Digest last year with a simple goal: cut through the noise. There was (and still is) a flood of information across PeopleSoft, ERP, cloud platforms, AI, and infrastructure. Valuable insights were scattered across blogs, press releases, analyst reports, and community posts, but were rarely brought together in one place.

The Digest exists to do exactly that: consolidate what matters, add practitioner context, and help ERP leaders make sense of a rapidly shifting landscape. Reaching 25 editions tells me there’s real value in that approach, and I appreciate everyone who’s been reading, sharing, and challenging ideas along the way.

Now, on to this week’s signals.

☕ This Week’s Focus

Edition 25 reflects a familiar but intensifying theme for 2026: AI ambition colliding with operational reality.

Oracle continues to place big bets on AI-driven platforms as markets scrutinize leadership changes and long-term returns. At the same time, ERP vendors are reshaping the competitive field, and PeopleSoft practitioners are doubling down on performance, governance, and day-to-day operational excellence.

This is what modern ERP leadership looks like right now. It includes balancing strategy, execution, and risk.

⚙️ Oracle, AI & Platform Strategy

🔗 Retailers Mitigate Risk with Oracle’s AI-Driven Supply Chain Collaboration
https://www.prnewswire.com/news-releases/retailers-help-mitigate-risk-with-oracles-ai-driven-supply-chain-collaboration-302657847.html
Oracle highlights how retailers are using AI-driven collaboration tools to improve visibility and resilience across supply chains. The key takeaway isn’t the AI buzz, it’s the focus on risk mitigation and coordination, two areas where ERP still delivers real value.

🔗 New Adapters and Connectivity Enhancements in Oracle Integration 26.01
https://blogs.oracle.com/integration/new-adapters-and-connectivity-enhancements-in-oracle-integration-26-01
Oracle Integration 26.01 introduces expanded adapters and connectivity improvements. For hybrid ERP environments, these enhancements continue the push toward cleaner, more maintainable integration patterns rather than brittle point-to-point solutions.

🔗 Oracle Announces Board Departures (CNBC)
https://www.cnbc.com/2026/01/09/oracle-announces-board-departures-george-conrades-and-naomi-seligman-.html
Oracle announced upcoming board departures, a reminder that leadership evolution often accompanies strategic inflection points. Governance matters, especially when organizations are making multi-decade bets on AI infrastructure.

🔗 Can Oracle Stock Rally in 2026? (Forbes)
https://www.forbes.com/sites/greatspeculations/2026/01/05/can-oracle-stock-rally-possible-and-here-is-how/
Forbes explores scenarios where Oracle could see renewed stock momentum—driven by cloud revenue growth, AI services, and disciplined execution. It’s a useful lens for separating fundamentals from speculation.

🔗 Inside Oracle’s $50B AI Bet (PredictStreet)
https://markets.financialcontent.com/stocks/article/predictstreet-2026-1-7-the-ai-goliath-inside-oracles-50-billion-bet-on-the-future-of-computing
A deeper look at the scale of Oracle’s AI investments and what success would need to look like to justify them. The article reinforces a familiar truth: big bets only pay off when adoption follows.

📊 ERP Market & Industry Shifts

🔗 Ellucian Acquires Anthology’s SIS and ERP Business (Campus Technology)
https://campustechnology.com/articles/2026/01/05/ellucian-officially-acquires-anthologys-sis-and-erp-business.aspx
Ellucian’s acquisition reshapes the higher-ed ERP market yet again. Consolidation continues, and institutions are being forced to reassess vendor strategy, roadmap confidence, and long-term platform viability.

🔗 Five ERP Strategic Implications for Operations Leaders in 2026 (ERP Today)
https://erp.today/five-erp-strategic-implications-for-operations-leaders-in-2026/
ERP Today outlines five trends shaping operational leadership this year, including automation and AI governance, as well as platform consolidation. The throughline is clear: operations leaders are now platform leaders.

👩‍💻 PeopleSoft Community & Practice

🔗 Upcoming Webinar: Troubleshooting PeopleSoft Performance
https://gideontaylor.com/event/troubleshooting-peoplesoft-performance-five-costly-mistakes-and-the-mechanic-mindset-that-helps-you-fix-them/
This upcoming webinar focuses on common PeopleSoft performance mistakes and a practical “mechanic mindset” for diagnosing issues. A solid opportunity for admins and DBAs looking to sharpen real-world troubleshooting skills.

🔗 PeopleSoft Change Assistant – A Practical Walkthrough
https://curiousdba.netlify.app/post/peoplesoftchangeassistant/
A hands-on look at PeopleSoft Change Assistant, including how it works, where it helps, and how to avoid common pitfalls. This kind of grounded tooling knowledge continues to separate smooth upgrades from painful ones.

🔗 Managing Ad Hoc PSQueries in PeopleSoft
https://blog.psftdba.com/2026/01/managing-ad-hoc-psqueries-in-peoplesoft.html
A pragmatic guide to controlling and organizing ad hoc PSQueries. Governance here isn’t about restriction. But rather it’s about protecting performance and maintaining trust in shared reporting environments.

💬 Aaron’s Take

Reaching 25 editions reinforces something I’ve seen repeatedly in ERP work: consistency matters more than noise.

Oracle is making bold AI investments. ERP vendors are consolidating. Markets are optimistic one week and skeptical the next. None of that changes the day-to-day reality for ERP teams who are responsible for keeping systems fast, secure, and useful.

The strongest organizations right now aren’t chasing every headline. They’re improving integration discipline, understanding performance bottlenecks, governing reporting responsibly, and making thoughtful platform decisions.

That’s the work this Digest has always tried to highlight—and it’s the work that will define successful ERP teams in 2026.

Thanks for being part of the first 25 editions. Onward.

🌐 Join the Community

If you’re new here or joining us as we move deeper into 2026, you can subscribe at PeopleSoftCloud.com to receive:

✅ Weekly ERP, PeopleSoft, and cloud insights
✅ Practitioner-focused context
✅ Platform and operations strategy
✅ Signals worth paying attention to

Here’s to the next 25.

One of the most common performance mistakes in PeopleSoft environments is assuming that increasing Process Scheduler concurrency increases throughput.

Subscribe now

It doesn’t. It usually does the opposite.

Concurrency controls how many processes can run at once, not how many should. When teams raise concurrency to “speed things up,” they often create hidden contention across CPU, memory, database sessions, and I/O. The result looks like higher utilization but feels like slower jobs, longer queues, and unpredictable runtimes.

The problem is that Process Scheduler doesn’t understand workload priority. A critical financial close job and a low-value reporting extract compete the same way unless you explicitly separate them. When concurrency is too high, expensive processes overlap, amplify resource pressure, and slow each other down.

Another overlooked issue is peak stacking. Many environments schedule dozens of jobs to start simultaneously. Even with adequate hardware, this creates artificial load spikes that appear to be capacity problems but are actually scheduling issues.

A better approach is controlled parallelism:

• Lower global concurrency

• Stagger start times

• Separate schedulers by workload type

• Align concurrency with actual database and OS limits

When teams do this, they often see faster completion times without adding resources. The system becomes more predictable, easier to tune, and less fragile during peak windows.

If your Process Scheduler feels “busy but slow,” this is one of the first places to look.

Small change. Real impact.

The emergency team meeting on Friday afternoon had gone about as well as Maya expected, which is to say, poorly.

She’d opened with the truth: the CIO wanted to migrate to SaaS, the decision was effectively made, and she’d bought them twelve weeks to prove there was a better path. Twelve weeks to modernize or start updating resumes.

Subscribe now

Jake Morrison, her senior DBA with seventeen years at Riverside, had gone pale. “They want to replace Oracle with what? Workday’s solution? That’s not even a real database.”

Tom Patterson, her application server admin, had laughed. “Twelve weeks? Maya, we can’t even complete a PeopleTools upgrade in twelve weeks. You want us to rebuild our entire operational model?”

Sarah Chen, the junior developer who’d joined the team eight months ago, had been the only one who looked intrigued rather than terrified. “What exactly do we need to prove?”

“That we can operate PeopleSoft like a modern cloud-native platform,” Maya had said. “Infrastructure-as-code. Automated deployments. Real observability. The works.”

“We don’t know how to do any of that,” Tom had said flatly.

“Then we learn,” Maya had replied. “Starting Monday.”

The meeting had ended with grudging acceptance, or at least, no one had quit on the spot. Maya considered that a win.

Now it was Monday morning, 7:00 AM, and Maya stood in Conference Room B with a fresh pot of coffee and a whiteboard that read: “Week 1: Assessment - Know Thyself.”

Her team filtered in: Jake with his Oracle certification mug, Tom with a notebook he’d been using since 2009, Sarah with her laptop covered in Python stickers that suddenly seemed prescient, and the rest of the team, including Lisa (Portal admin), Marcus (Integration Broker specialist), and Priya (Application Designer developer).

“Good morning,” Maya said. “Welcome to Week 1 of the rest of your careers.”

“Too early for inspirational speeches,” Jake muttered into his coffee.

“Fair enough. Here’s the non-inspirational version: we’re going to spend today conducting the most honest assessment of our capabilities that this team has ever done. No ego. No defensiveness. No, ‘but we’ve always done it this way.’ We’re going to document every manual process, every piece of tribal knowledge, every technical debt bomb sitting in our infrastructure. And then we’re going to prioritize what to fix first.”

“This sounds terrible,” Tom said.

“It is,” Maya agreed. “But you know what’s more terrible? Discovering in Week 11 that we missed something critical because we weren’t honest with ourselves in Week 1.”

She divided the whiteboard into five columns: Infrastructure, Deployment, Operations, Skills, and Quick Wins.

“Let’s start with infrastructure,” Maya said. “Tom, walk us through how we currently provision a new PeopleSoft environment.”

Tom flipped open his ancient notebook. “Okay, so first I submit a ticket to the infrastructure team for VMs.”

“Stop,” Maya interrupted. “How long does that take?”

“Depends. If they’re busy, maybe a week?”

“Keep going.”

“Once we get the VMs, I install the OS manually. Then I need Jake to install Oracle.”

“Which takes me two days,” Jake interjected. “Database install, configuration, applying patches, creating tablespaces, setting up backup jobs.”

“All manual?” Maya asked.

“Well, I have a script for some of it,” Jake said defensively. “But yeah, mostly manual. Each environment has its own quirks.”

“What quirks?”

Jake shifted uncomfortably. “You know. Different storage layouts, different memory configurations, different networking setups. The dev database is configured differently from QA, which is different from production.”

“Why?”

“Because… they were built at different times by different people?”

Maya wrote on the whiteboard under Infrastructure: “Environment provisioning: 2-3 weeks, completely manual, no standardization, configuration drift.”

“That seems harsh,” Tom said.

“Is it inaccurate?”

Tom said nothing.

“Okay,” Maya continued. “After Jake installs Oracle, then what?”

“Then I install the application server, process scheduler, web server, and PIA,” Tom said. “That’s another three days if nothing goes wrong.”

“How often does something go wrong?”

“Every single time,” Tom admitted. “Wrong library path, missing dependencies, PeopleTools patches that need to be applied in a specific order that isn’t documented anywhere except in my head.”

Maya added: “App tier installation: 3+ days, failure-prone, zero documentation, tribal knowledge-dependent.”

“When you put it like that, we sound incompetent,” Lisa said quietly.

“You’re not incompetent,” Maya said. “You’re operating in a model that was designed twenty years ago. But that model doesn’t scale, doesn’t automate, and doesn’t survive if Tom gets hit by a bus.”

“Thanks for that image,” Tom said.

“Let’s talk about deployments,” Maya continued, moving to the second column. “Priya, how do we currently move customizations from development to production?”

Priya, who’d been silent until now, spoke carefully. “I make the changes in Application Designer in dev. Test them. Then I create a project. Export the project to a file. Email the file to myself. Copy it to the QA server. Import it. Test again. Then repeat for production.”

“How long does that take?”

“For a small change? Maybe two hours. For a larger project with dependencies? I’ve had deployments take an entire day.”

“What happens if something breaks in production?”

“I… manually roll it back?”

“Do you have automated tests?”

Priya looked at Maya like she’d suggested summoning demons. “Automated tests? For PeopleCode?”

Maya wrote: “Deployment process: 100% manual, no CI/CD, no automated testing, high risk, slow rollback.”

“Operations,” Maya said, moving to the third column. “Marcus, when was the last time we had a production incident?”

Marcus, who managed their Integration Broker and application messaging, checked his phone. “Thursday. IB went down for forty minutes.”

“How did you know it was down?”

“A user called and said their integration wasn’t working.”

“So our monitoring is… end users?”

“We have Tuxedo monitoring,” Marcus said defensively. “It just doesn’t alert properly. And the logs are spread across seventeen different servers. So when something breaks, I SSH into each server, grep through logs, and try to correlate timestamps.”

“How long does incident resolution typically take?”

“If I can find the problem quickly? An hour. But if it’s a weird issue? I’ve spent eight hours troubleshooting before.”

Maya added: “Observability: User-reported incidents, distributed logs with no aggregation, no tracing, slow mean-time-to-resolution.”

The whiteboard was starting to look like an indictment.

“Backups,” Maya said. “Jake, how do we back up the database?”

“RMAN scripts that run nightly,” Jake said. “They’ve been running for… six years? Seven?”

“Have you ever tested a restore?”

Silence.

“Jake.”

“I tested it when I first set it up,” Jake said. “In 2018.”

“So we’re trusting seven-year-old backup scripts that haven’t been validated in seven years to protect our entire university’s enterprise data?”

“When you say it like that...”

“How long would it take to restore from backup if we lost production right now?”

Jake did some mental math. “Database restore from RMAN? Maybe six hours. Then we’d need to rebuild the application tier, reconfigure everything… twelve hours? Eighteen if we hit problems?”

Maya wrote: “Disaster Recovery: 12-18 hour RTO, untested backup procedures, manual recovery process.”

The room had gone very quiet.

“Skills assessment,” Maya said, moving to the fourth column. This was going to hurt. “Show of hands: who has used Git for version control?”

Sarah’s hand went up. No one else’s.

“Infrastructure as code? Terraform, Chef, anything?”

No hands.

“CI/CD pipelines? Jenkins, GitLab CI, GitHub Actions?”

Sarah raised her hand tentatively. “I used GitHub Actions in a personal project once.”

“Container orchestration? Kubernetes, Docker?”

No hands.

“Cloud platforms? GCP, AWS, Azure console?”

No hands.

“Anyone here written Python?”

Sarah’s hand. That was it.

Maya wrote: “Skills: Traditional admin skillset, no DevOps experience, no cloud experience, no automation frameworks, no modern tooling.”

She capped the marker and turned to face her team. Six faces stared back at her with varying expressions of defensive discomfort.

“Okay,” Maya said. “Here’s what I see. We have a team of smart, dedicated people running a critical enterprise platform using operational practices from 2005. We have no automation, no standardization, no observability, no disaster recovery confidence, and no modern technical skills. If we tried to document our processes, half of them exist only in Tom’s and Jake’s heads. If we lost a key team member, we’d be in crisis. And we’re spending most of our time on manual toil instead of improvement.”

“That’s a pretty bleak assessment,” Jake said.

“It’s an honest assessment,” Maya replied. “And here’s the thing, this isn’t unique to us. I’d bet 70% of PeopleSoft shops operate exactly like this. It works, sort of, until it doesn’t. But it’s expensive, risky, and slow. And it’s why consultants can walk in here and say ‘your PeopleSoft operation costs $4.2 million a year’ and make it stick.”

“So what do we do?” Lisa asked.

Maya moved to the fifth column: Quick Wins.

“We prove we can change,” Maya said. “Today, we pick one thing, one small thing, that we can automate or improve in the next week. Something that will give us a victory, build confidence, and demonstrate that this team can evolve.”

“Like what?” Tom asked.

“You tell me,” Maya said. “What’s the most annoying manual process you deal with every day? The thing that makes you think ‘there has to be a better way to do this’?”

Sarah spoke up first. “The quarterly critical patch DPK application process. Every time Oracle releases a patch bundle, we spend three days downloading files, reading the readme, manually applying the patch, checking the logs, and fixing errors.”

“And we have to do it for every environment and every server,” Priya added. “So a single critical patch bundle becomes two weeks of work across dev, QA, and production.”

“Can we automate that?” Maya asked.

“I don’t know,” Sarah said. “I’ve never tried.”

“Then that’s your Week 1 project,” Maya said. “You and Priya. Write a script in Python, Bash, or whatever works best that automates the critical patch download and application process. Document it. Test it in dev. If it works, we’ve just saved ourselves two weeks every quarter.”

Sarah and Priya exchanged glances. Sarah nodded. “Okay. We can try.”

“Jake,” Maya said. “You mentioned your RMAN backups haven’t been tested in seven years. This week, your job is to perform a complete restore test in a non-production environment. Document the actual restore time, identify any problems, and update the runbooks. Make disaster recovery a known quantity instead of a hope.”

Jake grimaced. “That’s going to be tedious.”

“Yes,” Maya agreed. “But when we’re presenting to the CIO in Week 12, and he asks about business continuity, I want to tell him we have a tested, documented DR process with a validated RTO. Can you do that?”

“Yeah,” Jake said reluctantly. “I can do that.”

“Marcus,” Maya said. “Observability. I want you to spend this week researching log aggregation solutions. We need to get all our PeopleSoft logs, including application server, web server, process scheduler, and integration broker, flowing into a single place where we can search them. Start with open-source options. Elasticsearch, OpenSearch, whatever. See what versions are compatible with our PeopleTools versions, and then document what it would take to implement.”

“That sounds complicated,” Marcus said.

“It is,” Maya said. “Which is why you’re starting with research, not implementation. By Friday, I want a one-page proposal that says ‘here’s how we could aggregate our logs, here’s what it would cost, here’s what value we’d get.’ Can you do that?”

Marcus considered. “Yeah. I can do that.”

“Tom,” Maya said. “You’re going to start documenting. Pick one environment, let’s say dev, and document every single configuration setting, every directory path, every environment variable, every tuning parameter. Everything that lives in your head and your notebook needs to live in a wiki or a Git repo by the end of the week.”

“All of it?” Tom looked pained.

“The dev environment,” Maya clarified. “Think of it as the template for the infrastructure-as-code we’re going to build later. But we can’t automate what we can’t describe.”

“This is going to be incredibly boring,” Tom said.

“Welcome to Week 1,” Maya replied.

She turned to Lisa. “Portal admin is cleaner than most of this, but I want you working with Sarah and Priya on the patching automation. Your job is to test it, break it, and make sure it actually works. Be the QA.”

“I can do that,” Lisa said.

Maya stepped back from the whiteboard. “Here’s what success looks like at the end of Week 1: Sarah and Priya have a working patch automation script. Jake has a tested DR runbook with real numbers. Marcus has a log aggregation proposal. Tom has documentation for one complete environment. Lisa has validated that the patch script actually works.”

“That’s… a lot for one week,” Tom said.

“It’s a fraction of what we need to accomplish in twelve weeks,” Maya said. “But it’s a start. And more importantly, it’s how we prove to ourselves that we can do this. Right now, you’re all thinking this is impossible. By Friday, you’ll have evidence that it’s possible.”

“And if we fail?” Jake asked.

“Then we learn why we failed and try again,” Maya said. “But here’s the thing, we’re not trying to be perfect. We’re trying to be better. Any improvement is a win.”

She grabbed the eraser and cleared a space on the whiteboard. “Let me show you where we’re trying to get to.”

The Modernization Maturity Model

Read more

Chapter 2 of the Twelve Week Challenge focuses on assessment, and that word alone tends to make eyes glaze over. It sounds slow. It sounds bureaucratic. It sounds like documentation nobody will read. In practice, though, this step is where most failed PeopleSoft initiatives could have been saved.

Subscribe now

Because here’s the uncomfortable truth: most organizations don’t have a shared understanding of how their PeopleSoft environment really works.

Most PeopleSoft Admins know fragments of the story. DBAs know a bit about their slice. Developers know what breaks when it breaks, and sometimes they know how to fix it. Leadership understands the pain, but not the mechanics. When those gaps exist, every automation effort, cloud move, or tooling decision stacks assumptions on top of uncertainty.

That’s not modernization. That’s gambling.

In real-world PeopleSoft environments, assessment isn’t about creating perfect diagrams or rebuilding the CMDB from scratch. It’s about answering a few critical questions honestly. What runs where? What runs when? What breaks under load? What processes are business-critical versus “we’ve always done it this way”?

Most teams think they know these answers. I wrote the process and concepts described in Chapter 2 because many don’t.

A common mistake at this stage is jumping straight to tooling. Teams want Terraform, containers, pipelines, dashboards—anything that feels like progress. The problem is that tools amplify reality. If the underlying understanding is fuzzy, automation makes the mess faster and harder to unwind.

In practice, strong PeopleSoft teams use assessment to establish a baseline of truth. Not theoretical architecture. Not vendor diagrams. Actual runtime behavior. That baseline becomes the reference point for every decision that follows, from process scheduler strategy to integration modernization to cloud placement.

Another overlooked outcome of Chapter 2 is alignment. When everyone agrees on how the system behaves today, conversations change. “This feels slow” turns into “this job overlaps peak load.” “The cloud will fix it” turns into “this workload needs to be decoupled first.” The tone shifts from opinion to evidence.

That shift matters more than most leaders realize.

This is also where many SaaS migration narratives quietly fall apart. When organizations finally document their PeopleSoft reality, they often discover the system isn’t as brittle or outdated as assumed. The issues usually live in operational patterns, not the platform itself.

That doesn’t mean PeopleSoft is the answer forever. It means decisions are grounded in facts rather than frustration.

Chapter 2 of the Twelve Week Challenge doesn’t promise transformation in a week. What it delivers is clarity, and clarity is what allows real momentum in the weeks that follow. Without it, every later “win” rests on shaky ground.

If you’ve ever felt like your PeopleSoft environment was being judged without being understood, this step will feel uncomfortably familiar. And that’s precisely why it exists.

Thursday, inside Chapter 2 of the Twelve Week Challenge, we go deeper into how teams are structuring this assessment without slowing delivery, or burning out the people who actually run the system.

Clarity first. Everything else depends on it.

This isn’t your typical “tips and tricks” series. I’m not going to wow you with my technical prowess or give you some magic pill to make everything better. Over the next 52 weeks, The PeopleSoft Executive Playbook will challenge conventional wisdom about ERP strategy, explore what modernization actually means in practice, and provide actionable frameworks for leaders who refuse to accept the false choice between innovation and stability.

Subscribe now

Read more

🎉 Welcome to 2026

Happy New Year—and welcome to Edition 24, the first Modern ERP Digest of 2026. If you’re new here, this is the perfect time to subscribe to www.PeopleSoftCloud.com. Each week, I curate the most relevant ERP, Oracle, and PeopleSoft stories, add context that matters to practitioners, and connect strategy to execution.

Subscribe now

2026 starts with renewed momentum: market sentiment is shifting, Oracle is doubling down on infrastructure and platforms, and PeopleSoft teams are pushing modular architectures, better observability, and cleaner delivery models. Let’s get into it.

⚙️ Oracle, Market Signals & Infrastructure

🔗 Beaten-Down Tech Giant Could Roar Back (AOL)
https://www.aol.com/articles/beaten-down-tech-giant-roar-193000624.html
A market reset may be setting the stage for a rebound. The article points to fundamentals, including cash flow, infrastructure investments, and enterprise positioning, as reasons Oracle could regain momentum. A useful lens as we move from hype to execution in 2026.

🔗 Launch Exadata Database Service Faster Using OCI Landing Zones (Oracle Database Blog)
https://blogs.oracle.com/database/launch-exadata-database-service-faster-using-oci-landing-zones
Oracle outlines how standardized OCI Landing Zones accelerate Exadata Database Service deployments with built-in security, networking, and governance. For ERP teams, this is about repeatability and speed without sacrificing controls.

🔗 Quarterly Updates Made Easy (Oracle Fusion Insider)
https://blogs.oracle.com/fusioninsider/quarterly-updates-made-easy
A practical guide to managing quarterly updates with less disruption. The emphasis is on planning, automation, and communication.

📊 ERP Strategy, Architecture & Delivery

🔗 From Idea Labs to Implementation Access (JSMPros)
https://blog.jsmpros.com/2025/12/from-idea-labs-to-implementation-access.html
This piece bridges experimentation and production, showing how teams can move ideas into controlled, supported delivery paths. It’s a reminder that innovation needs a runway and guardrails to scale.

🔗 From Menus to Meaning: How OpenSearch Modernizes PeopleSoft (LinkedIn)
https://www.linkedin.com/pulse/from-menus-meaning-how-opensearch-modernizes-selvakumar-ramasamy-4zm5c
A clear explanation of how OpenSearch shifts PeopleSoft from static navigation to insight-driven experiences. Observability, search, and analytics become first-class capabilities, not bolt-ons.

🔗 Why Modular PeopleSoft Architectures Matter (PeopleSoft Insider)

The PeopleSoft Insider

Why Modular PeopleSoft Architectures Are Winning in 2026 + How To Guard Your Org From Taking the SaaS Cloud Pill

Happy New Year! I wanted to start out the new year with this topic as it remains on the minds of so many PeopleSoft Pros. The pressure to abandon the core has never been higher, but the logic for staying has never been clearer. We’ve reached a point where “migration” is often used as a euphemism for “unnecessary risk…

Read more

3 months ago · 1 like · Derek Tomei

A strong case for modularization: decouple where possible, standardize interfaces, and evolve components independently. This is foundational thinking for hybrid ERP and long-term sustainability.

👩‍💻 PeopleSoft Community & Practice

🔗 PeopleSoft Now! – 2026 Product Roadmap (Video)

A forward-looking overview of the PeopleSoft 2026 product roadmap. The session focuses on continued investment across HCM, FSCM, Campus Solutions, and tools. Emphasizing UX refinement, analytics, and platform stability. It’s a solid orientation for planning the year ahead.

🔗 The 12 Week Challenge (PeopleSoftCloud)
https://www.peoplesoftcloud.com/p/the-12-week-challenge?r=z6fpj
A fictional story outlining a structured way to start 2026 with intent. This includes short cycles, clear outcomes, and steady progress. This challenge aligns perfectly with how successful PeopleSoft teams modernize: focused, measurable, and disciplined.

💬 Aaron’s Take

The tone of 2026 already feels different. Less noise. More intent.

Market narratives are settling, platforms are maturing, and ERP teams are shifting attention from chasing trends to building durable capability. Oracle’s infrastructure focus, the push for modular PeopleSoft architectures, and the growing role of OpenSearch all point to the same direction: clarity through structure.

Subscribe now

If 2025 was about sorting signal from hype, 2026 is about execution. This is the year to standardize, modularize, automate, and measure. Not because it’s flashy, but because it works.

And if you’re deciding where to invest your time this year, subscribing to PeopleSoftCloud.com is a good place to start. The work ahead is practical, and the community here is focused on getting it done.

🌐 Join the Community

Subscribe at www.PeopleSoftCloud.com to receive:

✅ Weekly ERP and PeopleSoft insights
✅ Practical modernization frameworks
✅ Cloud, database, and observability strategy
✅ Leadership perspective for enterprise IT

Welcome to 2026.

In her eight years at Riverside University, she’d learned that meetings with innocuous titles were the dangerous ones. The meetings that actually said what they were about, like “Q3 Budget Review” or “Incident Post-Mortem,” those were fine. But “Strategic Planning Discussion” with the CIO, CFO, and VP of Business Operations? That was the academic IT equivalent of “we need to talk.”

Subscribe now

She clutched her coffee like a talisman and waited.

At 8:00 AM precisely, the CIO’s assistant ushered her into the corner office where Robert Harrison, Riverside’s CIO for the past three years, sat flanked by CFO Patricia Winters and VP of Business Operations James Chen (no relation, though Maya had stopped clarifying this years ago).

“Maya, thanks for coming,” Harrison said, gesturing to a chair across from the executive tribunal. “We’ll get right to it. We’ve been conducting a comprehensive review of our enterprise application portfolio, and we’ve made a strategic decision regarding our ERP platform.”

Maya’s coffee suddenly tasted like ash.

Harrison slid a glossy presentation deck across the table. The cover featured a sunset image, subtle, with the title “Riverside University: Cloud ERP Transformation Initiative.”

“We’re migrating to SaaS,” Harrison continued. “Workday for Finance and HR, Salesforce for CRM, and we’re evaluating Oracle Cloud and Anthology for the student system. The board wants us to be cloud-native within eighteen months.”

Maya flipped through the deck. Slide 3: “Legacy System Challenges.” Slide 5: “Total Cost of Ownership Comparison.” Slide 8: “Implementation Timeline.” Slide 12: “Change Management Strategy.”

It was a masterpiece of selective data presentation. She recognized the consulting firm’s watermark in the footer; McKinsey had been on campus for three months, apparently building the case for burning down everything her team had spent a decade maintaining.

“This TCO analysis,” Maya said carefully, tapping Slide 5. “It shows PeopleSoft costing us $4.2 million annually versus $2.8 million for the SaaS solutions.”

“Correct,” Patricia Winters said. “Plus, the SaaS model eliminates our infrastructure overhead, reduces our admin headcount requirements, and provides automatic updates. No more PeopleTools upgrades eating six months of your team’s time.”

Maya took a breath. She’d been an IT manager long enough to know when executives had already made up their minds. But she’d also been a PeopleSoft administrator long enough to spot a flawed cost model from across a conference table.

“Can I ask about the methodology?” Maya said. “How did the consultants calculate our current PeopleSoft costs?”

Harrison glanced at Winters, who pulled up a spreadsheet on her tablet. “Hardware and infrastructure, licensing, support contracts, admin salaries, upgrade projects, and integration maintenance. All documented in the appendix.”

“And the SaaS costs?”

“Subscription fees based on user count, implementation services, change management, and training,” Winters recited. “Standard pricing from the vendors.”

Maya nodded slowly. “What about data migration costs for the SaaS implementation?”

“Included in implementation services,” Winters said.

“Customization recreation costs? We have 847 custom PeopleCode programs, 203 custom pages, and 156 integration brokers. How much does it cost to rebuild that functionality in Workday and Salesforce?”

A pause.

“The vendors assured us their out-of-the-box functionality covers 80% of requirements,” James Chen offered. “We’ll streamline the rest. Too much customization is part of the problem.”

Maya felt her jaw tighten. “Those customizations exist because our business processes exist. Student financial aid packaging, faculty load balancing, research grant accounting; these aren’t vanity features. They’re how we operate.”

“Which is why we need change management,” Harrison said. “This is an opportunity to modernize our business processes, not just our technology.”

Translation: we’re going to force-fit the university into vendor-defined processes.

Maya looked at the timeline on Slide 8. Eighteen months to replace three PeopleSoft pillars that had been configured, customized, and integrated over fifteen years. She’d seen this movie before at other institutions. It never ended well.

“Robert,” Maya said, using his first name deliberately. “I need to be direct with you. This analysis is fundamentally flawed.”

The room temperature dropped several degrees.

“Flawed how?” Harrison’s voice carried an edge.

Maya stood and walked to the whiteboard. “May I?”

Harrison gestured permission.

She drew two columns: “PeopleSoft Costs” and “SaaS Costs.”

“The consultants counted everything for PeopleSoft—every infrastructure cost, every admin salary, every upgrade hour. That’s fair. But for SaaS, they only counted subscription and implementation. Let me show you what they missed.”

She began writing under the SaaS column:

Migration Costs (Year 0-2):

• Data migration and validation: $800K-1.2M

• Customization gap analysis and recreation: $1.5M-2.5M

• Integration rebuilding (47 systems): $600K-900K

• Business process reengineering: $400K-700K

• Organizational change management: $300K-500K

• Dual-run period (6-12 months): $250K-400K

Hidden Ongoing Costs:

• Premium support tier (required for higher ed): +$180K/year

• Integration platform (Workato/Boomi): $120K/year

• Lost productivity during transition: $500K-800K (one-time)

• Institutional knowledge loss: unquantified

• Re-training existing staff: $200K

• Consultant dependency (first 3 years): $400K/year

• Subscription inflation (historically 7-12% annual): compounding

“That’s conservative,” Maya said. “And I haven’t counted the opportunity cost of your entire IT department being consumed by implementation for two years while other initiatives stall.”

Patricia Winters was taking notes. James Chen looked uncomfortable. Harrison’s expression was unreadable.

“Now let me show you what modernized PeopleSoft costs,” Maya continued.

She drew a third column: “PeopleSoft Modernized.”

One-Time Modernization Investment:

• Cloud infrastructure migration (GCP/AWS): $200K

• Infrastructure-as-code implementation: $80K

• CI/CD pipeline development: $60K

• Observability platform: $40K

• Team upskilling (training/certifications): $50K

• Automation framework: $70K

New Steady-State Costs:

• Cloud infrastructure: $480K/year (vs $720K on-prem)

• Reduced admin overhead (automation): -$200K/year

• Managed database services: $180K/year

• Modern observability tools: $45K/year

• Remaining support/licensing: $650K/year (existing)

“Total modernized cost: approximately $1.2 million annually by year two,” Maya said. “That’s 57% less than the consultants’ SaaS projection, and 71% less than they claim we’re spending now.”

She capped the marker. “And we keep our institutional knowledge, our customizations, our integrations, and our team. Plus we’d be done in months, not years.”

Harrison leaned back. “That’s quite a claim, Maya. You’re telling me we can cut our PeopleSoft costs by 71% in a few months?”

“No,” Maya said. “I’m telling you the consultants inflated our current costs by counting every possible expense, then deflated the SaaS costs by ignoring migration reality. Real PeopleSoft modernization versus real SaaS migration? We win on cost, risk, and timeline.”

“The board wants cloud-native,” Winters said. “PeopleSoft isn’t cloud-native.”

“PeopleSoft on Google Cloud Platform with Kubernetes orchestration, infrastructure-as-code, automated scaling, and cloud-native observability isn’t cloud-native?” Maya countered. “We’re not talking about lifting and shifting our data center to AWS. We’re talking about re-architecting PeopleSoft using modern DevOps practices. The application platform is irrelevant if the operational model is modern.”

Harrison studied her. “You really believe you can do this?”

“I know we can,” Maya said. “But I need time to prove it.”

“Eighteen months?” Harrison asked.

“Twelve weeks.”

The room went silent.

“Twelve weeks?” James Chen said. “To modernize an entire ERP platform?”

“To prove the concept,” Maya clarified. “Twelve weeks to migrate one environment to cloud infrastructure, implement infrastructure-as-code, build CI/CD pipelines, establish modern observability, and demonstrate the cost model. Twelve weeks to show you that PeopleSoft modernization is faster, cheaper, and lower risk than SaaS migration.”

Harrison exchanged glances with Winters and Chen.

“And if you can’t prove it in twelve weeks?” Harrison asked.

“Then we proceed with your SaaS plan,” Maya said. “No resistance, no sabotage. I’ll personally lead the transition and help you find homes for my team.”

“And if you do prove it?”

“Then we commit to full PeopleSoft modernization instead of migration. We make it the strategic direction, not a stopgap. And we fund my team’s transformation properly.”

Harrison picked up the McKinsey deck and dropped it in his desk drawer. “You understand what you’re promising? In twelve weeks, I need to present to the board. I need concrete evidence, including cost numbers, performance metrics, automation demonstrations, and the works. Not theory. Proof.”

“I understand.”

“And your team? Are they on board with this? You’re asking traditional PeopleSoft admins to become DevOps engineers in three months.”

Maya thought of Jake, her senior DBA who still wrote Oracle PL/SQL by hand. Of Tom, her application server admin, who had seventeen years of tribal knowledge and zero documentation. Of Sarah, her junior developer, who was brilliant but had never touched Git.

“They’ll rise to it,” Maya said, with more confidence than she felt. “Or we’ll find out who belongs in a modern IT organization.”

Harrison stood and extended his hand. “Twelve weeks, Maya. Starting Monday. I want weekly status reports and a final presentation in week twelve. Make this count.”

Maya shook his hand, feeling the weight of what she’d just committed to. Twelve weeks to transform her team, her platform, and her career.

She walked back to her office in the IT building, her mind already racing through task lists and architecture diagrams. She needed to call a team meeting. She needed to assess their current state honestly, with no illusions or excuses. She needed to figure out how to teach a team of administrators who’d spent careers clicking through PIA how to write Python and Terraform.

But first, she needed to build the real TCO model. The one she’d sketched on Harrison’s whiteboard was directionally correct but approximate. If she was going to stake her credibility on these numbers, she needed them to be bulletproof.

Maya opened her laptop and created a new spreadsheet: “PeopleSoft vs SaaS: True Total Cost of Ownership.”

The True TCO Framework

Read more