Executive Point of View: Building the Next-Generation JDE Platform
The immediate priority is to establish an independent, supportable JD Edwards environment. That requirement should drive the first set of decisions. It should not, however, define the full ambition of the program.
Treating this solely as an infrastructure migration would address the hosting constraint but leave much of the current operating complexity intact. The better course is to use the separation as an opportunity to simplify the ERP foundation, improve access to trusted operational data and introduce AI selectively where it can remove manual effort without weakening business controls.
Enterprises in this position should sequence the transformation in three stages. The first is to protect business continuity by moving the JD Edwards transactional core away from IBM i and DB2/400. The second is to establish a governed data foundation for finance, operations and management reporting. AI-enabled workflows should follow only after the underlying data, access model and approval controls have been proven.
This is deliberately not an autonomous-AI proposition. Moving Oracle database services into Google Cloud also does not eliminate the integration, security, licensing, or operational responsibilities that exist across the environment. The value comes from designing the ERP platform, data foundation and AI capabilities as parts of the same operating model.
The scale of an enterprise’s estate makes that discipline important. In organizations with a large scale, migration success depends as much on integration behavior, reconciliation, recovery and operational readiness as on the target technology itself. Consider organizations with several thousand users, close to a hundred integrations and millions of integration transactions per day. In such cases discipline and a structured approach to migration is critical.
1. The Decision Facing the Enterprise
In many organizations, JD Edwards 9.2 remains deeply embedded in finance and operational processes. The challenge is that such an application depends on an aging IBM i platform, a shrinking pool of specialist skills, RPG and CL components and a substantial integration footprint.
Remaining on that platform increases supportability and change risk. Moving too aggressively creates a different set of risks around data conversion, application behavior, performance, integrations and cutover.
The target architecture therefore needs to answer four practical questions:
- Does the proposed platform support the certified JD Edwards configuration and expected workload?
- Can DB2/400 data be converted, synchronized, reconciled and recovered within acceptable business tolerances?
- Can reporting and analytics be improved without recreating the current duplication of data and pipelines?
- Can AI assistance be introduced while preserving access controls, auditability, segregation of duties and human accountability?
A product's technical capability is relevant, but it should not be the primary basis for the decision. The architecture needs to work as an end-to-end service.
2. Recommended Target Direction
The proposed direction is to run JD Edwards on a certified application stack with Oracle Exadata, delivered through Oracle AI Database@Google Cloud, as the database foundation.
RAC and Data Guard provide important availability and recovery capabilities. They should not be treated as the complete resilience design. Application-tier redundancy, network dependencies, recovery procedures, monitoring, service ownership and operational rehearsals all need to be addressed.
The key question is not whether individual components are highly available. It is whether the JD Edwards service can continue or recover predictably when one of those components fails.
BigQuery is the proposed analytical foundation, with Looker providing governed business measures and semantic consistency.
Datastream, Dataflow, Dataform and Cloud Composercan support replication, processing, transformation and orchestration where they fit the confirmed source and target requirements.
We would avoid migrating every existing pipeline simply because it exists today. The first step should be to identify which reports, datasets, interfaces and historical stores continue to serve a business purpose. Existing warehouses, ETL jobs, retention requirements, ownership and downstream dependencies should be understood before retirement or replacement decisions are made.
Gemini Enterprise Agent Platform will provide conversational and agent-assisted capabilities using authorized Oracle data, BigQuery history, Looker measures and relevant catalog metadata.
The initial role of these agents should be narrow: investigate an issue, assemble supporting information, recommend an action, or prepare a draft.
Where an action has a financial or operational consequence, the accountable business user should remain in the approval path. Direct and unrestricted ERP write-back should not be part of the initial design.
3. Migration Architecture and Engineering Considerations
Moving JD Edwards data from DB2/400 to Oracle is a heterogeneous database conversion. It should not be planned as though it were a conventional Oracle-to-Oracle migration.
That distinction matters because the conversion method, synchronization approach, testing strategy and fallback design are different.
The proposed pattern uses JD Edwards-generated Oracle schemas, IBM InfoSphere CDC and Oracle GoldenGate where the source and target combinations are supported. An Oracle staging environment can provide a controlled point for initial conversion and synchronization before the data is moved into the target Exadata environment.
RMAN, Data Pump and Zero Downtime Migration may become useful once the data is represented in Oracle. They should not be positioned as direct DB2/400 conversion tools.
Four areas deserve particular attention.
Schema fidelity
The team should validate data types, indexes, constraints, large objects, sequences and JD Edwards-specific table behavior rather than assuming that a technically successful conversion is functionally equivalent.
Business reconciliation
Row counts are useful but insufficient. Reconciliation should include financial balances, document counts, inventory quantities, open transactions and other business control totals agreed with process owners.
Workload behavior
Testing needs to cover interactive transactions, batch processing, integrations, scheduling, reporting and peak business events such as month-end processing. Results should be compared with agreed current-state baselines.
Cutover and recovery
The production cutover should be rehearsed from end-to-end. The rehearsal needs to establish synchronization thresholds, decision authority, rollback criteria and the feasibility of reverse replication where the technology supports it.
PDDTA and PDCTL synchronization, Interconnect availability, standby promotion and reverse-CDC behavior should be resolved during engineering. They are not details to leave until the final cutover plan.
4. Data and Analytics Modernization
The data program should start with the information the business needs to trust, rather than with a target list of technologies to replace.
Snowflake is a good example. Once its actual scope is confirmed, the enterprise can compare three options: retain it, operate it alongside BigQuery, or migrate selected workloads to BigQuery.
That decision should use real workload evidence. SQL compatibility, report behavior, latency, retention requirements, consumption economics and downstream dependencies all matter. Based on the material currently available, there is not enough evidence to assume that every Snowflake workload belongs within the migration scope.
For operational replication, Oracle-to-BigQuery CDC is the leading proposed pattern. Datastream can capture supported Oracle changes, while Dataflow and Dataform can handle processing and transformation. Cloud Composer is appropriate where workflow orchestration is genuinely required.
Existing visual integration tools should be assessed individually. Recreating them automatically as another service layer would add complexity without necessarily adding value.
The semantic layer is equally important. Finance and operations should agree on the definition of measures such as:
- DSO
- Inventory exposure
- Invoice exceptions
- Close-cycle progress
- Supplier performance
Those definitions should be established before conversational analytics or agent-based access is scaled. Otherwise, AI will make inconsistent information easier to consume rather than making the information more reliable.
5. Practical Opportunities for Agentic AI
The strongest early AI use cases are likely to be activities where employees spend time gathering information, comparing records, investigating exceptions, or preparing routine analysis.
Gemini Enterprise Agent Platform can provide the reasoning layer, surfaced through Gemini Enterprise or embedded into business experiences. Where custom agents are required, Agent Development Kit (ADK) and supported orchestration patterns can be considered.
The important design principle is that the agent should work from information the user is already entitled to access. Grounding can include authorized Oracle records, BigQuery history, Looker measures and catalog context.
| Business process | Initial agent-assisted use | Control required |
|---|---|---|
| Order to cash | Identify overdue accounts and prepare collection drafts | Finance approval before customer communication or account action |
| Procure to pay | Compare invoices, purchase orders, receipts and supporting documents | Human approval before exception resolution or posting |
| Financial close | Investigate material variances and prepare draft commentary | Controller review with traceability to governed measures |
| Supply chain | Identify inventory exceptions and recommend items for replenishment review | Planner approval before creating or changing an order |
| Vendor oversight | Highlight unusual vendor-master or document activity | Procurement or risk review before intervention |
| Executive information | Answer questions using approved finance and operational measures | Permission-aware retrieval with visibility of supporting sources |
Table 1: Opportunities for leveraging Agentic AI
Three controls should be established before these capabilities are scaled:
- An agent should not receive broader access than the user or service identity requires.
- Business answers should be grounded in authorized records and approved measures.
- Actions that change ERP records should remain behind an accountable approval step until the control model has been proven.
6. Reference Architecture
The proposed architecture consists of six connected areas:
Figure 1: Analytical flow to governed analytics and agentic experiences
The primary analytical flow is expected to move Oracle data through Datastream into BigQuery, followed by consumption through Looker or governed agent experiences.
There may also be cases where an agent needs authorized access to Oracle data directly. Those patterns should be evaluated against latency, security and support requirements rather than adopted by default.
Approved business actions should return through controlled application interfaces. Direct, unrestricted database writes from an AI agent should not be part of the target pattern.
Security applies across the architecture rather than sitting in a separate layer. IAM, encryption, key management, network boundaries, audit trails, service perimeters and recovery responsibilities need to be validated across both Oracle and Google Cloud service domains.
7. Delivery Roadmap
The first phase should resolve the facts that drive architecture and sizing.
This includes production, non-production, disaster-recovery, archive and staging volumes; the table inventory; integration catalog; certification requirements; licensing position; security requirements; and warehouse scope.
In cases where the source material contains different database and table totals those differences need to be reconciled before the target environment is sized and approved.
Exit criterion: a signed-off baseline, target configuration and agreed conversion approach.
Build the landing zone, connectivity, Exadata service, identity model, logging and core security controls.
Rather than attempting a broad migration immediately, convert one representative non-production JD Edwards library. Use it to prove schema fidelity, application behavior, integration connectivity, reconciliation and operational procedures.
Exit criterion: agreed data, functional, operational and performance criteria have been met.
The next step is to test the design under realistic production conditions.
Run scale tests, cutover simulations, disaster-recovery exercises and fallback rehearsals. CDC lag should be measured under representative workloads rather than assumed from nominal throughput.
The rehearsal should also establish who has authority to stop or reverse a production cutover.
Exit criterion: joint business and technology approval of production readiness.
Execute production synchronization and cutover using the rehearsed procedure.
The immediate objective after cutover is stability. JD Edwards transactions, batch processing, integrations, recovery procedures and operational monitoring should be proven before the program expands the analytics or AI scope.
A fallback period should be explicitly defined rather than left open-ended.
Introduce BigQuery and Looker by business domain, starting with a limited number of measures that finance and operations have agreed are authoritative.
The first agent-assisted process should also be deliberately narrow. Its value should be measured using actual effort reduction, quality, control effectiveness and user adoption before similar patterns are scaled.
A realistic ambition is to have the landing zone operational, Exadata provisioned, one non-production library validated and a BigQuery/conversational-analysis pilot underway, subject to procurement and technical dependencies.
Interconnect readiness and PDDTA/PDCTL CDC remain important dependencies.
8. Business Value and TCO
Retiring the IBM i/AS/400 platform and re-platforming JD Edwards can reduce infrastructure complexity and improve availability, provisioning and security. The size of those benefits should be validated against the customer's actual baseline rather than treated as committed savings at this stage.
| Value area | Working hypothesis | Evidence needed before commitment |
|---|---|---|
| Infrastructure and licensing | 30-50% reduction | Current contracts, hardware, support costs, cloud consumption and Oracle database licensing position |
| Data platform and ETL | ~45% reduction | Warehouse consumption, tooling, support and engineering costs |
| Analytics speed | 60-70% faster time to insight | Current report-development and decision-cycle baselines |
| Targeted workflow effort | ~60% reduction | Process-level time study and pilot results |
| DSO improvement | 5-15% | Receivables baseline, customer segmentation and collections policy |
| Invoice-exception effort | 30-50% reduction | Exception volumes, handling time and automation eligibility |
| Unplanned downtime | 60-70% reduction | Incident history, final availability design and recovery-test results |
Table 2: Potential benefits across value areas
These figures should remain working hypotheses until the assessment establishes the underlying cost and process baselines.
The business case will be more credible if each benefit is tied to an owner, a baseline, a measurement method and a point in the roadmap when the benefit can reasonably be expected to appear.
9. The LTM Advantage
LTM accelerates JDE modernization on GCP through a proven lifecycle approach and 30+ INFINITY accelerators spanning assessment, migration, security, automation and AI-led operations. This integrated model reduces migration risk and business disruption while improving governance, cloud consumption and operational efficiency, with the potential to lower AMS costs by more than 30%.
10. From Infrastructure Retirement to Business Improvement
Retiring the legacy infrastructure solves an immediate problem. It should also create a platform that is easier to operate and easier to improve.
The first measure of success is straightforward: JD Edwards continues to support the business reliably after separation, with a supportable database platform, tested recovery and stable integrations.
The next measure is whether finance and operations can work from information they trust without recreating the current reporting complexity.
AI comes after those foundations are in place.
Used selectively, agent-assisted workflows can reduce the time employees spend gathering information, investigating exceptions and preparing routine analysis. They should not remove accountability from the people responsible for financial and operational decisions.
"Protect continuity first, simplify the operating model, establish trusted information and then use AI where there is a measurable reason to do so."
The result is more than a change in hosting location. It is an opportunity to leave the enterprise with a JD Edwards platform that is supportable today and better positioned for the next stage of operational improvement.
About the Author
Guruprasad Gonjare — Senior Director of Cloud Architecture, LTM
Guruprasad has 23 years of global experience leading enterprise cloud and AI transformations. He specializes in modernizing ERP systems and database platforms across multiple clouds. At LTM, Guru drives Oracle Cloud Infrastructure (OCI) growth. He leads go-to-market strategy, pre-sales and solution development, and he builds the solutions and accelerators that customers use to move Oracle and non-Oracle workloads to the cloud. He also has deep expertise in AWS, Azure and Google Cloud and builds hybrid and multi-cloud platforms tailored to each customer's needs.
Outcreate Your Business
Outcreate with LTM
Outcreate Together
It’s time to Outcreate