IFS Maintenix (MXCORE) Implementation Guide for IFS Cloud

What Maintenix means inside an IFS Cloud architecture

IFS Maintenix, identified in the documentation as MXCORE, is an aviation maintenance component that licensed customers can install during the IFS Cloud deployment process. In a co-deployed model, it sits alongside IFS Cloud rather than floating off as a loosely related external tool.

That matters because Maintenix brings its own application schema and reporting schema, both of which must be installed on the same Oracle server as the IFSApps database schema. The deployment also introduces separate middle-tier containers for the Maintenix Application Server and the Report Server.

Where Maintenix fits functionally

Maintenix is positioned to work with two major IFS Cloud areas:

• Maintenance Execution
• Allowable Configuration

Those integrations are not cosmetic. Installation scripts enable data synchronization between the co-located schemas, and a meaningful portion of the project effort is really about controlling how those data flows, permissions, and handoffs behave after go-live.

The deployment reality: database first, then containers, then integration

A practical Maintenix rollout starts with understanding the sequence. The IFS installer handles the IFSApps database schema, the IFS Cloud application, the Maintenix application, and the Maintenix reporting application. But the Maintenix and Jasper reporting schemas are installed manually.

That manual work includes Oracle connection properties, SYS and SYSTEM credentials, datapump import settings, database identifiers, and execution of cleanup scripts for both the Maintenix and Jasper users. It is not the kind of deployment step you want to improvise during a cutover window.

Critical database and Oracle considerations

• Maintenix and Jasper schemas must be installed on the same Oracle server as IFSApps
• Oracle privileges such as DBMS_LOCK, DBMS_SCHEDULER, DBMS_XA, and selected transaction dictionary views must be granted through the installation sequence
• The installation creates users and grants UTL_FILE execution rights as part of the setup
• Co-deployed schema synchronization is configured through the co-deployed.properties step

This is one of the strongest signals that Maintenix is infrastructure-heavy. Teams need database discipline, not just application admin knowledge.

Container planning matters more than it looks

In Kubernetes-based deployments, Maintenix introduces dedicated containers such as ifsmaintenix-appserver and ifsmaintenix-reportserver. On top of that, the required IFS Cloud platform container set changes depending on whether the customer is only using basic operations plus Maintenix, or also using mobile maintenance capabilities.

Once mobile maintenance enters the picture, the dependency surface gets wider: notification services, native server components, integration services, signing services, remote assistance, and supporting file services all begin to matter. That is exactly why infrastructure scoping needs to happen early, not after environment build has already started.

Maintenance Execution is really an operating model, not just a module

When IFS Cloud Maintenance Execution is deployed with Maintenix as the primary Maintenance and Engineering system, the implementation team has to think far beyond one role or one screen. Administrators, planners, supervisors, line technicians, mobile technicians, maintenance controllers, project managers, and customer-facing roles all have their own setup requirements.

That setup includes user enablement, mobile app rollout, lobbies, document attachments, LiDAR media, digital signatures, remote assistance, external file storage, API users, tooling behavior, skill certificates, role-based visibility, sign-off permissions, and communication monitoring. In other words, the deployment is as much about operational governance as it is about technology.

Allowable Configuration is where process discipline really shows

Allowable Configuration adds another layer of complexity because it depends on Maintenix-managed data being exported, migrated, governed, and republished correctly.

• Users need migration-job access for the MIG_AC job family
• Configuration data is exported from Maintenix as CSV and then migrated into ATCM
• Restrictions may need to be temporarily relaxed only in tightly controlled cases
• Teams must avoid active unpublished change sources during migration to prevent inconsistency

That workflow tells you something important: the integration model assumes disciplined master-data control. If governance is weak, Allowable Configuration becomes risky quickly.

IFS Connect and routing rules are easy to underestimate

For Allowable Configuration integration with Maintenix, IFS Connect needs to be configured correctly. In co-deployed environments, routing addresses point to Maintenix REST endpoints and use token-based authentication with the IFS_Connect client secret. In cloud-to-on-premise scenarios, the routing addresses instead rely on the Maintenix integration user’s credentials.

Routing rules also have to be enabled and disabled in the right combinations depending on the topology. That is the kind of thing that often gets missed in handover documentation, then resurfaces later as a stubborn interface problem.

Post-installation is not optional cleanup

After Maintenix is installed, the job is not finished. Post-installation work includes enabling IAM clients, migrating maintenance data where relevant, and then configuring the components that actually rely on Maintenix, especially Maintenance Execution and Allowable Configuration.

There is also a long tail of operating details: cross-application navigation, publish permissions, inventory reservation rights, alerts, work-package completion controls, inbox and outbox integrity checks, hard-stop overrides, document access templates, time zone setup, and event-driven notifications. These are the details that decide whether the solution is stable in production or merely installed.

The practical takeaway

Maintenix inside IFS Cloud is best treated as a coordinated aviation platform deployment, not as a bolt-on product. The database, Kubernetes containers, security, routing rules, migration jobs, user roles, and post-installation controls all have to line up. When they do, the result is powerful. When they do not, the failure mode is not just inconvenience — it is operational confusion in a highly controlled maintenance environment.

Planning a Maintenix and IFS Cloud rollout?

If your team needs help structuring Maintenix architecture, installation sequencing, integration setup, or post-go-live stabilization, we can help turn the documentation into a workable delivery plan.