By Pentagon 2000 Software, in collaboration with Monica Badra, Founder of Aero NextGen

Most aviation and MRO companies that fail at their ERP projects do not fail at choosing the right ERP because they made a careless decision. They fail because they asked the wrong questions at the start, trusted a demo that did not resemble their workflow, or never saw their actual requirements run in the standard application and instead relied on future development or sales promises that could not meet the need. They chose a system that worked fine at other companies, ones that are less complex or less competitive, in a completely different part of the industry.

By the time the problems appear, the team has adapted around the gaps, finance is reconciling manually, and the compliance team is maintaining a parallel spreadsheet because the system cannot be trusted. Time, effort, and considerable business impact from late go-to-market have already occurred. Nobody wants to admit the selection was a mistake, so the workarounds and expensive custom development become standard practice. Until they break.

Unfortunately this is not a rare situation. It is probably the most common one.

The Real Problem Is Not the Software

Before getting into what to look for, it is worth saying something that does not appear in most ERP selection guides: the system is rarely the only problem.

A parts distributor running a system originally built for line maintenance will always struggle, no matter how good that system is in its own category. An MRO that chose a platform because it was the cheapest option at the time, with limited business logic and industry know-how incorporated in the standard application, or because a peer company recommended it without having remotely similar operations, will spend years and a fortune trying to make something fit that was never designed for them.

The conversation about which ERP to choose needs to start much earlier, at the point where a company is honest about what it actually does and where it wants to be, how it makes money, and where its current process genuinely breaks down.

What Are the Main Problems We See in the Industry

At Pentagon 2000, we talk to companies of all sizes across MRO, parts distribution, fleet operators, and manufacturers in the aerospace and defense industry. They come to us at different stages. Many are on their first serious ERP evaluation. Many have outgrown their current ERP and are ready to move on to a better suited platform.

A few patterns come up consistently.

Running financials and accounting separately from the ERP

A surprising number of small aviation companies run their ERP and their financials as two separate systems, connected by a sync that half works. QuickBooks on one side, the operational system on the other. Purchase orders update in one place but not the other. Vendor changes in the ERP do not reflect back on the sales order. Financials transfer incorrectly. The team learns which data to trust and which to verify manually. This is not a minor inconvenience. It means the financial picture is always slightly wrong, and nobody can be sure by how much.

The deeper problem is the separation itself. When accounting lives outside the system that runs your parts and your work orders, every movement has to be reconciled by hand. Pentagon 2000 was built the other way around. Each part movement and each document is reflected immediately in the respective ledger and financial statement, so the operational picture and the financial picture are always the same picture.

The exchange tracking gap

For companies dealing in cores, rotables, and exchange transactions, this is where a lot of systems fall apart. The workflow looks simple in a demo, but the real version involves multiple condition codes, timing differences between physical and financial movement, and compliance documentation that needs to tie back to the original transaction. Systems that were not built with aviation exchange in mind tend to handle this with workarounds that accumulate over time until they become unmanageable.

The scaling problem

A system that works for 15 users in one country starts to show cracks when the company adds a second office, starts trading in multiple currencies, or brings on a customer base that requires different documentation standards. Multi-currency is a good example. It sounds like a checkbox feature, but the way exchange rates are applied across purchasing, sales, and financial reporting varies significantly between systems, and the difference matters a lot when a company is billing in dollars, paying suppliers in euros, and reporting to ownership in a third currency. Scale also means structure. As companies grow through acquisition or by opening offices in new countries, they need to run multiple companies, divisions, or departments, either on a single database or across several. A system that cannot model that structure forces the business to bolt on separate instances that never quite reconcile.

The legacy system

There are still companies in this industry running server-based systems built decades ago, held together by institutional knowledge. The hesitation to move is understandable. Migrations are disruptive, and the fear of choosing something worse is real. But these systems are rigid. They were never built to flex as the business changes, so every new requirement turns into a project. The longer this continues, the more expensive the eventual move becomes, because the data gets messier, the integrations multiply, and the people who understand the current system retire.

A related version of this is the homegrown system that worked well at a certain size and then quietly stopped keeping up as the number of employees increased. It still runs. It still does most of what it was built to do. But it cannot connect to anything modern, it has no roadmap, and the institutional knowledge required to maintain it is concentrated in one or two people. These companies tend to stay longer than they should because the system is familiar and the risk of moving feels higher than the cost of staying. At some point that calculation flips, usually when a key person leaves or a compliance requirement arrives that the system simply cannot meet.

There is a broader point here. An aviation company or service provider should be spending its energy on aviation, on maintenance, on parts, and on its customers, not on building and maintaining software. Software that has to be developed and patched in-house is a distraction from the actual business, and it rarely keeps pace with it.

Traceability that holds up to an audit

In aviation, traceability is not a feature. It is the difference between a part you can sell and a part you cannot. Many systems track parts well enough for day to day operations but cannot produce complete history on demand. When an auditor or a customer asks for the full chain on a serialized component, the answer should take seconds, not a week of digging through files. Pentagon 2000 was built for 100% traceability, where every part, every document, and every transaction is linked and retrievable.

Data and system security

Security is no longer a back office concern. In the current era of cyber attacks, the ERP holds the most sensitive operational and financial data a company has, which makes it a target. Buyers should ask how a system protects that data, where it is hosted, and what controls are in place. For publicly traded companies, this extends to compliance frameworks such as SOC and Sarbanes-Oxley (SOX), which set real requirements for how financial data is handled and audited. At the same time, the platform should be moving forward rather than standing still, with genuine investment in AI, automation, robotics, and predictive capabilities, instead of using security as an excuse to avoid modernizing.

What the Evaluation Process Looks Like From the Outside

The following section reflects the perspective of Aero NextGen, an aviation technology advisory and solution brokerage that helps MRO and aviation companies identify, evaluate, and shortlist software solutions through independent advisory services and its Solution Finder platform.

One of the most consistent mistakes we see during ERP evaluations is that companies define their requirements based on what their current system cannot do, rather than what their future operations actually need. That sounds like the same thing. It is not.

A company that is frustrated with broken exchange tracking will go into an evaluation looking for better exchange tracking. They will find it, select the system, and eighteen months later discover that the reporting does not support their compliance workflow, or that the RFQ process requires a level of manual handling they did not anticipate. The new system is better in the one area they measured. It has gaps they never thought to ask about.

The evaluation process needs to map the full workflow, not just the pain points.That means involving the people who actually use the system day to day, not just the decision-makers who approved the last one.

A few things that rarely appear on standard RFQ checklists but consistently determine whether an implementation succeeds:

How does the vendor handle your industry-specific compliance requirements? Not in general terms. Ask them to walk through a specific certification workflow. Ask what happens when a document is missing. Ask how the system enforces, not just tracks, compliance steps.

What does the implementation actually involve? Who does the data migration? What is the typical timeline for a company of your size and complexity? Ask for references from companies in a similar segment, not their largest or most recognizable customers.

What happens after go-live? Support structures vary enormously. Some vendors are responsive during the sales process and difficult to reach afterward. Ask specifically about training, ongoing support, and how product updates are communicated and managed.

What does your system landscape look like, and does this ERP connect to it? If you are using QuickBooks, a parts marketplace, a shipping integration, or any other tool that your team depends on, the ERP needs to connect to those systems reliably, not theoretically.

—-

The Questions Worth Asking Before You Sign Anything

Whether you are evaluating for the first time or coming out of a system that did not work, these are the questions that tend to reveal the most.

Can you show me this business process using my data? Not sample data. Not a generic demo environment. If the vendor cannot or will not run a demo using a scenario you describe from your actual operations, that tells you something.

How does your system handle the specific thing that broke in your last ERP? If your exchange process was a mess, ask them to walk through an exchange transaction in detail. If your QuickBooks or ILS sync was unreliable, ask exactly how the integration works and what happens when it fails.

Who else in my segment uses this system? A system built primarily for airline operators may not be the right fit for a parts broker. A system designed for large MROs may be overbuilt and impractical for a 60-person operation. Ask for references in your specific category.

How much custom development will this actually require? This is one of the most revealing questions you can ask, because the answer is usually buried in the implementation quote. A system that needs heavy customization to fit aviation workflows is telling you it was not built for aviation in the first place. The richer the standard application, the less custom development you need, and the less you pay for it over the life of the system. Ask the vendor what percentage of your requirements the standard product covers out of the box, and what specifically would have to be built.

How long will deployment take, and what does it cost to keep running? A long deployment is not a sign of a serious system. It is often a sign of a system that does not fit. Ask how long a project like yours typically takes from kickoff to go-live. Ask whether you will need to hire dedicated ERP specialists to keep it running, and whether every change down the line means paying outside integrators. An ERP project does not need to be complicated or expensive to be done well. The total cost of ownership, deployment, maintenance, and the people required to support it, matters as much as the license.

Can you choose between on-premises and cloud, or are you locked into one? In this industry, many companies cannot move to the cloud, whether for security, regulatory, or infrastructure reasons. Yet a growing number of vendors offer cloud only. That is a problem if your operation needs to stay on-premises, or if you simply want the option to decide for yourself rather than have it decided for you. The ability to run the same system on-premises or in the cloud, and to move between them as your needs change, is worth more than it looks like on a feature list.

What Good Actually Looks Like

A well-chosen ERP is not one that has every feature. It is one where the core workflows your team uses every day are handled correctly, the financial data can be trusted, unsafe or improvised interfaces do not jeopardize the integrity of the data, and the system does not require a layer of manual intervention to function.

It should handle your compliance documentation without your team maintaining a parallel process. It should connect to the tools you already use without requiring constant reconciliation. It should be able to grow with you when you add users, offices, or currencies, without becoming a different system that needs to be replaced again.

It should not be overly expensive, neither the licensing nor the software lifecycle management, and the ERP project itself should not be too complicated.

The selection process takes time. But the time spent asking harder questions before you sign is a fraction of the time you will spend managing a system that was the wrong fit.

About

Pentagon 2000 Software has been building aviation-specific ERP solutions since 1986, serving MRO providers, parts distributors, operators, manufacturers, and aerospace and defense companies, with more than 1,000 licensed customers worldwide. Pentagon UPSTREAM is our cloud-hosted, browser-native ERP, built for aviation companies that need the depth of an industry-specific system with the flexibility of a modern cloud platform. If you are currently evaluating options, request a demo or get in touch to talk through your specific requirements. Contact Guy Danon, Global Head of Sales & Marketing, at Pentagon 2000 Software, for any questions.

For independent ERP evaluation, advisory support, and software matching resources, visit Aero NextGen or try the Solution Finder.