Oracle Enterprise Applications

Yes. We support the release you run: patching within what Oracle still publishes, concurrent managers, workflow, period-close problems and the customisations nobody documented. We cannot produce patches that Oracle has stopped issuing. Where that leaves a gap, we write down compensating controls (network isolation, URL restrictions, tighter access, monitoring) and a dated upgrade plan, so the exposure is a recorded decision rather than a surprise.

Oracle publishes Critical Patch Updates every quarter. On 12.2 we apply them with online patching (ADOP), so users stay on the running system while the patch is applied and downtime is limited to the cut-over. Each cycle is rehearsed on a copy of production and checked against your customisations and interfaces. You get a short note of what was applied, what was deferred and why.

Coverage follows the tiers on our support page: Standard, Extended, and 24×7 Managed SRE, where a P1 is acknowledged within 15 minutes and an engineer is engaged within an hour. For Oracle estates the scope normally includes concurrent manager and workflow health, patching, period-close support and database administration, with a named lead who knows your customisations. New development and changes to scope are quoted separately rather than absorbed quietly.

By treating them as a register rather than a habit. Each extension is recorded with its reason, owner and risk rating. We check what Oracle already does before writing anything, and build to Oracle's extension rules: no changes to seeded objects or base tables and, on 12.2, online-patching standards for custom schemas and code. The register also shows which customisations to retire before an upgrade.

Through supported interfaces: Integrated SOA Gateway, open interfaces and APIs on EBS; REST services, file-based data import (FBDI) and Oracle Integration on Fusion. Every interface has an owner, a log of what it moved, a retry path and an alert, so a failed payment file or a stuck shipment is found by us before it is found by finance. We do not write directly to Oracle's base tables.

As a rehearsal, not a one-off. We run full mock conversions on production-sized data and reconcile each run against agreed controls: trial balances, open payables and receivables, on-hand inventory, open orders and the asset register. Cleansing happens at source, with your data owners signing off the rules. Go-live depends on the reconciliation passing, not on the calendar.

Usually, yes. We build on extracts and supported APIs, not on the ERP's tables: invoice capture, anomaly detection on payables, demand and cash forecasting, search over contracts and tickets. Anything that writes back to the ERP goes through the same interface controls and approval step as any other integration.

It depends on how much you have customised, what your licences allow, which modules you need and how much control you want over when change happens. Fusion Cloud is a subscription service: Oracle applies updates on its own quarterly schedule, and customisation is limited to supported extension tools. EBS gives you control over code, patch timing and where it runs, at the cost of running it. With EBS 12.2 Premier Support committed through at least 2037, the choice is rarely forced by a deadline. The estate review compares both for your estate on total cost, risk and process fit. We have no quota for either answer.

Four things: an estate review; an assessment of custom code against 12.2's online-patching standards; a technical upgrade rehearsed end to end on a copy of production; and a functional test cycle with your business users. The custom-code assessment is usually where the effort and the surprises sit, because 12.2 changes how objects must be built. Each rehearsal is timed, and the cut-over window is planned from those timings, not from an estimate.

The approach depends on size, downtime tolerance and licensing: EBS Cloud Manager for repeatable environment provisioning, Data Guard or RMAN for the database move, and Oracle's Zero Downtime Migration where it fits. Network, identity, backup and disaster-recovery design are agreed before any environment is built. Every migration is rehearsed, timed and reconciled by row count and checksum, with a rollback agreed before the window opens.

We cannot quote that honestly before the rehearsal. The rehearsal on a production-sized copy gives measured timings for each step, and the window is planned from them. Online patching, standby-based cut-over or incremental synchronisation shorten it where the estate allows. The go/no-go criteria and rollback plan are agreed before the window opens, so nobody makes that call under pressure.

In layers: quarterly security patching on a schedule you can audit; external-facing modules such as supplier or recruiting self-service placed behind a DMZ reverse proxy with only the required URLs exposed; TLS throughout; periodic review of responsibilities against segregation-of-duties rules; database hardening; and audit logging that someone reads. We look at what is exposed to the internet first, because exposure decides how urgent everything else is.

We can document what is deployed (products, options, environments, processor counts, users) and flag where usage looks inconsistent with the licence metric. That is the information an Oracle licensing review asks for. We do not interpret your contract or act as your licensing authority; for contract questions, confirm with Oracle or an independent licensing specialist. The same inventory supports the Fusion-versus-EBS decision and a bring-your-own-licence move to OCI.

Yes. In a GxP or audited environment, changes follow your change control, with documented requirements, risk assessment and test evidence your quality or compliance team can approve. We write to GAMP 5 practice, with 21 CFR Part 11 and EU Annex 11 in view, and your quality procedures take precedence. See OT & Regulated Environments.

Copies of production hold real employee, supplier and customer data. We mask or scramble personal and sensitive fields before a copy leaves production, restrict who can reach it, and delete it when the project ends. Access to every non-production instance is agreed in writing: who has it, what it covers and when it ends.

Yes, and the estate review comes first. It documents what has been built: a module and version inventory, a customisation register ranked by risk, an interface map with owners, patch history and support status, and a list of quick fixes. If the previous team is still available, we run knowledge-transfer sessions against that register. Nothing should depend on anyone's memory, including ours.

The engineers who build an extension sit on its support rota, and a named lead owns your estate across build and run. You deal with the people doing the work, not a sales layer. They work from Pune, India (UTC+05:30). Standard hours overlap the European morning; the Extended tier covers the full European working day and runs into the US East Coast afternoon; Managed SRE covers the rest.

A business owner for each process, access to a non-production instance, and someone who can approve changes to how work is done, not just to the system. Add your period-close and change-freeze calendar, so cut-overs and patch cycles avoid it.