Rehearse the IBM i migration before setting the outage
The useful downtime estimate comes from moving a representative recovery set and testing the application. A copy-speed calculation misses restore processing, configuration work and business acceptance.
- Prepare a recovery set using the agreed migration method.
- Restore or seed the destination and record elapsed times and errors.
- Run the agreed acceptance checks with the business owners.
- Use the measured results to set the cutover window and go/no-go deadline.
Keep the rehearsal isolated from production interfaces. The copied system must not send live orders, scheduled messages or duplicate payments while it is being tested.
Agree what a successful IBM i move looks like
| Check | What the owner needs to confirm |
|---|---|
| Restore and system access | Review restore logs, missing objects and console access before opening application tests. |
| Business application tests | Run representative business transactions and compare expected records and results. |
| Interfaces and scheduled work | Test inbound/outbound feeds, scheduled jobs and printing with the responsible owners. |
| User access and security settings | Check profiles, authority and required security configuration in the new environment. |
| Workload and response time | Compare representative jobs and response times with the agreed baseline; investigate bottlenecks before go-live. |
| Backup and recovery after the move | Complete and verify a usable target-system save with the recovery method the business will use. |
Restore and system access
Review restore logs, missing objects and console access before opening application tests.
A completed restore command is only the beginning. Resolve omissions against the recovery checklist and confirm the intended system and application are usable.
Business application tests
Run representative business transactions and compare expected records and results.
Choose tests with known expected results. The acceptance owner should be able to show that the full business process completed, including dependent applications.
Interfaces and scheduled work
Test inbound/outbound feeds, scheduled jobs and printing with the responsible owners.
Confirm addresses, routing and endpoint changes. Release recurring work deliberately so the source and destination do not both process the same business event.
User access and security settings
Check profiles, authority and required security configuration in the new environment.
Preserve the intended authority model and review any temporary access used during the move. Include profiles used by batch jobs and external integrations.
Workload and response time
Compare representative jobs and response times with the agreed baseline; investigate bottlenecks before go-live.
Compare like-for-like work at the agreed load. Processor capacity, memory pressure and storage response can affect different jobs in different ways.
Backup and recovery after the move
Complete and verify a usable target-system save with the recovery method the business will use.
The new system needs its own usable recovery set after the final changes. Verify access to the media and documentation from the place recovery would actually be performed.
Make the final IBM i switch a controlled sequence
- Confirm the destination is ready and the rehearsal issues are closed.
- Stop or quiesce applications as required by the chosen migration method.
- Complete the final save or synchronization and verify its status.
- Change the agreed connections and run the acceptance checks.
- Release users and scheduled work after the named owner accepts the result.
A replication-assisted move still needs a consistent final state and a deliberate point at which the destination becomes production. Keep the old system from receiving ordinary production work after that decision.
Decide how to recover before new transactions begin
Agree the deadline for returning to the original system and the person who can make that decision. Keep the source recoverable until the target passes acceptance, subject to the selected method and licensing terms.
After the target accepts new business transactions, returning to the source can require reconciliation or a supported reverse-synchronization procedure. Powering the old server back on does not merge the new data. State how those transactions will be preserved before relying on rollback.
A rehearsal should test the recovery decision as well as the successful move. Include the time needed to restore service on the original environment.
Finish with a recoverable IBM i production environment
Review batch processing and interfaces after the first business cycle. Confirm backup completion and the software keys that apply to the production system. Remove temporary migration access and close out the old server only when the business accepts the move and retention requirements are met.
Plan the IBM i cutover with Midland · Return to migration planning · What affects migration duration?
Sources and compatibility checks
Technical guidance checked October 21, 2026. A hardware release mapping describes which releases can run; support coverage and software entitlement are separate checks.