iSeries and IBM i Servers
If your team still says iSeries, AS400, or IBM i, the first job is translation. You need someone who can identify the current system, protect the business application, explain the IBM Power options, and help you decide whether this is support, refresh, hosting, high availability, or migration work.
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 right answer depends on the application, IBM i release, machine type, storage, backup, printers, users, and support window.
- A hardware quote is not enough if the business depends on old ERP code, reports, EDI, forms, batch jobs, or custom integrations.
- A useful partner should explain support, refresh, hosted IBM i, high availability, and migration options in plain language.
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 questions when the business depends on an IBM i workload and the naming is messy. The goal is to turn AS400, iSeries, IBM i, and IBM Power into one clear conversation about what you have, what has to keep working, and what option reduces risk.
Can the reseller assess my current iSeries or IBM i environment?
Start with what the business runs
The system is important because of the application, not because of the server name. Tell the reseller what the system does for the business: ERP, warehouse, finance, manufacturing, order entry, reporting, EDI, custom RPG, or another daily workload.
Identify the actual system
iSeries and AS400 are useful search terms, but the quote needs the machine type, model, serial number, IBM i release, processor, memory, storage, backup method, and any attached devices that still matter.
List the dependencies
Printers, forms, labels, EDI, FTP jobs, mapped drives, terminal sessions, reports, vendor software, and custom integrations can decide whether a support or migration plan works. Do not let those details stay in someone's memory.
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
IBM i licensing, processor activations, users, software maintenance, third-party tools, and application licensing can change the real cost of a server option. Ask the reseller to explain those assumptions before comparing quotes.
New, refurbished, and hosted are different decisions
A new IBM Power server, refurbished hardware, hosted IBM i, or temporary bridge system can all be valid options. The best fit depends on budget, timeline, support risk, data center plans, and how long the workload must keep running.
Plan for the next support window
A refresh should buy time, not just solve today's capacity issue. Ask how long the recommended hardware, IBM i release, maintenance coverage, backup plan, and application stack are expected to remain supportable.
What application, backup, printer, and integration dependencies must be checked?
Application fit decides success
The server can be technically correct and still fail the business if the application does not behave correctly. Custom code, old ERP versions, reports, job schedules, and vendor software need to be reviewed before the change.
Printers and forms are not side issues
Many IBM i environments still depend on label printers, forms, spool files, mapped output queues, or device workflows that are easy to overlook. Ask who checks those before and after the work.
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 should confirm orders, reports, invoices, labels, approvals, EDI, batch jobs, and daily workflows before the project is considered complete.
Does the quote include migration and post-cutover support?
Separate hardware from project work
A server quote may not include planning, backup review, data movement, application testing, downtime scheduling, rollback planning, user support, or first-week stabilization. Ask what is included line by line.
Cutover needs an owner
Someone needs to own the final move: who freezes changes, who moves data, who checks the application, who communicates with users, and who decides whether the system is ready for production.
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
Post-cutover support should cover monitoring, backups, performance, user issues, printer output, job schedules, and application exceptions. The project is not finished the moment the new system boots.