iSeries and IBM i Servers
If your team still says iSeries or AS400, the first job is translation. Then the real one: identify what the system actually is, protect the application running on it, and decide whether you are buying support or a project.
What You Need to Sort First
- iSeries is often legacy language, but the workload may still be mission-critical IBM i running on IBM Power hardware.
- The application and the IBM i release decide this, long before the machine type does. Printers and batch jobs usually decide the timeline.
- A hardware quote answers the easy half. The hard half is old ERP code and the custom integrations nobody has documented since the person who wrote them left.
- A useful partner explains all five options in plain language and tells you which one they would not sell you. That answer is worth more than the other four.
This Page Helps You With...
- iSeries refresh
- IBM i migration
- AS400 modernization
- ERP workload support
- High availability planning
What You Need to Know Before You Choose an iSeries or IBM i Server Option
Use these when the business depends on an IBM i workload and the naming is a mess. The goal is one clear conversation about what you have and what has to keep working.
Can the reseller assess my current iSeries or IBM i environment?
Start with what the business runs
The system matters because of the application, not the server name. Tell the reseller what it does for the business.
- ERP
- Warehouse
- Finance
- Manufacturing
- Order entry
- Reporting and EDI
- Custom RPG
That single answer changes the recommendation more than any spec you could give them.
Identify the actual system
iSeries and AS400 are useful search words. A quote needs facts.
- Machine type, model and serial number
- IBM i release
- Processor and memory
- Storage
- Backup method
- Attached devices that still matter
List the dependencies
These decide whether a plan survives contact with Monday morning.
- Printers, forms and labels
- EDI
- FTP jobs
- Mapped drives
- Terminal sessions
- Reports
- Vendor software
- Custom integrations
Write them down. Right now most of that list lives in one person's memory, and that is the actual risk.
Separate stable from risky
A stable IBM i environment may only need maintenance, backup review, or spare parts planning. A risky one may need a hardware refresh, hosted IBM i, high availability, or a controlled migration project.
Which IBM Power hardware supports my required IBM i release?
Match the operating system first
Do not start with the newest model. Start with the IBM i release the application can run on, then check which IBM Power hardware options support that release and the support window the business needs.
Licensing can change the real cost
The server price is rarely the deciding number.
- IBM i licensing
- Processor activations
- User counts
- Software maintenance
- Third-party tools
- Application licensing
Ask the reseller to state those assumptions before you compare quotes, because two quotes with different assumptions are not a comparison.
New, refurbished, and hosted are different decisions
New hardware, refurbished hardware, hosted IBM i and a temporary bridge are all valid answers. Which one fits depends on budget, timeline and how long the workload has to keep running. Your data center plans matter too, especially if there is a lease ending.
Plan for the next support window
A refresh should buy years, not fix this quarter. Ask how long each layer stays supportable.
- The hardware
- The IBM i release
- Maintenance coverage
- The backup plan
- The application stack
The shortest answer in that list is your real runway.
What application, backup, printer, and integration dependencies must be checked?
Application fit decides success
A technically correct server still fails the business if the application misbehaves. Review the software side before the change, not after.
- Custom code
- Old ERP versions
- Reports
- Job schedules
- Vendor software
Printers and forms are not side issues
Plenty of IBM i environments still lean on output nobody thinks about.
- Label printers
- Pre-printed forms
- Spool files
- Mapped output queues
- Device workflows
Ask who checks those before the work and who checks them after. A warehouse that cannot print labels is down, whatever the server says.
Backup has to be tested
A backup plan is only useful if restore has been tested. Ask where backups live, how restore works, how long recovery takes, and whether the reseller will test the recovery process before major changes.
Users need to test real work
Technical testing is not enough. Users have to confirm their own work before anyone calls the project done.
- Orders
- Reports and invoices
- Labels
- Approvals
- EDI
- Batch jobs
- The daily workflow end to end
Does the quote include migration and post-cutover support?
Separate hardware from project work
A server quote often excludes the entire project around it.
- Planning
- Backup review
- Data movement
- Application testing
- Downtime scheduling
- Rollback planning
- User support
- First-week stabilization
Ask line by line. Every item above has been the reason a cheap quote got expensive.
Cutover needs an owner
Someone has to own the final move, and the owner is different for each step.
- Who freezes changes
- Who moves the data
- Who checks the application
- Who tells the users
- Who decides it is ready for production
Name all five before the weekend, not during it.
Rollback should be written down
A controlled migration should explain what happens if the application fails, data does not match, users cannot work, or the downtime window runs long. A rollback plan is not pessimism, it is responsible planning.
The first week matters
The project is not finished when the system boots. Post-cutover support should cover the first real week.
- Monitoring
- Backups
- Performance
- User issues
- Printer output
- Job schedules
- Application exceptions