The Keepers of Yesterday's ERP

I hear from careful CIOs: "We can keep Oracle EBS running for as long as we need. It is still cheap enough. Why archive it?" That is a reasonable position. Oracle still supports EBS 12.2 through its Continuous Innovation strategy, and Oracle has announced Premier Support through at least 2037. The system may be stable. The hardware may be depreciated. The team may know the quirks. And if on-premise EBS becomes too expensive to maintain internally, managed hosting can reduce cost and operational effort. So the practical CIO is not wrong to ask why the company should spend money retiring something that still works.

The harder question sits underneath the sensible one. A business can confuse a valuable asset with the container it came in. Oracle E-Business Suite (EBS) history is a valuable asset. Old invoices, journals, payroll records, approvals, purchase orders, project costs, supplier records, customer history, and attachments are not obsolete paperwork. They are facts. Some are regulated. Some explain balances. Some may save time in an audit. Some may contain insights the company has not mined yet. But the Oracle E-Business Suite (EBS) application stack is not the fact. It is the container. Once Fusion Cloud is running the business, keeping Oracle E-Business Suite (EBS) alive forever may be like paying rent on an old office because the filing cabinet is still in the corner.

When a company moves to Fusion Cloud, the current operation moves. Orders, invoices, payments, procurement, projects, HR, payroll, and accounting begin to flow through the new system. But EBS does not become empty. It becomes historical. That sounds harmless until you ask what "historical" means.

Historical data is not merely old data. It is the company's memory of what happened. It can answer questions no one is asking today but someone will ask later: Why was this supplier paid twice? Who approved that invoice? Why does this balance exist? What was the payroll result for that period? Which project costs drove the overrun? Where is the attachment that supports this journal? What was the purchasing pattern before we changed the policy?

A retirement plan becomes too thin when it treats history as a storage problem. History is also an access problem, a control problem, an evidence problem, and increasingly an insight problem. There are retention laws, tax rules, legal holds, industry requirements, internal policies, security obligations, and audit expectations. There is also business value. Supplier behavior, invoice exceptions, approval delays, project overruns, account usage, payroll patterns, and purchasing leakage all live inside historical transactions. The company cannot throw the data away just because Fusion is live. But it also does not follow that the old ERP application must live forever. Data retention != application retention. It is an easy distinction to miss.

Here is the part that rarely appears in the budget model: the data may remain valuable while the organization's ability to use EBS decays. EBS functional experts retire, change roles, or become scarce. Apps DBAs are pulled into newer priorities. Business users forget old responsibilities, menus, and report names. Custom report logic becomes tribal knowledge. New finance users know Fusion, not EBS. Auditors still ask for old evidence, but fewer people remember where the evidence lives.

The database may be stable. The application may still launch. The login screen may look unchanged after years of reorganizations, upgrades, and finance leadership changes. But the human system around it weakens. That quiet cost rarely shows up as a single budget line. It is not only hosting. It is institutional dependency. Someone still has to know what to query, which responsibility to use, which report was customized, which attachment table matters, which operating unit filter applies, and which old answer is trustworthy. The company keeps the data, but slowly loses the practical ability to use it. Over time, corporate memory becomes harder to trust.

There are many respectable ways to avoid making the archive decision. Keeping EBS on-premise is the familiar path. It may be acceptable for a short transition, but it preserves the heaviest operating burden: infrastructure, patching, backups, monitoring, access reviews, database support, application support, and old skills. Managed hosting is a better answer when EBS still works for a living. If EBS still runs transactions, workflows, integrations, custom programs, or open business processes, then EBS still needs an operating model. Managed hosting can reduce cost compared with on-premise EBS and reduce the burden on internal teams. That can be a good decision.

But managed hosting and archiving solve different problems. Managed hosting can reduce the cost of keeping EBS alive. Archiving reduces the need to keep EBS alive. That distinction is the whole game. A read-only database copy is another tempting answer. It feels lean. It may help technical teams query old data. But a database copy is not a business experience. It does not give finance a friendly invoice search, audit a repeatable evidence workflow, security a clean access model, or users an easy way to retrieve attachments.

Analytics and data lake tools are also useful, but they answer a different question. They are excellent for trends, dashboards, cross-system reporting, and insight. They are not, by themselves, the place an auditor goes to retrieve the approval support for one invoice from six years ago. Loading selected history into Fusion can help when a small amount of history belongs in the new operating model. But Fusion should not be asked to carry every old EBS transaction simply because no one designed a better home for history. Each option has its place. The order matters: first understand the future use of the data, then choose the container. If EBS still runs the business, host it properly. If EBS is only guarding the archives, give the archives a better home.

A good archive is not merely a cheaper bucket. It is a memory system. A company does not remember everything in the same way. Some memories are used every week. Some are needed only during audits. Some are useful for analytics. Some are kept because a tax authority, regulator, lawyer, or internal policy may ask. EBS history is the same.

Treating all old data the same usually means the design has stopped too early. The better archive matches data to its future access pattern. Working memory needs browser-based reports, search, filters, and exports. These are the invoices, journals, suppliers, employees, projects, payments, purchase orders, and attachments that finance, HR, procurement, supply chain, and audit teams may still need to find. This is where an archive database such as Oracle Autonomous Data Warehouse is useful: it keeps historical Oracle E-Business Suite (EBS) data queryable through SQL and reportable through tools such as Oracle APEX without preserving the full Oracle E-Business Suite (EBS) application stack.

Evidence memory needs stronger discipline: approvals, supporting documents, created-by and updated-by fields, retention controls, and repeatable audit exports. It is not enough to have the data somewhere. The organization has to retrieve it consistently when the question arrives. Analytical memory is different again. Supplier trends, invoice exceptions, payment timing, project overruns, account usage, and historical patterns can help improve Fusion processes. Old data can become raw material for better decisions, process mining, anomaly detection, and future AI use cases. ADW can support this analytical layer directly when the history needs to remain close to SQL reporting and archive application access.

Cold memory is the long tail. Some history may not need daily reporting, but it should remain retained, queryable, and cost-efficient. This is where ADW, object storage, archive storage, and compressed columnar formats such as Parquet can all have a role, depending on how often the data is queried and who needs to use it. Parquet is not a complete answer by itself. A file will not answer an auditor or teach a finance user how to find an invoice. A file is not a user experience. For frequently searched history, ADW is often the better center of gravity because it supports SQL, reporting, security design, and the browser archive experience. For colder analytical history, Parquet in object storage can be considered as an additional tier. Apache Parquet is designed for efficient storage and retrieval with compression and encoding, and Oracle Autonomous Database can query Parquet data in object storage through external tables.

No one should read this as a proposal to put everything in Parquet. The better habit is to match the data to the access pattern. Archiving is not about burying history. It is about putting each kind of history where it belongs.

The useful question is whether EBS is still working for a living or merely guarding the archives. You are probably not ready to retire EBS if active transactions still run there, integrations still write to it, users still depend on EBS workflows or approvals, open processes remain unresolved, or business owners cannot agree on what "retired safely" means. In that case, keep EBS operating well. Managed hosting or OCI may be the practical move.

You are closer to archival when Fusion Cloud is live or nearly live, EBS is no longer used for new transactions, integrations no longer write to it, users primarily need historical inquiry and exports, attachments are understood, security groups can be defined, and a final freeze, export, validation, and cutover window can be planned. If EBS still works for a living, do not retire it. If EBS is only guarding the archives, give the archives a better home.

This is where EBSArchive fits. It is designed for organizations that have moved from Oracle EBS to Fusion Cloud or another ERP and want to retire EBS while preserving historical access. The model uses customer-owned OCI services such as Autonomous Data Warehouse, Oracle APEX, OCI Object Storage, identity controls, and data-level security to provide browser-based historical reporting, attachments, controlled access, and a path to colder retention where the access pattern fits.

The old system and the old data are not the same thing. The data is valuable. The data may be regulated. The data may contain insights the company has not fully mined yet. The data may be needed in five years when someone asks, "Why did this happen?" But that does not mean the old application must live forever.

If you are the CIO, ERP leader, or IT owner looking at a quiet EBS environment after Fusion Cloud, ask the uncomfortable question: Are we still running EBS because the business needs ERP capability, or because the business needs memory? If the business still needs ERP capability, operate EBS well. Managed hosting or OCI may be the practical move. If the business needs memory, preserve the facts, protect the evidence, keep the insights available, and retire the machinery that no longer runs the business.

A useful EBS retirement review starts there: with the EBS versions, modules, data volume, reporting needs, attachment scope, access requirements, audit obligations, cold-data strategy, and likely retirement blockers. The goal is to leave with a clearer view of whether EBS should stay hosted temporarily, move to OCI, remain available through analytics or database access, or be retired through an archive. You do not have to lose EBS history to retire EBS. You need a way to preserve the memory without keeping yesterday's ERP alive forever.