JD Edwards World and IBM i Change Request Form Template
A change on an IBM i production partition touches payroll, orders and the general ledger at the same time. This template gives you a short, consistent form with the five things reviewers always ask for: what, why, when, how tested and how to undo it.
Fill in
JD Edwards World and IBM i Change Request Form Template
Change Request CR-2026-0142
Company: Acme Precision Ltd Requested by: A. Patel, Finance Systems Date: 2026-10-20 System or partition: PRODLPAR1 Change type: Program change Risk level: Medium
Summary and Reason
Summary: Update custom purchase order print program to show revised vendor payment terms.
Business reason: New supplier contracts changed standard payment terms effective 1 November.
Implementation Plan
Planned window: 2026-10-31 20:00 to 22:00
Before the change: take a backup of every object to be replaced, confirm no jobs are using them, and notify affected users.
After the change: run the agreed smoke tests and confirm results with the process owner.
Test Evidence
| Test | Environment | Expected result | Actual result | Tester |
|---|---|---|---|---|
| Unit test | Test library | |||
| Regression | Test library | |||
| User acceptance | Test library |
Backout Plan
Restore the previous program object from the saved backup library and clear the program cache by restarting the batch subsystem.
Approvals
This is a starting point for your own change control process, not a replacement for it. Add fields your auditors require, such as ticket references and segregation of duties confirmations.
Optional change control review
Want a second pair of eyes on your IBM i change process before the next audit?
Optional. The tool and every export work without this. No spam.
How to fill it in
Complete the fields at the top, then write a short summary and a business reason in plain language. Choose a risk level honestly: high means a failure stops orders, shipments or financial close. Describe the planned window and the backout plan before anyone approves anything. After your tests, print the form and add actual results. The signature lines record who agreed to the change before it happened.
- One form per change, not one per project
- Backout plan must be specific enough for someone else to run
- Attach test evidence rather than writing passed
- Record the actual implementation time afterwards
Why a form matters
Auditors test change management by sampling changes and looking for approval, testing and segregation of duties. On IBM i this often means showing that the person who wrote the program did not promote it to production without review. The form is the evidence. It also protects the team, because a clear backout plan makes it safer to say yes to a change.
Reading the risk level
Low risk changes are reversible within minutes and affect few users, for example a report heading. Medium risk touches a shared program or a data table with a tested backout. High risk includes operating system upgrades, PTF packages that need an IPL, data conversions and any change to posting logic. High risk changes should always have a rehearsal and an agreed go or no-go checkpoint.
Common mistakes
The most common mistake is a backout plan that says restore from backup without naming which backup, who does it and how long it takes. Another is testing in a library that differs from production. Record the library list and the object versions tested. Finally, do not skip the form for urgent fixes; use a shorter version afterwards and record the emergency approval.
Frequently Asked Questions
Is this form enough for audit?
It is a good base, but your auditors and policy decide what is required. Add approval levels, ticket references and segregation of duties fields as needed, and keep the signed copy where auditors can retrieve it.
Do PTFs need a change request?
Yes. PTFs and cumulative packages change system behavior and often need an IPL. Treat them as medium or high risk and record the package identifier, the test partition and the backout approach.
What about emergency changes?
Allow an emergency path with verbal approval from a named manager, then complete the form within a set period, such as one business day. Review emergency changes monthly to see whether they are being overused.
Can I add custom fields?
The downloadable document reflects the fields you see here. For extra fields, copy the exported document into your document system and extend it there.
Netray can help set up read-only checks that compare object versions between test and production so your change form is backed by facts.
Related Tools
JD Edwards World Custom Program and Modification Inventory Worksheet
Editable inventory of custom programs, modified objects and custom files with business criticality and a retire, keep or replace decision.
ERP OperationsIBM i (AS/400) Disaster Recovery Runbook Template
Fill-in recovery runbook for an IBM i production partition: objectives, restore sequence, contacts, validation steps and drill history.
ERP Migration & SelectionERP Cutover and Go-Live Plan Template for IBM i Migrations
Fill-in cutover plan for migrating from an IBM i ERP: freeze window, final data load, validation, go or no-go criteria and rollback.
More ERP Operations tools
See all- IBM i Batch Job Schedule Documentation Worksheet
- IBM i Disk Growth and Capacity Forecast Calculator
- IBM i Disk Capacity Runway Calculator
- ERP License Audit Risk Assessment
- ERP Support Cost Benchmark Calculator
- IT Ticket Backlog Cost Calculator
- ERP Database Growth Forecaster
- ERP Performance Health Check
- Legacy Report Modernization Calculator