IBM i Software FAQ

Backup is about recovering from a good copy after something goes wrong. High availability is about keeping downtime very low by maintaining a ready continuity path before failure happens.

Many IBM i teams need both. Backup protects recovery. HA protects continuity tolerance.

Start by mapping access paths and user groups. Interactive admins, line-of-business users, remote access workflows, and service accounts rarely need the exact same treatment.

The strongest MFA rollouts phase by access risk and operational fit instead of forcing every workflow into one pattern on day one.

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.

That depends on business process fit, customization debt, integration pressure, staffing, and how much disruption the organization can tolerate.

Many teams should evaluate phased modernization before assuming replacement is the only path, but the answer is never purely technical.

Yes. API and integration projects often create one of the most practical first modernization wins because they connect IBM i systems to newer workflows without forcing a full replacement project.

The key is choosing a bounded use case with clear business value.

The right 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.

Untested backups create a dangerous illusion of safety.

Start with the actual gap. If the main need is product selection and licensing guidance, a reseller-style partner may fit. If architecture or project design is unclear, assessment-led consulting may fit better. If the team lacks day-to-day operating capacity, managed support may be the real requirement.

That is exactly why discovery partner profiles matter before buyer conversations get rushed.

Not always. The right answer depends on recovery objectives, current secondary site posture, connectivity, governance, and cost tolerance.

Cloud-based DR can be useful, but it should be judged against recovery design requirements instead of being treated as an automatic upgrade.

Usually when dependencies, exception handling, cross-system coordination, or operational visibility become too complex for manual tracking. The tipping point often appears when overnight workflow reliability starts depending on one or two people who know the sequence from memory.

Documentation support, internal search, alert triage assistance, reporting summarization, and support workflow improvement are usually safer starting points than autonomous operational control.

AI is most useful when it reduces friction around existing expertise instead of pretending to replace that expertise.

Start with one operational pain point that has clear volume and clear cost, such as accounts payable, HR records, or shipping paperwork, instead of trying to digitize every paper process at once.

That scope makes the project easier to justify and gives the team a visible win before a larger rollout is considered.

That depends on how often trading partner requirements change and how much ongoing mapping work the internal team can realistically own. Frequent partner onboarding or mapping changes usually favor managed support.

Stable, well-documented trading partner relationships can often stay in-house without much risk.

Yes, in most cases. Barcode and mobile workflow tools usually connect to existing ERP inventory and order transactions rather than requiring a full platform replacement.

The more important question is whether the integration is real time or batch, since that affects how much the new workflow actually improves accuracy and speed.

Often both, but process comes first. If intake paths and escalation rules are not clearly defined, a new tool will just formalize the confusion instead of fixing it.

Map how issues are reported and escalated today before comparing platforms, then choose software that supports that design.

It depends on the goal. Administrators and developers usually need query, performance, and development tooling, while analysts and business users typically need reporting and simplified data access.

Buyers should define the primary audience before comparing platforms, since tools built for one group rarely satisfy the other.

Most organizations get better results from a dedicated CRM platform that integrates with IBM i data rather than trying to build CRM functionality natively. The key is making sure that integration is real, not just planned.

Buyers should test the integration with real account and order data before committing, since a CRM that cannot reliably sync with core IBM i systems creates duplicate work instead of reducing it.

It depends on how well the current ERP's financial module fits reporting, audit, and close requirements. Organizations with straightforward finance needs often do fine inside the ERP, while those with heavier compliance or multi-entity reporting sometimes need a dedicated platform.

The decision should follow documented close and reporting pain points, not a general preference for fewer systems.

Often yes. BRMS is a strong policy and media control layer, but it does not natively provide cloud offsite automation, immutable ransomware-proof retention, or cross-platform reporting.

Many IBM i shops keep BRMS in place and add third-party software specifically to close those gaps rather than replacing it outright.

Most environments end up needing both. Tape-integrated software still provides the offline, tamper-resistant copy that ransomware recovery depends on, while cloud-native platforms simplify offsite automation and retention management.

The stronger evaluation question is whether one platform can orchestrate both natively, rather than picking a single media type in isolation.