How to choose ERP software: An 8-step guide and selection checklist

To choose ERP software effectively, organisations must look beyond feature checklists and vendor demonstrations. Successful selection requires a structured evaluation process that assesses functional fit, total cost of ownership (TCO), implementation risk, and long-term architectural flexibility (or "optionality”).

This guide provides a vendor-neutral, 8-step framework to help buying committees evaluate, shortlist, and select the right for their operational and strategic goals.

How to choose ERP software in eight steps

To choose ERP software that supports scalable, connected operations, follow an eight-step selection process: define outcomes, document requirements, select a deployment model, evaluate architectural optionality, shortlist via pass/fail gates, score finalists using a weighted model, validate through scripted scenarios, and model multi-year total cost of ownership.

1. Define outcomes and ERP requirements

Replacing a legacy system or adopting a new platform should never be treated as an end in itself. ERP selection must begin with clearly defined business outcomes and hard operational constraints.

Focus initial discovery on measurable improvements across core operations:

• Reducing month-end financial close timelines (e.g., from 10 days to 3 days).
• Eliminating manual spreadsheet reconciliations between financial management software and operational platforms.
• Lowering inventory variance and improving supply chain visibility.
• Reducing duplicate data entry across disparate systems.
• Improving time-to-billing for billable projects and services.

Capturing functional and non-functional requirements

Requirements must capture the "jobs to be done" across the entire organisation. Involve stakeholders from finance, operations, IT, procurement, and HR to build a prioritised matrix.

Every requirement should be tied to a clear business outcome and assigned an owner responsible for defining acceptance criteria:

Requirement	Business Outcome	Priority	Owner	Acceptance Criterion	Vendor Evidence Required
Automated Intercompany Reconciliations	Reduce month-end close by 2 days; eliminate manual FX adjustments	Critical	Head of Finance	System automatically nets and posts intercompany transactions daily across multi-currency entities	Scripted demonstration using company test data
Real-Time Inventory Tracking	Reduce stock variance to under 1%	Critical	Operations Director	Serial-number level tracking from receipt through production to dispatch	Live product demonstration
Automated Field Worker Scheduling	Increase daily billable utilisation by 12%	High	Operations/HR Lead	Dynamic route and shift optimisation based on worker skills and compliance rules	Reference customer verification
RESTful API Access	Lower long-term integration maintenance costs	Critical	IT Director	Full CRUD access to core entities with versioned API documentation	Public API documentation & developer portal review

 

Core ERP requirements checklist categories

When compiling your comprehensive ERP software requirements, ensure coverage across these key operational areas:

• Finance and accounting - General ledger, accounts payable/receivable, fixed assets, intercompany accounting, multi-currency consolidation, and tax compliance.
• Procurement and spend management - Requisitioning, purchase order automation, supplier management, and invoice matching.
• Inventory and supply chain - Warehouse management, serial/lot tracking, demand forecasting, and logistics integration.
• Projects and services - Project accounting, resource management, time and expense tracking, and milestone billing.
• Workforce and payroll dependencies - Time and attendance tracking, roster scheduling, integration with workforce management systems, and payroll export capabilities.
• Analytics and reporting - Role-based dashboards, ad-hoc query tools, self-service reporting, and real-time operational data feeds.
• Automation and AI - Automated workflow routing, anomaly detection, exception-based processing, and document parsing (OCR).
• Security and compliance - Role-based access control (RBAC), single sign-on (SSO), audit logging, GDPR compliance, and encryption at rest/in transit.
• Data and integration - Open APIs, webhooks, pre-built connectors, ETL capabilities, and bulk data import/export tools.

2. Choose between cloud, on-premise, and hybrid ERP

Choosing an ERP deployment architecture requires balancing cost, operational flexibility, IT capability, and regulatory control. There is no universally superior deployment model; the right architecture depends on your organisational context, existing infrastructure, and operational risk tolerance.

Architectural comparison

Factor	Cloud ERP (SaaS)	On-Premise ERP	Hybrid ERP
Cost Structure	Predictable OPEX (subscription fees); lower initial infrastructure cost.	Higher upfront CAPEX (servers, licences); ongoing hardware/facility maintenance.	Mixed OPEX/CAPEX; requires managing both cloud subscriptions and local hardware.
Release Cadence & Upgrades	Automatic, continuous vendor updates; all customers remain on the current version.	Manual, periodic major upgrades; often requires extensive regression testing.	Cloud modules update automatically; core elements update on managed schedules.
Scalability	Near-instant scaling of compute, storage, and additional user licences.	Requires hardware provisioning, network upgrades, and additional local infrastructure.	Cloud components scale rapidly; core capacity bound by local infrastructure limits.
Customisation	Configuration-driven; custom code typically restricted to extension frameworks.	Unlimited custom code potential, but deep modifications risk blocking future upgrades.	Highly customised core preserved local; cloud extensions handle new workflows.
Data Control & Residency	Provider manages security; data residency subject to cloud region availability.	Complete local control over data storage, physical access, and sovereign boundaries.	Sensitive operational data retained locally; non-sensitive data processed in cloud.
IT Burden	Provider handles infrastructure, patches, backups, and disaster recovery.	Internal IT team manages OS, database administration, backups, hardware, and network security.	IT manages local integration layer and core hardware alongside cloud vendor SLAs.
Remote Access	Native web/mobile access built-in without requiring complex VPN infrastructure.	Requires secure remote access layers (VPN, remote desktop services) to be maintained.	Native cloud interface for field users; secure gateway access for core systems.
Exit & Migration	Dependent on vendor data export tools, database access policies, and exit terms.	Full direct access to raw underlying database files and database schemas.	Direct access to local database; exported data schemas for cloud modules.

While cloud ERP offers rapid innovation cycles and reduced hardware overhead, cloud vs on-premise ERP decisions should not be made purely on assumed cost savings. On-premise or hybrid models remain highly relevant for organisations operating under strict data residency mandates, those with heavy legacy manufacturing equipment integrations, or those operating in environments with poor network connectivity. Hybrid models also serve as an effective interim step for staged digital modernisation.

3. Apply the ERP Optionality Test

A major risk in ERP procurement is vendor lock-in. Over time, rigid architectures, proprietary integration frameworks, and predatory licensing structures can severely constrain your business agility and inflate ongoing costs.

To mitigate this, buyers should evaluate platforms using the ERP Optionality Test. This proprietary framework measures how easily an organisation can modify, extend, scale down, or replace its ERP landscape without incurring catastrophic operational or financial penalties.

The 6 criteria of the ERP Optionality Test

Evaluate each prospective system across six criteria, assigning a score from 0 to 2:

• 0 = Unclear, restricted, or proprietary
• 1 = Partial capability, subject to additional cost or operational friction
• 2 = Fully documented, practical, standards-based, and contractually guaranteed

1. Modular adoption

Can individual functional modules (e.g., procurement, inventory, financials) be implemented, updated, or decommissioned independently without forcing a complete system overhaul?

• Score 0: Monolithic; modules cannot be licensed or operated independently.
• Score 1: Modules exist, but core dependencies require buying unused functional stacks.
• Score 2: Fully composable architecture with independent operational capabilities.

2. Documented APIs

Are comprehensive, standards-based API documentation and developer endpoints publicly available without premium tier surcharges?

• Score 0: Proprietary/undocumented integration tools; API access requires custom vendor work orders.
• Score 1: APIs available, but rate limits, payload caps, or access fees restrict practical use.
• Score 2: Complete RESTful/GraphQL coverage with clear versioning and no hidden fees.

3. Data portability

Can you extract your full historical raw data (including transactional logs and database schemas) on demand in open, machine-readable formats (e.g., SQL dump, CSV, JSON)?

• Score 0: Data export limited to basic front-end reports or restricted proprietary backups.
• Score 1: Data export available, but vendor charges heavy extraction or professional service fees.
• Score 2: Automated, full-schema bulk export tools included standard in the base licence contract.

4. Upgrade-safe integrations and customisations

Are extensions and integrations completely decoupled from the core application codebase using event hubs or open middleware?

• Score 0: Custom code directly alters core tables; updates routinely break customisations.
• Score 1: Low-code extensions exist, but major platform upgrades require manual regression testing.
• Score 2: Extensibility architecture guarantees 100% upgrade isolation and backward compatibility.

5. Licence flexibility

Does the commercial agreement allow annual reductions in user seat counts or module removals aligned with operational downturns or corporate restructuring?

• Score 0: Fixed floor contract locks in maximum seat counts with zero downward adjustment allowed.
• Score 1: Licence reduction permitted only at multi-year renewal windows with termination penalties.
• Score 2: Annual or periodic true-down rights included without penalty or fee reallocation.

6. Contractual exit terms and costs

Does the contract explicitly detail vendor responsibilities, transition assistance rates, data retention timelines, and deletion procedures upon contract termination?

• Score 0: Vague or missing exit clauses; vendor reserves right to charge arbitrary offboarding fees.
• Score 1: Exit terms present, but migration support assistance rates are un-capped or undefined.
• Score 2: Clear, contractually bound exit SLAs, fixed professional service rates, and data handover guarantees.

Evaluation threshold: A total score below 8 out of 12 represents a material vendor lock-in risk. While architectural optionality complements (rather than replaces) functional fit, scoring low here signals that long-term total cost of ownership will likely escalate significantly over time.

Evidence checklist for the Optionality Test

Do not rely on verbal vendor assurances during evaluation. Demand concrete documentation:

• Public or sandbox developer portal access to verify full API schemas and versioning rules.
• Written documentation detailing API call rate limits, throttling policies, and extra usage fees.
• A demonstration of standard, end-to-end bulk data extraction tools operating on real database tables.
• The vendor’s official release notes and deprecation policies for legacy features and APIs.
• Draft contractual clauses covering annual seat reduction rights, exit assistance SLAs, and data retention schedules.  

4. Compare ERP vendors with weighted selection criteria

To compare prospective platforms objectively, build a 100-point weighted evaluation scorecard. This prevents single high-performing areas (such as a polished visual interface) from masking critical deficiencies in data architecture or commercial terms.

The 100-Point Weighted Selection Scorecard

Evaluation Criterion	Weight Percentage	Vendor Score (1 to 5)	Weighted Score ((Score ÷ 5) × Weight)
1. Business & Process Fit	25%	[ 1–5 ]	[ % ]
2. Architecture, Security & APIs	15%	[ 1–5 ]	[ % ]
3. ERP Optionality Test	20%	[ 1–5 ]	[ % ]
4. TCO & Commercial Terms	15%	[ 1–5 ]	[ % ]
5. Implementation & Adoption Risk	15%	[ 1–5 ]	[ % ]
6. Vendor & Partner Capability	10%	[ 1–5 ]	[ % ]
Total Score	100%		[ % ]

Scoring methodology

Members of the cross-functional selection committee (finance, IT, operations, security, end users) should score each vendor independently on a 1 to 5 scale across all criteria:

• 1 = Fails to meet basic expectations
• 2 = Meets partial needs with major workarounds or custom code
• 3 = Meets core standard expectations
• 4 = Exceeds requirements with standard, out-of-the-box functionality
• 5 = Industry-leading capability with proven market benchmarks

Calculate the final category score using the formula:

Pass/fail non-negotiables

Points cannot offset critical compliance or functional failures. Non-negotiable elements, such as statutory tax compliance, mandatory industry security certifications (e.g., ISO27001), or strict data residency requirements, must act as pass/fail elimination gates. If a system fails a non-negotiable gate, it is eliminated immediately regardless of its overall point total.

5. Assess ERP vendors and implementation partners

Choosing an ERP software platform is only half the equation; you are also choosing an implementation partner who will configure, integrate, and deploy the application. Deficiencies in partner capability are a leading root cause of project delivery delays and budget overruns.

Vendor stability and product viability

When evaluating the software vendor directly, verify:

• Financial health - Evaluate balance sheet stability, revenue growth, and R&D investment levels to ensure long-term viability.
• Product roadmap - Review past release history against past roadmaps. Does the vendor consistently ship planned features on schedule?
• Security and availability SLAs - Demand historical uptime metrics (minimum 99.9% target) and review standard Service Level Agreements (SLAs), including credit policies for unplanned downtime.

Implementation partner assessment

If deployment is executed by a Systems Integrator (SI) or value-added reseller, evaluate:

• Named project team - Secure contractual commitments for the specific named consultants, solution architects, and project managers who will execute your build.
• Responsibility matrix (RACI) - Establish explicit boundaries for data migration, interface development, user acceptance testing (UAT), and system configuration.
• Subcontractor disclosure - Clarify whether any implementation components or custom code builds will be outsourced to offshore third parties.

Essential customer reference questions

When conducting reference calls with existing clients of prospective ERP vendors and partners, focus on operational execution rather than sales-led testimonials. Ask:

1. "Did the implementation team complete the deployment within the initial target timeline and budget? If overruns occurred, what were the primary root causes?"
2. "What unexpected software, infrastructure, or implementation costs arose during configuration and post-go-live hypercare?"
3. "How does the system perform during peak transactional loads (e.g., year-end processing, peak shipping windows)?"
4. "How responsive and knowledgeable is the tier-2 and tier-3 post-implementation technical support team when critical tickets are raised?"
5. "Knowing what you know today about system capabilities, partner quality, and vendor culture, would you select this platform and implementation partner again?"

6. Validate ERP systems through RFPs, demos, and proof of concept

To cut through sales presentations, structure your evaluation phase around rigorous Requests for Proposal (RFPs), scenario-based software demonstrations, and targeted Proof of Concept (POC) builds.

Standardising functional claims

In RFP documentation, ensure vendors categorise every functional claim explicitly:

[S] Standard out-of-the-box - Native function requiring no code or workflow configuration

[C] Configurable - Achieved via standard admin controls and workflow setup

[D] Custom development - Requires bespoke code, custom database tables, or APIs

[T] Third-party integration - Requires purchasing, licensing, and integrating an add-on

[R] On product roadmap - Not currently available; scheduled for future release

Elimination rule: Do not accept roadmap promises [R] as existing platform functionality. If a critical requirement relies on a roadmap item, make contract binding penalties contingent on delivery before your planned go-live date.

Scripted, scenario-led demonstrations

Do not permit vendors to show generic, pre-recorded product walk-throughs. Provide prospective vendors with real, anonymised operational data and demand they execute end-to-end, scripted business processes live:

• Procure-to-pay - Create a complex requisition with automated approval routing based on spending thresholds, convert to a purchase order, process partial receipt of goods, and perform an automated three-way invoice match.
• Order-to-cash - Enter a multi-line customer order involving back-ordered inventory, apply customer-specific volume discounting, trigger credit checks, generate picking lists, and issue an automated invoice.
• Month-end close - Run a multi-entity, multi-currency financial consolidation with automated intercompany elimination journal entries and draft key trial balances.
• Project-to-cash - Capture time and billable expenses against a fixed-fee milestone project, track utilisation against budget, generate milestone billing, and post revenue recognition entries.

Targeted Proof of Concept (POC)

For high-risk operational elements, mandate a practical proof of concept build prior to contract execution. A POC should be used to validate:

• Complex custom integrations with legacy proprietary software or specialised hardware.
• High-volume transaction processing speed under full production load stress.
• Critical automated workflows or complex regulatory reporting requirements.

Define clear, objective success criteria before commencing the POC, and involve operational end-users to score system usability directly.

7. Calculate total cost of ownership

The initial software licence or subscription fee typically represents less than 40% of the true financial investment required to deploy and maintain an enterprise system. Evaluating an ERP requires building a complete 5-to-7-year Total Cost of Ownership (TCO) financial model.

Complete 5-to-7-year TCO model structure

ERP total cost of ownership (TCO)
Year 0: Initial Implementation & Deployment • Software Licences / Subscriptions (Pre-go-live deployment tier) • Implementation Partner Professional Services & Configuration Fees • Data Cleaning, Transformation & Legacy Data Migration • Third-Party Middleware / Integration Connector Licences • Hardware, Infrastructure & Network Upgrades • Internal Resource Backfill, Change Management & Staff Training
Years 1–7: Recurring Operational Costs • Annual Software SaaS Subscriptions / Maintenance & Support Fees • Managed Services, Tier 2/3 Technical Support & Platform SLA Costs • Ancillary Storage, Bandwidth, Premium API Call Volume Fees • Ongoing Change Management, New Staff Onboarding & Periodic Retraining • Upgrades, Regression Testing & Custom Integration Maintenance
Contingency & Scaling Adjustments • Contractual Annual Licence Fee Escalation Caps (e.g. max 3–5% per annum) • User Seat / Operational Volume Scaling Assumptions (Growth & Contraction) • Eventual Data Extraction, Offboarding & Exit Transition Assistance Costs

Commercial and contractual terms to guard against

When reviewing commercial terms, watch for hidden cost escalation clauses:

• Uncapped renewal price increases - Ensure standard subscription renewals include explicit contractual fee increase caps (e.g., tied to CPI or capped at 3–5% annually).
• Arbitrary user tier boundaries - Watch for pricing models where adding a single user forces the entire account into a significantly higher subscription tier.
• Aggressive API or storage throttling - Review usage limits for database storage, file attachments, and API calls. Ensure overage rates are clearly defined and reasonable.
• Professional services rate cards - Secure fixed rate cards for vendor and partner consulting services that remain valid for at least 24 to 36 months post-implementation.

8. Confirm implementation strategy before signing

Implementation feasibility is a core component of ERP selection, not an operational detail to figure out after contracts are signed. Selecting an outstanding platform with an unworkable implementation methodology creates severe project risk.

Implementation methodologies

Implementation Strategy	Key Characteristics & Considerations
Phased Deployment	• Roll out by module, business unit, or geography • Lower risk profile; longer total duration • Requires temporary integration bridges
Pilot-Led	• Deploy to a representative business unit or site first • Validates build configuration in live production • Lessons learned refine rollouts across remaining units
Big Bang	• All core modules and business units cut over at once • Faster overall duration; highest operational risk • Demands extensive testing and business readiness

Resource allocation and change readiness

An ERP deployment requires significant time commitments from your top Subject Matter Experts (SMEs). Before finalising your timeline, confirm organisational readiness:

• Executive sponsorship - Is there a dedicated executive sponsor with clear authority to resolve cross-departmental scope disputes and approve necessary process changes?
• SME availability and backfill - Have key operational experts in finance, procurement, and logistics been relieved of 20–50% of their daily duties via formal backfill staffing?
• Data migration ownership - Is there explicit internal ownership assigned for scrubbing, formatting, deduplicating, and validating legacy data prior to system ingestion?
• Change management framework - Is there a structured change management programme covering internal communication, role-based training, and user adoption tracking?

Making the final decision

Common ERP selection mistakes to avoid

1. Selecting for current needs only - Choosing a platform that solves today's immediate issues without evaluating how its data architecture scales over 5–7 years.
2. Prioritising brand over fit - Selecting a recognised global vendor based on brand reputation rather than functional fit for your specific industry workflows.
3. Underestimating data migration - Treating data cleanup and transformation as a minor administrative task rather than a major, resource-intensive workstream.
4. Rushing the evaluation - Skipping scripted scenario demos or reference calls to meet an arbitrary procurement deadline.
5. Ignoring internal resource limits - Assuming existing staff can execute a complex ERP implementation alongside their full-time operational duties without backfill support.

Final selection checklist

Before signing software contracts or statement of work agreements, confirm that your selection committee has validated every item:

• All mandatory operational and compliance non-negotiables passed pass/fail evaluation gates.
• Scorecard evaluations completed independently by finance, IT, operations, and security stakeholders before final score aggregation.
• The platform achieved a score of 8/12 or higher on the ERP Optionality Test.
• Reference calls completed with 3 non-vendor-provided customer accounts of similar operational scale and complexity.
• All high-risk functional requirements, integrations, or throughput expectations validated via a live, scripted demonstration or physical Proof of Concept.
• A comprehensive 5-to-7-year TCO model completed, including all third-party software, implementation fees, internal backfill costs, and explicit renewal price caps.
• Contractual terms reviewed for clear exit assistance terms, explicit API rate limits, data extraction access rights, and true-down seat flexibility.
• Clear internal ownership assigned for executive sponsorship, project management, data migration, and operational change management.

How OneAdvanced supports connected, composable operations

Once you have established your selection criteria, evaluated architectural optionality, and defined your operational outcomes, you can assess how commercial ERP providers meet your framework.

OneAdvanced provides a modern, composable ERP platform engineered to support scalable, connected operations across medium to large UK businesses. Designed to eliminate data siloes and streamline complex operational workflows, the platform connects core functions across:

• Finance and spend management - Comprehensive financial management software providing multi-entity accounting, smart procurement, and real-time financial reporting.
• Workforce management: Integrated workforce management capabilities supporting shift scheduling, time and attendance tracking, and seamless payroll export workflows.
• Governance and risk: Embedded audit trails, role-based security controls, strategic risk management, and regulatory compliance frameworks built directly into the platform architecture.

Built on an open architecture with documented RESTful APIs, OneAdvanced allows organisations to modernise incrementally. By adopting modular capabilities at a pace aligned with operational readiness, businesses avoid the high risk and disruption of monolithic "big bang" system overhauls while maintaining the long-term flexibility defined in the ERP Optionality Test.

Next steps and selection tools

Ready to structure your ERP selection process? Take advantage of these next steps:

• Request a demonstration - Experience how our modular platform handles your real-world operational workflows with a scenario-led ERP demonstration.
• Discuss your requirements: Speak with our solution architects to review your specific technical architecture, integration endpoints, and ERP implementation strategy.

FAQs

How does ERP selection influence long-term business success?

Selecting the right ERP establishes a flexible digital foundation that connects operational data, automates repetitive processes, and improves decision-making speed. A well-chosen system scales alongside organisational growth.

What are the most critical technical considerations when selecting an ERP?

Beyond core functional fit, primary technical considerations include architectural optionality, API robustness and versioning, security certifications (e.g., ISO27001, SOC 2), database scalability, disaster recovery SLAs, deployment flexibility, and open data portability.

How long does the ERP selection process typically take?

For medium to large organisations, a thorough, risk-mitigated selection process takes between 3 to 6 months. This provides adequate time to document requirements, conduct scripted scenario demonstrations, execute proof-of-concept builds for high-risk requirements, calculate multi-year TCO models, and complete thorough commercial negotiations.

How long does ERP implementation typically take?

Implementation timelines depend heavily on deployment scope, system complexity, and architecture. Monolithic or heavy on-premise ERP typically requires 12 to 24 months due to extensive customisation, complex infrastructure setup, and high-risk cutover processes. Composable/cloud ERP can be deployed incrementally in phased iterations over 4 to 9 months.

Can ERP requirements evolve after system selection?

Yes. Business models, market conditions, and regulatory environments change over time. Successful organisations manage evolving requirements through a formal governance framework and by selecting a modular, composable ERP platform that allows new capabilities, third-party software integrations, and workflow updates to be introduced.