Mainframe and AS400 Front End Modernization

Keep the core, replace the screens

Companies that run on an IBM mainframe or an IBM i system, still widely called the AS400, rarely have a problem with the core. The COBOL or RPG programs process orders, policies, claims or inventory reliably, and Db2 holds data that has been correct for decades. The pain is at the edges: 3270 and 5250 green screens that take months for new hires to learn, no access from phones or tablets, customers who have to call because nothing is exposed online, and other systems that receive data through nightly file transfers. Tepia focuses on those edges.

Replacing the entire host is a multiyear program with real risk, because the business rules inside those programs are often documented nowhere else. A front end modernization delivers visible improvement in months while leaving the proven logic where it is. It also builds the API layer you would need anyway if you later decide to move the core.

Ways to reach host programs and data

Tepia picks the access method per transaction, based on how the program was written and how often it will be called:

Tepia typically combines two or three of these. Direct SQL for reads plus program calls for updates covers most IBM i projects, because updates then run through the same validation the green screen uses.

Designing for people who know the green screen

Experienced users of 5250 and 3270 screens are fast. They type ahead, use function keys without looking and move through order entry quicker than most web forms allow. Tepia keeps that speed by supporting keyboard shortcuts, tab order that follows the old field sequence, and type ahead lookups on customer and item numbers. Power users should never feel the new screen slowed them down.

New users get the bigger gain. A process spread across six screens, each with cryptic field labels and error codes, becomes one form with plain language labels, inline help and host error messages translated into instructions. Mobile apps go further for staff away from a terminal: a warehouse picker scans a barcode, a field rep checks stock and order history before a visit, and both write back through the same API the office uses. Our enterprise mobile app development page covers that side.

Protecting the host while the front end changes

A mainframe or IBM i system has finite capacity and strict batch windows, and a chatty web app can disrupt both. Tepia designs the API layer to cache reference data, combine small requests, and queue updates during nightly processing. Each call carries a correlation ID so a slow transaction can be traced from the browser to the host job.

• Host user profiles and object authority remain the final word on what each user can do.
• Updates use commitment control or transaction boundaries so a failure never leaves half a record.
• Testing runs against a separate test library or partition with production like data, never the live system.
• Every change made through the new front end is logged with user, time and before and after values.

Tepia follows SOC 2 aligned logging and access practices, which helps when internal audit reviews a new path into the system of record. See our middleware development work for the integration layer itself.

How Tepia approaches mainframe and AS400 front end modernization

Tepia applies its six phases transaction by transaction, with a US based project manager coordinating your host team, business users and our engineers.

1. Discovery: screen recordings of real users, a map of the programs, files and transactions behind each screen, and a review of current file transfers. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as a customer service rep changing a ship to address on an open order.
2. Design: a design questionnaire, moodboards, a style guide and wireframes that merge related screens, tested with both veteran and new users.
3. Development and Testing: the API layer first, then screens released on an Alpha and Beta schedule, with test plans comparing results against green screen transactions and load tests during batch windows.
4. Training: side by side sessions showing the old screen and the new one for each task.
5. Launch: screens switched by department, green screen access kept as a fallback, and support reps on the floor during the first weeks.
6. Support: issue resolution, bug tracking and new screens or APIs as more transactions move to the modern front end.

Typically Discovery runs 1 to 3 months, development and QA 2 to 6 months for the first set of screens, and launch about a month. See our process.

When to move off the host entirely

A modern front end and API layer often satisfy the business for years. Some companies eventually go further, moving read heavy functions such as reporting and customer lookups to a cloud database fed by change data capture, then rewriting individual programs as services. The API layer makes that possible because callers no longer care where the logic runs.

Full replacement makes sense when hardware or licensing renewals force a decision, when the RPG or COBOL skills you depend on are leaving, or when the data model itself blocks new products. Tepia can plan that path in stages. Read legacy system modernization and cloud migration for legacy applications, then contact Tepia to walk through your screens.

Frequently asked questions