When most people hear “managed services,” they picture help desk tickets, network monitoring, printer support, and user account management. That is traditional IT managed services, a well-established category with hundreds of providers competing on price and response time.
ERP Managed Services is a different discipline entirely.
It is not about keeping the lights on. It is about keeping the business running on the application that drives it — the ERP system that controls purchasing, manufacturing, inventory, order management, and finance.
For organizations running their ERP on IBM i, that application layer is where decades of business logic, custom configuration, and institutional knowledge live.
Infor LX, BPCS, and other IBM i-hosted ERP systems are among the applications ERP Managed Services covers. The IBM i platform is the operating environment. The ERP is the business.
That distinction matters when you are evaluating providers. A traditional MSP and an ERP Managed Services provider are not competing for the same scope of work.
Before making any decision, clearly establish which layer each provider covers — and whether the provider you are speaking with actually operates at the ERP application level or defaults to infrastructure support, with ERP mentioned as an afterthought.
The First Question Is About Scope
While response times, pricing, and team size are important, you want to establish which layer your managed services provider covers.
For many providers serving IBM i shops, the focus is on the infrastructure layer — keeping the OS current, managing backups, and monitoring uptime.
For VIRTUTEM, the focus is the application layer: the RPG and CL code driving order-to-cash, the ERP configuration controlling MRP and manufacturing workflows, the Db2 for i queries feeding production and financial reporting, and the EDI environment connecting your ERP to your trading partners.
Infor LX and BPCS are examples of the ERP systems we support. Providers that operate at this layer can modify code, diagnose configuration issues, manage the ERP at the level where your business logic actually lives, and resolve EDI failures before they become missed ship windows — not just keep the server online.
The question to ask early: “Walk me through what you will and won’t touch in our ERP environment — not the OS, the application itself. And specifically, how do you handle EDI?”
If the answer covers restarts and monitoring but not code or configuration, you have your answer.
What to Ask Instead of “What Are Your Certifications?”
Unlike SAP, Oracle, or Salesforce, legacy ERP vendors such as Infor do not operate meaningful certification programs for their ERP applications. There is no Infor LX Certified Consultant credential to check. There is no BPCS certification exam. This is not a gap in the market — it reflects the nature of these systems.
Competence in Infor LX or BPCS is built through years of hands-on implementation, support, and customization work, not through a training course with a certificate at the end.
IBM does maintain certifications for the IBM i operating system platform itself — but those validate OS administration skills, not ERP application expertise.
An engineer certified to administer IBM i knows how to manage PTFs, configure backups, and monitor system performance. That is infrastructure work. Whether that same engineer can navigate twenty years of Infor LX configuration, diagnose a BPCS job stream failure, or modify RPG code without breaking downstream processes is an entirely different question — one no certification answers.
Because credentials do not answer the question, the burden of proof falls entirely on the provider. What you are looking for is demonstrated experience: a track record of active engagements, client references in your industry, and evidence that the provider’s team has worked inside environments like yours — not just IBM i generally, but the specific ERP running on it.
The questions that replace credential checks are direct.
How many ERP environments on IBM i is your team actively supporting right now? Can you provide references from clients running the same ERP application we use? How long has your team been working specifically with this ERP, rather than IBM i in general? What was the last major customization or configuration project your team completed, and can you describe what it involved?
References matter more than résumés in this evaluation. A provider who has supported five Infor LX environments over ten years and can connect you with those clients is more credible than one who lists IBM i credentials and describes general enterprise experience.
The work is specific. The proof should be too.
ERP Vendor Partnership Status
The closest thing to a formal credential in the ERP Managed Services space is whether the provider holds an endorsed partnership with the ERP vendor itself.
For Infor-based ERP systems on IBM i — LX, BPCS, PRMS — that means Infor Alliance Partner status. It is not a certification in the technical sense, but it is vendor recognition that carries real meaning: the ERP vendor has evaluated the provider’s expertise, track record, and client base, and has formally included them in its partner network.
Alliance Partner status matters for practical reasons beyond the badge. Infor Alliance Partners have access to the Infor Support Portal, which means they can raise support cases directly with Infor, access current PTFs and BMRs, and stay current on platform changes as they happen — rather than relying solely on publicly available documentation.
For a client running a production ERP on IBM i, that access can be the difference between a same-day resolution and a days-long escalation chain.
Beyond general Alliance Partner status, ask whether the provider has any exclusive or preferred designations.
Some ERP vendors recognize partners for specific product lines or geographies where their depth is exceptional. VIRTUTEM, for example, holds Infor Alliance Partner status and is Infor’s only designated business partner for PRMS services in North America — a designation that reflects depth, not simply enrollment.
That kind of specificity is what you are looking for: not a partner directory listing, but evidence that the vendor itself regards the provider as a go-to resource for the work you need done.
Also, ask about onboarding. A provider with genuine ERP Managed Services experience will describe a structured discovery process for understanding your environment: mapping active RPG programs and job streams, documenting existing configuration and customizations, and identifying dependencies between custom code and standard ERP modules.
That process exists because experienced providers know that every IBM i ERP environment is different, and the only way to support one reliably is to understand it specifically.
A provider who cannot describe that process, or who proposes to learn your environment reactively as issues arise, is not an ERP Managed Services provider. They are an IBM i generalist hoping the ERP does not surface anything complicated.
The question that replaces the credentials check: “How many active ERP environments on IBM i is your team supporting today, and can you connect us with clients running the same application?”
The SLA Terms That Actually Matter for IBM i
A 99.9% uptime SLA tells you the IBM i system will be available. It says nothing about whether the ERP running on it is well managed. System availability and application health are not the same measurement, and conflating them is one of the most common mistakes organizations make when structuring an ERP Managed Services agreement.
Four elements should be explicit in any ERP Managed Services agreement for a manufacturing or distribution company running its ERP on IBM i.
ERP Configuration Change Documentation
Every configuration change made to the ERP environment should be logged, documented, and accessible to the client on request.
Undocumented changes are how institutional knowledge gaps widen under a managed services engagement rather than close. Ask for a documented change log as a contractual deliverable.
Enhancement Delivery Timelines
If the provider is responsible for RPG development or Infor LX enhancements, the agreement should specify delivery timelines, escalation paths, and visibility into the backlog.
The SLA should name response windows, escalation criteria, and how outstanding enhancements are reported back to the client.
Job Stream Performance Thresholds
Available and operational are different measurements. A month-end batch job that takes three hours instead of forty minutes is a business problem, not just a system alert.
The SLA should cover monitoring of ERP batch job durations on IBM i and threshold-based alerting specific to your business workflows — MRP runs, month-end closes, overnight job streams, order processing cycles. IBM i is built for this kind of batch processing. The SLA should reflect what actually breaks your business, not just what generates a system alert.
User Support Response Windows
For manufacturers and distributors running their ERP on IBM i, a production issue at 6 AM on a Monday is not the same as a configuration question on a Thursday afternoon.
The agreement should define response windows by issue severity and explicitly cover ERP application support — not just system availability.
If the SLA only defines uptime, it is an infrastructure agreement, not an application services agreement.
EDI Transaction Integrity
For manufacturers and distributors on IBM i, EDI is not a peripheral system — it is the transaction layer connecting your ERP to every major customer, supplier, and logistics partner you work with. A failed 850 purchase order, an unacknowledged 856 ASN, or a mapping error on an 810 invoice does not generate a system alert. It generates a missed ship window, a chargeback, or a vendor compliance failure. The SLA should reflect that.
Four things should be explicit in the EDI scope of any ERP Managed Services agreement:
- which EDI translator the provider supports and who owns mapping changes
- how trading partner errors are detected, who investigates them, and what the response window is
- whether the provider manages VAN relationships directly or passes that responsibility back to the client
- what constitutes an EDI incident versus a VAN-side issue, and who owns the liaison work either way
Most IBM i managed services providers do not have dedicated EDI staff. They monitor the translator for failures but have no one who can diagnose a mapping error, resolve a trading partner rejection, or manage a VAN escalation. That gap routinely surfaces only when a problem occurs — at which point the client discovers that their MSP’s EDI coverage ends at the system log.
Ask directly: “If we have a trading partner rejection at 9 PM on a Thursday, who on your team handles it, and what is their EDI background?” The answer will tell you everything you need to know.
What ERP Downtime Actually Costs
For executives evaluating ERP Managed Services, the financial case is straightforward once the right numbers are on the table. When an MRP run fails overnight, and the production schedule is wrong at 6 AM, the cost is not a system alert — it is a production line running the wrong jobs, a warehouse pulling the wrong inventory, and a customer shipment that does not leave on time.
For a mid-size manufacturer, a single unplanned ERP outage or data integrity failure can generate tens of thousands of dollars in operational cost within hours.
Month-end close delays carry their own costs: finance teams working overtime, reporting cycles slipping, and executive decisions made on stale numbers.
The question for a CFO or COO is not whether ERP Managed Services is an expense — it is whether the cost of a specialist provider is higher or lower than the cost of one preventable failure per quarter. For most manufacturing and distribution operations running on IBM i, it is not a close comparison.
Four Questions That Separate Infor ERP Specialists from Generalists
1. “Walk me through how you handle Infor LX configuration changes. How are they documented, who approves them, and how does the client access that record?”
A specialist has a defined configuration management process: changes are logged when they are made, linked to a request or enhancement record, and accessible to the client on demand.
A generalist makes changes and moves on.
The difference becomes apparent when something breaks, and nobody can explain what changed or when.
VIRTUTEM maintains a configuration management log for every active managed services client. Every change — configuration update, enhancement deployment, PTF application, job stream modification — is recorded when it is made, linked to the originating request, and made available to the client on demand through a shared record. Clients do not need to ask what changed after a problem surfaces. The record exists before the problem occurs.
In one global manufacturing engagement, this governance structure helped reduce an open ticket backlog of 150+ items and an average backlog age of over 80 days to approximately 30 open tickets with an average age under 30 days, within months of engagement.
2. “We have undocumented RPG customizations that predate our current team. How do you approach understanding and supporting code you didn’t write?”
A specialist describes a structured discovery process — mapping active programs, documenting business logic, and identifying dependencies between customizations and standard Infor LX modules.
This is the onboarding work that separates a provider who can actually support your environment from one who is learning it at your expense.
VIRTUTEM’s onboarding process for a new managed services engagement begins with a structured environment discovery: cataloging active RPG and CL programs, mapping job stream dependencies, documenting BPCS and Infor LX configuration, and identifying any customizations that sit outside the standard application.
That work occurs before VIRTUTEM assumes any production responsibility. The outcome is a documented baseline that belongs to the client — not knowledge that lives only in a consultant’s head.
A generalist says they’ll figure it out as issues arise.
3. “If our environment has documentation gaps like undocumented RPG customizations, job streams without runbooks, how do you handle onboarding?”
A specialist describes a structured environment audit: job scheduler configuration, user authority profiles, active RPG programs, ASP utilization, and a process for building out the missing components.
A generalist assumes documentation exists.
When VIRTUTEM encounters an environment with documentation gaps — which is the case for the majority of IBM i ERP environments that have been running for more than a decade — the onboarding audit builds the missing documentation as the first deliverable.
Job scheduler configuration, user authority profiles, active program inventory, ASP utilization, and undocumented customization logic are all captured and handed back to the client in a written environment baseline. That baseline does not disappear if the engagement ever ends. It belongs to the client.
4. “Our EDI runs through our IBM i and integrates directly with our ERP. Walk me through how you support that.”
A specialist can describe exactly which translators their team has worked with, who on their staff handles mapping changes, and how they manage trading partner escalations when the problem is on the VAN side rather than the IBM i side. They treat EDI as an integrated part of the ERP environment — because on IBM i, it is.
A generalist monitors the translator for failures and escalates everything else back to the client.
VIRTUTEM has a dedicated in-house EDI team that supports the full EDI stack on IBM i. The team works with Gentran, TrustedLink, IBM Sterling Commerce, and other IBM i-based translators, and is translator-agnostic — if a client’s environment runs something else, the team learns it rather than recommending a replacement.
All mapping work is handled in-house. VIRTUTEM does not replace VANs, but manages the full implementation of the VAN relationship and acts as the direct liaison when issues arise on the VAN side — so clients have one point of contact for an EDI problem regardless of where in the stack it originates.
One timing note that belongs in any honest evaluation: this decision has a natural deadline that most organizations only recognize in retrospect.
The right time to begin an ERP Managed Services engagement is while you still have an internal resource who knows the environment — someone who can participate in the onboarding, validate the documentation, and transfer institutional knowledge in an orderly way. Once that person retires or resigns, that window closes. The evaluation that happens after the departure is always more expensive, more urgent, and more likely to end in a compromised scope because there is no longer time to do it properly.
If retirement is on the horizon in the next 12-24 months, this evaluation should be underway now.
Start Your Evaluation with VIRTUTEM’s Complimentary ERP Environment Assessment
VIRTUTEM’s ERP Architects have delivered ERP Managed Services to manufacturing and distribution companies running Infor LX and BPCS across North America for over three decades.
As an Infor Alliance Partner and Infor’s only designated business partner for PRMS services in North America — a distinction recognized by IT Jungle as making VIRTUTEM a “longtime Infor partner” — the team brings application-layer depth that generalist IBM i providers cannot replicate.
The ERP Environment Assessment is a structured review of your IBM i ERP configuration, active job streams, RPG customization inventory, and current support coverage. It is delivered as a written report that identifies gaps, risks, and the specific scope of what an ERP Managed Services engagement would need to cover in your environment. There is no obligation and no sales pitch — just a clear picture of where your environment stands and what it needs.
Request your complimentary ERP Environment Assessment online or call us directly to describe your environment and what you need covered.
Frequently Asked Questions
What is the difference between ERP Managed Services and traditional managed services?
Traditional managed services cover infrastructure: hardware, network, OS patching, backups, and help desk.
ERP Managed Services covers the business application running on that infrastructure — the ERP configuration, custom code, job streams, and business logic that determine whether your operations actually run correctly.
For organizations on IBM i, these are distinct disciplines, often handled by specialists.
Does an ERP Managed Services provider need to be an Infor Alliance Partner?
Not legally required, but practically significant. Infor Alliance Partners have direct access to the Infor Support Portal, current PTFs and BMRs, and an escalation path to Infor engineering. A provider without that access is working from public documentation and community knowledge alone.
For a production ERP environment, the difference in resolution speed during a critical issue can be substantial.
Can we use an ERP Managed Services provider alongside our existing IBM i infrastructure provider?
Yes. Infrastructure and application layer services operate at different scopes and are routinely separated across providers. The key requirement is that each provider has a clearly defined scope, both parties know who owns which layer, and there is a named escalation path when an issue touches both.
VIRTUTEM works alongside infrastructure providers regularly and can help define that boundary as part of the onboarding process.
How long does it take to transition to an ERP Managed Services provider?
It depends on the environment’s complexity and whether an internal resource is available to participate in onboarding.
For a well-documented environment with an engaged internal resource, a structured onboarding can be completed in 4-6 weeks. For environments with significant documentation gaps or undocumented customizations, the discovery phase typically lasts 8-12 weeks.
Starting while an internal resource is still available always shortens the timeline and improves the outcome.
What ERP systems does VIRTUTEM support on IBM i?
VIRTUTEM’s primary ERP Managed Services focus is Infor LX, Infor BPCS, and Infor PRMS — three of the most widely deployed IBM i-based ERP systems in North American manufacturing and distribution.
VIRTUTEM is an Infor Alliance Partner and Infor’s only designated North American business partner for PRMS. The team also has experience with other IBM i-hosted ERP environments and can assess supportability on a case-by-case basis.