Who this is for
Your team is considering holding an existing WebCenter estate while an upgrade, ERP program or replacement is planned. The question is what evidence would justify that decision and what must happen if the assumptions change.
For tier definitions, use the support-policy explanation. For the choice between forward paths, use the sponsor decision guide. This page focuses on operating during a deferral.
Establish the coverage boundary
Oracle’s Lifetime Support Policy distinguishes Sustaining Support from the stages that provide new fixes. Sustaining includes eligible existing material and technical assistance, with exclusions; it does not provide a new patch stream. Confirm the exact product, release, patch level and contract before relying on particular material or response terms.
A family-level date is a starting point. Forms Recognition, databases, operating systems, browsers and integration products need their own checks. The support dates reference links the published policy and identifies its limits.
If someone proposes a special support extension, record it as unknown until written terms are available. No cost model should quietly substitute assumed coverage for missing evidence.
Build the operating decision record
| Question | Evidence to collect | Decision or owner needed |
|---|---|---|
| What is installed? | Releases, patches, custom components, domains and connected systems | Technical owner confirms inventory scope |
| What needs remediation? | Relevant advisories, exposure assessment and available fixes | Security owner agrees the response or escalation |
| What is changing around it? | Planned identity, browser, database, ERP and infrastructure changes | Dependency owners coordinate compatibility checks |
| Can the process recover? | Recent restore evidence and representative business tests | Operations and process owners agree acceptance |
| Who can maintain it? | Named skills, access arrangements and available capacity | Sponsor addresses coverage gaps |
| What ends the deferral? | Funded next steps, prerequisites and decision milestones | A named decision owner and review date |
This is a proposed evidence structure. It is not a statement that any particular estate meets its controls.
Use review triggers, not an assumed safe window
Revisit the decision when a relevant vulnerability has no acceptable remedy, a required dependency changes, recovery tests fail, key engineering capacity is lost or the replacement plan slips. Define who receives the escalation and what evidence they need.
The appropriate response may be a configuration change, reduced exposure, an accelerated upgrade, a workload change or stopping an affected function. Test the chosen response and record the remaining limits. A compensating control needs the organization’s acceptance; naming one does not establish that it is sufficient.
Compare the full cost of waiting
Include engineering effort, retained licenses and infrastructure, monitoring, testing, incident handling, dependency work and the future exit project. Keep uncertain support terms visible. Use the scenario planner to compare stated assumptions, not to obtain a vendor quote or an automatic approval.
There is no evidence here for a universal break-even month. A longer deferral may change both cost and risk, but the direction and size depend on the estate and the options available.
Define the exit before it becomes urgent
Identify the desired end state and its prerequisites. A repository upgrade, a hosting move and replacement of invoice processing can have different owners and schedules. Include historical document access, retained workloads, ERP reconciliation and the disposition of active workflow instances.
An Estate Review can organize the findings and sequence. Support retainers provide separately agreed engineering capacity during the period. A major upgrade or migration receives its own scope and acceptance criteria.