AS400 Software Intelligence

Start by separating users by risk and workflow instead of forcing one MFA pattern onto everyone at once. Interactive admins, remote access users, occasional approvers, and service accounts usually need different controls if the rollout is going to hold up in production.

A practical sequence starts with the smallest, highest-risk group first, typically QSECURITY administrators and anyone with *ALLOBJ or *SECADM special authority, since a compromised admin credential is the fastest path to a full system breach. Pilot MFA there, work out the recovery process for lost tokens or failed logins, then expand to remote access users connecting over VPN before touching the broader interactive user base. Service accounts and batch jobs need a separate conversation entirely, since most MFA products cannot prompt a job scheduler or an unattended FTP connection for a one-time code, so those accounts typically need compensating controls like IP restriction, exit point monitoring, and tighter object authority instead of MFA itself.

Buyers should press vendors on exactly how the product hooks the 5250 sign-on screen, since some tools intercept the standard sign-on API cleanly while others require a modified sign-on program or a proxy that adds a second network hop. Ask what happens when the MFA service is unreachable: a poorly designed integration can lock every user out of a green-screen session during an outage, which is worse than no MFA at all. It is also worth asking how the vendor handles emergency break-glass access for QSECOFR, since that account needs a documented exception path that is still logged and reviewed, not a permanent bypass that quietly undoes the whole project.

The right restore-testing cadence depends on business criticality, audit pressure, and how much change the environment sees. The important point is that restore testing should be scheduled, documented, and repeatable instead of assumed.

A workable pattern for many shops is a full restore test to an isolated LPAR or a separate partition quarterly, with lighter spot checks, restoring a single critical library or IFS directory, done monthly in between. The isolated partition matters because testing a restore against production risks collisions with live objects and job names, and it does not prove anything about disaster recovery if the "test" only ever happens on the system that is supposed to fail. Buyers should ask whether the software can automate provisioning a test environment, or at least script the restore sequence so it does not consume a full day of an administrator's time each quarter.

Documentation is the part that gets skipped under deadline pressure, and it is exactly what an auditor or cyber insurance underwriter will ask to see. A useful restore test report captures what was restored, how long it took, whether the application came up cleanly, and who verified the result, ideally exported automatically rather than typed up after the fact from memory. It is also worth testing restores under a degraded scenario occasionally, missing a volume, a corrupted save file, a partial journal chain, since a clean test every time proves less than a test that occasionally forces the team to work through a real problem.

Backup protects recoverability from a good copy after something goes wrong. High availability protects continuity by keeping a ready path for failover before the outage becomes prolonged.

The clearest way to see the difference is to walk through two failure scenarios side by side. A disk subsystem fails and the LPAR goes down: with HA in place, replicated data on a standby system lets the team swap roles and have the business running again in minutes, while backup alone means restoring from the last save point and losing everything since that save ran. Now consider a different scenario: a batch job runs wild and corrupts a set of files at 2 AM. HA replicates that corruption to the standby system almost immediately, since it is designed to mirror changes quickly, so the only real fix is restoring from a backup taken before the corruption occurred. Neither technology covers both cases well on its own.

This is why mature IBM i environments run both rather than choosing one, and why buyers should resist a vendor pitch that frames HA as a replacement for backup or vice versa. The practical question during evaluation is how the two work together: does the HA platform interfere with or complicate backup scheduling on the source or target system, can backups be taken from the standby node to reduce load on production, and does the vendor offer both capabilities under one roof or does the shop need to integrate two separate products and support contracts.

Start with the conditions most likely to cause operational interruption ... failed jobs, queue issues, performance pressure, storage thresholds, replication health if HA exists, and security events that need fast review. Monitoring strategy should begin with business impact, not dashboard completeness.

Failed and stalled jobs deserve top priority because they are frequently the first visible symptom of a deeper problem, whether that is a full auxiliary storage pool, a locked file, or a downstream system that stopped responding. Storage thresholds come next: an IBM i system that runs low on disk can degrade gracefully at first and then fail abruptly, so alerting well before critical thresholds gives operations time to act rather than react. Queue depth and subsystem stress often signal the same underlying issue from a different angle, and catching them early can prevent a slow degradation from becoming a full outage.

Security events belong in the first-alert tier even for organizations that have not historically treated monitoring and security as connected disciplines. Unusual profile activity, failed sign-on patterns, or changes to authorization lists and exit point programs can indicate either a genuine security event or a misconfigured application, and both deserve fast review. Buyers should ask whether the monitoring platform can correlate related conditions, such as a storage threshold breach coinciding with a batch job failure, since related alerts arriving separately often get triaged as unrelated noise instead of the single incident they actually represent.

That depends on business process fit, customization debt, integration pressure, staffing, and how much disruption the organization can tolerate. Many IBM i teams should evaluate phased modernization or extension before assuming replacement is the only path, but the answer is never purely technical.

Customization debt is worth quantifying rather than estimating. Buyers should get a real count of modified programs, custom objects, and workarounds built around the base ERP, since a system with a handful of well-documented customizations is a very different modernization case than one with thousands of undocumented changes accumulated over twenty years. Integration pressure works similarly: counting the actual number of interfaces, files, and downstream systems that depend on the ERP shows whether replacement risk is contained or sprawling before anyone commits to a timeline.

Staffing is often the deciding factor that gets underweighted. If the team supporting RPG or COBOL customizations is shrinking, nearing retirement, or already stretched thin, that shifts the calculus toward a path that reduces dependency on scarce in-house programming skill, even if the current system still technically works. Disruption tolerance should be evaluated against the business calendar too, a retailer cannot absorb an ERP cutover during peak season, and timing constraints can rule out certain modernization or replacement paths regardless of their technical merit.

None of these factors should be assessed in isolation. A structured risk review that scores customization debt, integration count, staffing risk, and disruption tolerance together gives leadership a defensible basis for the decision instead of a choice driven by the loudest complaint in the building.