Before You Replace the Legacy ERP, Learn What It Is Actually Doing
I spend much of my time helping organizations move from established enterprise systems to modern cloud platforms. Increasingly, that work has involved large public-sector transformations where the word legacy can mean many things: PeopleSoft, an older commercial ERP, a mainframe application, a custom database, or an ecosystem of systems and interfaces that has accumulated over decades.
When we begin these transformations, there is a natural tendency to focus on the destination.
But before designing the future state, a transformation team also needs a reliable understanding of what the legacy environment is actually doing today. That idea was reinforced for me at Ascend 2026, when I attended a presentation by Tirumala Rao Chimpiri (Tiru) on PS-CARE, the PeopleSoft Continuity Automation & Resilience Engine, a framework he developed.
What interested me as a transformation consultant was the possibility of using operational history during discovery. It could help us ask better questions about the systems we are preparing to transform.
The Legacy System Is Part of the Transformation
An organization may spend years planning, funding, designing, configuring, converting data, building integrations, testing, preparing for cutover, and stabilizing a new environment.
During those years, the legacy system does not suddenly become unimportant because it has a planned retirement date.
Payroll still has to run. Vendors still have to be paid. Financial periods still have to close. Interfaces still have to complete. Reports still have to be produced.
This is especially apparent in the public sector, where I frequently encounter environments that have evolved over many years and sometimes decades. What we casually call the "legacy system" may actually consist of an ERP, mainframe applications, data warehouses, agency-specific systems, scheduled interfaces, extracts, reports, and custom processes held together by both technology and institutional knowledge.
Higher education is a good example of this challenge. Institutions may depend on years of accumulated PeopleSoft processes supporting payroll, finance, student administration, reporting, and integrations while simultaneously preparing for a new ERP or cloud environment. Understanding which of those processes remain active, how they behave, and what depends on them can become an important part of transformation discovery.
Better visibility is not necessarily an investment in keeping the old platform forever. It can be an investment in making the transition away from it more successful.
For CIOs and ERP leaders, that distinction matters. The question is not whether to preserve legacy technology indefinitely, but whether better evidence about the current environment can reduce transition risk and improve decisions about what should be carried forward, redesigned, consolidated, or retired.
Operational History Can Become Discovery Data
We inventory applications, identify interfaces, examine reports, profile data, interview business owners, document business processes, and determine which information needs to move into the future environment.
Documentation and interviews tell us how people understand the environment. Operational evidence can complement that understanding by showing how the environment has actually been behaving.
For example, an interface documented as a nightly process may not have run successfully in months. A process described as monthly may actually be launched repeatedly during financial close. A supposedly routine batch process may regularly require manual intervention. Conversely, a process described as business-critical may show little recent activity.
None of these observations provides an answer by itself. Instead, they give the transformation team better evidence with which to conduct discovery and better subjects for discussion with business and application owners.
What PS-CARE Adds to the Discovery Discussion
For an administrator, a process that takes three hours instead of its usual 30 minutes is a support concern. During discovery, I would also want to know whether that was an isolated incident or part of how the process is routinely used and supported.
PS-CARE brings configured process expectations together with records of issues and how they were resolved. It is built in PeopleTools and works with PeopleSoft Process Scheduler metadata. Where the relevant history has been retained, that combination can give a discovery team something specific to examine with the people responsible for the process.
That information is useful for operating an ERP. From a consulting perspective, I think it can also be useful when preparing to transform one.
The Connection to Data Migration
My own perspective on this is heavily influenced by data migration and data governance.
During a conversion, it is rarely enough to know that a particular value exists in a database table. We also need to establish its origin, understand which business process created or modified it, determine when it becomes authoritative, identify the rules applied to it, and understand the downstream processes that depend upon it.
Traditional data lineage might describe a path from a source table, through transformation logic, into a target object. In practice, meaningful lineage can be broader:
Illustrative process and data flow to investigate during transformation discovery (Image courtesy of Dennis Gray)
Understanding the operational environment helps us reconstruct some of that story. Scheduler history alone does not establish data lineage; the application logic and business explanation still need to be examined.
Technical documentation becomes outdated. Employees retire or move into other roles. Customizations accumulate. Interfaces are added to solve immediate business problems. Processes that began as temporary workarounds sometimes become permanent parts of operations.
The data remains, but the explanation for why it exists can become harder to find.
Operate, Understand, Transform
I find it useful to think about this information in three ways:
- Operate. Operational information helps teams determine whether the current environment is functioning as expected, including whether important processes are starting on schedule, completing within normal timeframes, and receiving attention when exceptions occur.
- Understand. Historical patterns can reveal how the organization actually uses the system. They can highlight active processes, recurring interventions, unusual runtimes, and potential dependencies that deserve further investigation.
- Transform. That evidence can then inform discussions about which behaviors need to be preserved in the future environment, which should be redesigned or consolidated, and which should disappear entirely.
One danger in any transformation is assuming that everything the legacy environment does must somehow be recreated in the new environment. It does not.
A process can run perfectly every night and still represent a business or technical workaround that should not survive modernization. Conversely, an obscure process that attracts little attention may support a critical downstream dependency that absolutely must be addressed before cutover.
Evidence Is Not the Same as an Answer
Process histories, runtimes, schedules, statuses, alerts, and other system-generated evidence that show how an application is actually operating (sometimes called operational telemetry) should not be mistaken for business-process documentation. Nor should it dictate transformation design.
Frequent use and steady performance do not, by themselves, establish business value or sound design. An unusual pattern needs to be understood before it is treated as a problem.
Frameworks such as PS-CARE can provide evidence. Application teams, business owners, architects, data teams, and transformation consultants still have to determine what that evidence means.
In practice, this evidence can make discovery conversations considerably more productive. Rather than starting with a broad request for someone to describe overnight processing, for example, a transformation team can bring actual execution patterns into the discussion.
That is a much more consultative use of operational information than simply producing another monitoring dashboard.
Modernization Before Replacement
This is ultimately why my conversation with Tiru and the PS-CARE presentation stayed with me.
PS-CARE's relevance to me is the connection between the history available to an operations team and the questions facing a transformation team. Bringing that history into discovery can help us make better-informed decisions about the replacement.
The closer an organization gets to replacing a legacy system, the less inclined it may be to invest in that system. Yet that is also a period when understanding the legacy environment becomes particularly important.
Modernization does not always begin with replacement.
Sometimes it begins by understanding more clearly what the system you intend to replace has been telling you all along.