Oracle E-Business Suite upgrades are rarely just application upgrades. They sit within a wider technical estate that can include Oracle Database, middleware, operating systems, integrations, custom code, reporting, security components and operational processes.
That is why dependency mapping should come before detailed upgrade planning. The objective is to understand not only the current EBS version, but the complete set of components and relationships that could affect the upgrade path.
Start with the application and database baseline
The first step is to establish the current E-Business Suite release, database version, application tier architecture, operating system, middleware stack and patch level. This provides the baseline for identifying supported upgrade paths and technical prerequisites.
It is also important to distinguish between what is documented and what is actually running. Historic build documents can be useful, but they may not reflect later patches, configuration changes, temporary fixes or infrastructure moves.
A reliable baseline should therefore be evidence-based, drawing on configuration, inventories, patch records and the live platform where appropriate.
Customisations can drive the real workload
Standard application components are only part of the picture. Many EBS estates contain years of custom development, personalisations, interfaces, reports and extensions.
Customisations should be inventoried and classified so the upgrade team can understand what needs remediation, retesting or retirement. This can include custom forms, concurrent programmes, database objects, workflows, integrations, shell scripts, reports and bespoke interfaces.
A useful question is not simply whether custom code exists, but whether it is still required. Upgrade programmes are an opportunity to remove obsolete components rather than automatically carry every historic customisation forward.
Integration dependencies need early attention
EBS often sits at the centre of a broader business process. It may exchange data with payroll, banking, procurement, reporting, document management, identity systems, third-party platforms and bespoke applications.
Each interface has its own technical assumptions. These can include hostname, IP address, database connectivity, file paths, certificates, authentication methods, scheduled jobs or specific data formats.
Even where the core EBS upgrade is technically successful, an overlooked interface can create significant operational disruption. Integration discovery should therefore be completed early enough to influence the test plan and cutover sequence.
Database dependencies must be mapped
The Oracle Database layer needs its own dependency review. The target EBS release may impose database version or compatibility requirements, while the database itself may depend on specific backup, monitoring, encryption, replication or high-availability arrangements.
Database links, directory objects, external tables, scheduled jobs, custom schemas and third-party connections should be reviewed. The upgrade team should also understand how the database is backed up and how recovery would work if the change needed to be reversed.
DNC’s Oracle and E-Business Suite Consultancy covers database upgrades, EBS modernisation, migration and legacy support.
Identity and security should not be treated as separate
Authentication and access-control dependencies can easily be missed if the programme focuses only on the application stack.
Single sign-on, Oracle Access Manager, directory services, certificates, service accounts and external identity providers may all need testing. Privileged access arrangements, administrative accounts and technical users should also be understood before the upgrade begins.
The upgrade can be a useful point to review whether inherited access remains appropriate and whether unsupported or weak authentication dependencies should be removed.
Infrastructure dependencies influence the upgrade plan
The application and database tiers depend on the underlying infrastructure. That includes compute capacity, storage, network routes, DNS, load balancing, firewalls, backup platforms, monitoring and any cloud services used by the environment.
Where EBS is being upgraded alongside a move to OCI or another platform, these dependencies become even more important. Combining an application upgrade with infrastructure migration can reduce repeated change, but it also increases the number of moving parts that need to be controlled.
For cloud-hosted Oracle environments, DNC’s Cloud Architecture and Engineering services can support the surrounding platform design.
Build the test strategy from the dependency map
A good test plan should reflect the real system, not just the standard application functions.
Technical validation should cover database and application services, interfaces, batch processes, authentication, reporting, printing, integrations and operational tooling. Business testing should focus on critical end-to-end processes rather than isolated screens.
Dependency mapping helps identify where test coverage is needed. If a component is important enough to depend on, it should normally appear somewhere in the validation plan.
Cutover planning needs more than an outage window
The cutover plan should define the sequence of technical activities, dependencies, decision points and responsibilities. It should include pre-change checks, backups, stopping and starting services, upgrade steps, integration controls, validation activities and communication points.
Rollback should also be explicit. Teams need to know what conditions would trigger rollback, how long reversal would take and whether the data state allows a clean return to the previous environment.
A theoretical rollback procedure that has never been tested is not the same as a proven recovery path.
Common dependency-mapping mistakes
One common mistake is assuming that an old architecture diagram represents the current system. Another is relying only on technical teams and not involving application owners who understand business processes and integrations.
It is also easy to catalogue dependencies without assigning ownership. Every significant interface, custom component and operational process should have someone responsible for validation.
Finally, teams sometimes discover customisations during testing rather than during assessment. That pushes avoidable risk into the most time-sensitive phase of the project.
What good looks like
A well-prepared EBS upgrade has a clear technical baseline, known customisations, mapped interfaces, understood database dependencies, documented identity and security requirements and a test plan derived from those findings.
The team knows which components are being upgraded, retired, migrated or left unchanged. Responsibilities are clear and cutover decisions are based on evidence.
Conclusion
Oracle E-Business Suite upgrades succeed more reliably when they are treated as changes to an ecosystem rather than a single application.
Dependency mapping provides the structure needed to understand that ecosystem. It improves scoping, testing, sequencing and rollback planning, while reducing the chance that an undocumented integration or custom component becomes a late surprise.
If you are planning an Oracle EBS upgrade, migration or modernisation programme, see DNC’s Oracle and E-Business Suite services or discuss your requirements with us.