A fit-gap analysis is a structured comparison between what your business needs and what a specific ERP system actually does. For each requirement, it records whether the software meets it as standard, meets it with configuration, needs an extension, or is better handled by changing the process. You need one whenever you are about to commit money and time to a system: during selection, before a replacement, ahead of a major upgrade, or when an implementation is going off track.
Done well, the fit-gap register becomes the single source of truth for scope. It tells the finance team what the project will cost to build and maintain, tells operations which processes will change, and tells IT what it will be supporting for years afterward. Done poorly, it is a spreadsheet of “yes” answers collected from a sales demo, and the real gaps surface during user acceptance testing, when they are most expensive to fix.
What a fit-gap analysis is (and isn’t)
A fit-gap analysis is requirement-level and system-specific. It asks, line by line, “How does this ERP handle this requirement?” The output is a register of decisions, not a report of opinions.
It is often confused with a general gap analysis. A business gap analysis compares your current state to a desired future state, usually at the level of capabilities or performance, and it does not need a software product to exist. A fit-gap analysis comes later and is narrower: it takes the future-state requirements and tests them against one or more candidate systems.
| Gap analysis | Fit-gap analysis | |
|---|---|---|
| Question asked | Where are we versus where we want to be? | How well does this system meet our requirements? |
| Level of detail | Capabilities, outcomes | Individual requirements and scenarios |
| Needs a candidate system | No | Yes |
| Typical output | Improvement roadmap | Fit-gap register with resolutions and effort |
It is also not a vendor RFP response. Vendors will answer “yes” to most requirements because most things are possible with enough development. The analysis has to establish how each requirement is met and what that costs.
When to run one
System selection. Run a fit-gap on each shortlisted system. Comparing registers side by side shows which platform leaves you with fewer and cheaper gaps, which is more useful than a feature checklist.
Replacement of a legacy or custom system. Long-running in-house systems often encode years of workarounds and undocumented rules. A fit-gap forces those rules into the open so you can decide which are genuine requirements and which are habits.
Major upgrade or cloud migration. Moving between versions, or from on-premises to cloud, can remove customizations you relied on. Re-run the analysis on your existing extensions to see which are now standard and which must be rebuilt.
Implementation rescue. When a project is stalled, a fit-gap resets scope. It separates what is truly required for go-live from what has crept in, and it gives the steering committee a basis for hard decisions.
Inputs you need first
A fit-gap is only as good as what goes into it. Before any walkthrough, prepare three things.
As-is process maps
Document how work flows today for each process area in scope: procure-to-pay, order-to-cash, record-to-report, plan-to-produce, hire-to-retire, and so on. Include handoffs, approvals, reports, and the spreadsheets people use outside the current system. Those spreadsheets often reveal the real requirements.
Documented requirements
Turn the process maps and stakeholder interviews into specific, testable requirements. “The system must support approvals” is not testable. “Purchase orders above a defined amount route to the department head, then to the CFO, with delegation during leave” is. Tag each requirement with a priority using MoSCoW (Must, Should, Could, Won’t) and note whether it is driven by regulation, such as ZATCA e-invoicing and VAT obligations, or by internal preference.
Candidate systems and environments
Have access to a working environment for each system you are assessing, ideally configured with your chart of accounts, a sample of your items and customers, and your organizational structure. Assessing against slides or a generic demo company will overstate fit.
The five fit categories
Every requirement should land in exactly one category. Keeping the definitions strict is what makes the register comparable across systems and process areas.
1. Standard fit
The system meets the requirement out of the box, with no setup beyond normal master data. Standard fit carries the lowest cost and lowest upgrade risk.
2. Configuration
The requirement is met by setting parameters, workflows, templates, or security roles that the vendor supports without code. Configuration survives upgrades in most cases, but it still needs to be designed, documented, and tested.
3. Extension or customization
The requirement needs new code, a custom report, an integration, or a third-party add-on. This is where cost, testing effort, and long-term maintenance accumulate. Distinguish between extensions built on supported frameworks and modifications to core logic; the latter carry much higher upgrade risk.
4. Process change
The business agrees to adopt the system’s standard way of working instead. This is often the best answer, but it is an organizational decision, not a technical one, and it needs an owner who will manage the change with the affected teams.
5. Out of scope or workaround
The requirement will not be met in the ERP for this phase. It may be handled manually, in another system, or deferred. Record the reason and the interim workaround so nobody is surprised at go-live.
A fit-gap register template
The register is the working document. Keep it in a shared workbook or project tool with version history so every decision is traceable. The columns below are a practical starting point; the rows are generic illustrations, not recommendations for any particular system.
| ID | Process area | Requirement | Priority (MoSCoW) | Fit category | Proposed resolution | Effort | Owner | Decision |
|---|---|---|---|---|---|---|---|---|
| P2P-014 | Procure-to-pay | Three-way matching of purchase order, goods receipt and vendor invoice, with tolerance by amount | Must | Configuration | Enable matching policy; set price and quantity tolerances per vendor group | Low | AP lead | Approved |
| O2C-007 | Order-to-cash | Arabic/English bilingual tax invoice meeting ZATCA e-invoicing requirements | Must | Extension | Localization add-on plus bilingual invoice layout; validate with tax advisor | Medium | Finance manager | Approved |
| P2P-021 | Procure-to-pay | Approval workflow by amount with delegation during leave | Must | Configuration | Build approval hierarchy with amount thresholds and delegation rules | Low | Procurement head | Approved |
| INV-032 | Inventory | Custom weekly stock report formatted like the current spreadsheet | Could | Process change | Adopt standard inventory aging report and saved views | None | Warehouse manager | Pending |
Useful additional columns include the source of the requirement (interview, regulation, policy), the test scenario reference, the date of the decision, and a link to the design document for anything classified as an extension.
Running it step by step
- Confirm scope. Agree on the process areas, legal entities, sites, and integrations included. Freeze the requirement list for this round so the analysis does not chase a moving target.
- Write your own scenarios. Convert requirements into end-to-end scripts that use your real document types, approval paths, and edge cases, such as partial deliveries, credit notes, or multi-currency payments. Do not rely on vendor demo scripts, which are designed to show strengths.
- Run scripted walkthroughs. Have the vendor or implementation partner execute each scenario live in the environment while your process owners watch and ask questions. Record what was shown, not what was promised.
- Classify each requirement. Assign one fit category per requirement, agreed between your process owner and the solution architect. Where there is disagreement, note both views and escalate rather than defaulting to “fit.”
- Estimate effort. For configuration and extension items, estimate build, test, and ongoing maintenance effort. Use relative sizes if precise estimates are not yet possible, but be consistent.
- Prioritize. Combine MoSCoW priority with effort. High-priority, low-effort items go first; low-priority, high-effort gaps are the first candidates for process change or deferral.
- Sign off. Walk the steering committee through the register, focusing on extensions and process changes. Capture formal approval for each decision so the scope baseline is clear before design begins.
Deciding: customize or change the process
This is the decision that most shapes total cost of ownership. Test each gap against four questions.
Is it a genuine competitive differentiator? If the way you quote, schedule, or serve customers is a real reason they choose you, protecting it with an extension can be justified. If the process is simply how things have always been done, adopt the standard.
Is it required by regulation or contract? Tax, e-invoicing, statutory reporting, and customer contractual obligations are not optional. If the system does not meet them natively, an extension or certified add-on is usually the right answer.
What does it cost to build and maintain? Include design, development, testing, documentation, and the effort to support it every year afterward. A modest build cost can hide a large maintenance burden.
What is the upgrade impact? Extensions on supported frameworks usually carry forward with manageable retesting. Modifications to core logic can block or complicate every future upgrade, especially on cloud platforms with frequent release cycles.
If a gap is not differentiating, not regulatory, and costly to maintain, changing the process is almost always the better choice.
Common mistakes
- Starting without process maps. Without an as-is baseline, requirements are guesses, and the register reflects opinions rather than how the business works.
- Accepting “yes” without seeing it. A requirement is not a fit until it has been demonstrated with your scenario.
- Blurring configuration and customization. Calling code “configuration” hides cost and upgrade risk from decision-makers.
- Leaving process owners out. IT cannot decide on its own that finance will change how it closes the month.
- No ownership or sign-off. Decisions without a named owner are reopened later, usually during testing.
- Treating the register as a one-off. It should be maintained through design, build, and testing as the scope baseline.
Frequently asked questions
How long does an ERP fit-gap analysis take?
It depends on the number of process areas, entities, and candidate systems. A focused analysis on one system for a single company takes considerably less time than a multi-entity comparison of several platforms. The key driver is how ready your process maps and requirements are before walkthroughs start.
Who should be involved?
Process owners from each area in scope, a solution architect for each candidate system, someone from finance to weigh cost, IT for integration and support implications, and a project lead who owns the register. An executive sponsor should chair sign-off.
Can the ERP vendor run the fit-gap for us?
They can contribute, and their product knowledge is valuable. However, a vendor or reseller has an interest in the outcome. A vendor-neutral facilitator, or at least your own team owning the scenarios and classifications, keeps the results balanced.
Is there a standard fit-gap analysis template?
There is no single industry standard, but most effective templates share the same core: a unique ID, process area, testable requirement, priority, fit category, resolution, effort, owner, and decision. The table above is a practical starting point you can adapt.
What happens after the fit-gap analysis?
The approved register feeds solution design, effort estimates, and the implementation plan. Extensions get functional specifications, process changes get change management plans, and each requirement links to test scripts for user acceptance testing.
Getting an independent fit-gap
AIMLTS is a vendor-neutral consultancy based in Jeddah. We run process mapping, business process re-engineering, and fit-gap analysis before recommending any system, and we implement Dynamics 365, Odoo, SAP, and Oracle or build custom ERP when that is the better fit. Learn more about our Business Process Consulting, explore ERP Solutions and ERP Implementation, or book a discovery call to discuss your requirements.