Choosing Software

An ERP implementation is not a software rollout. It's a decision to run finance, inventory, and often manufacturing or HR on one shared data model, all at once, on a system nobody on staff has used yet. Choosing the platform is its own decision, scored against clear evaluation criteria. This guide starts after signature: the decisions and phases that decide whether the project lands on time, on budget, and gets used.

Why ERP implementations fail

The failure pattern is more specific than "ERP is hard," which is good news: most of it is preventable during planning.

Panorama Consulting's 2026 ERP Report, a survey of 170 organizations run between January 2025 and January 2026, found a median project timeline of 9 months, with more than a quarter of projects over budget and almost a quarter over schedule. The most common cause of a budget overrun wasn't buyer scope creep, it was an unexpected need for additional technology: a fit gap that should have surfaced during selection but only got caught once the project was underway. The most common cause of a schedule overrun was organizational resistance: delayed sign-offs and pushback on standardizing a shared chart of accounts or approval flow.

The pattern holds at a larger scale too, with a caveat. A 2012 McKinsey and Oxford Saïd Business School study, Delivering large-scale IT projects on time, on budget, and on value, examined more than 5,400 large IT projects with budgets over $15 million and found they ran 45% over budget and 7% over schedule, delivering 56% less value than promised. That's not ERP-specific, and most ERP projects are nowhere near $15 million, but the mechanism, a fit gap found too late, is the same one.

Six things reliably drive that pattern:

Customizing around a process instead of fixing it. A workaround built for an old system limitation gets faithfully rebuilt, because nobody asked if the process was worth keeping.

Data that was never clean. Duplicate vendors, dead SKUs, and inconsistent naming accumulate unnoticed for years, and the cleanup gets compressed into a few frantic weeks before cutover.

A go-live date set by finance, not by readiness. Fiscal year-end is a real constraint, but it isn't a substitute for a testing sign-off, and hitting an arbitrary date ships known defects into production.

No single accountable owner. When configuration decisions get made by committee, definitions drift and nobody has standing to say no to the eleventh custom field.

Underestimating change management. The software usually works; the organization's willingness to standardize how it works is the harder, chronically under-resourced problem.

Treating the systems integrator as the owner. A partner can build integrations and migrate data, but can't own your chart of accounts or process redesign, and left alone will optimize for their statement of work, not your adoption.

What to decide before you configure anything

Most expensive mistakes happen in the first few weeks, when people start configuring before anyone has agreed what the system is for. Settle these on paper first.

Lock the chart of accounts and entity structure first. Every module, report, and integration depends on it, and changing it after go-live means re-running historical comparisons and re-training everyone who reads a report.

Decide which processes bend to the software, and which get configured to match yours. Standard configuration survives upgrades; anything kept exactly as-is becomes a customization, and both carry ongoing cost.

Pick the cutover model before configuring anything downstream of it. A parallel run, a hard cutover, or a phased go-live each imply different data cutoff dates, and choosing it late means redoing the data plan.

Name a single owner for each master data domain. Customer, vendor, and item masters each need one person who defines a valid record, or "clean data" is nobody's job during the busiest phase of the project.

Draw the integration boundary in writing. List every system the ERP talks to and which system is the record of truth for each shared field. The software integration requirements checklist covers this in full.

Define what "done" means for phase one. Write the reports, modules, and entities that go live first, and what's deliberately deferred. If it doesn't fit one page, it's the whole project wearing a phase-one label.

Decision	Question to resolve first	Who decides
Chart of accounts and entity structure	Reflects today's reporting, or where the business is headed?	Finance lead, CFO sign-off
Process vs. customization	Genuinely differentiated, or just "how we've always done it"?	Process owner, sponsor as tiebreaker
Cutover model	Parallel run, hard cutover, or phased?	Steering committee
Master data ownership	Who defines a valid record, who resolves a duplicate?	One named owner per domain
Integration boundary	Which system is the source of truth per shared field?	IT lead
Definition of "done" for phase one	What's in scope, and explicitly deferred?	Project sponsor, in writing

Phase one should hold to one chart of accounts, core finance plus the single module you can't run without, and two or three reports that run the business today. Push subsidiaries, the full module suite, custom code, and multi-entity rollout to phase two on purpose, not by accident.

Still choosing a platform? Work through how to choose ERP software and the ERP evaluation criteria checklist first. This guide assumes the contract is signed.

A step-by-step ERP implementation plan

Panorama's 2026 data puts the median project at 9 months, in a survey with a median organization revenue of $200.5 million, skewed toward mid-market and larger implementations. Smaller, single-entity projects commonly run 3 to 6 months; large, multi-country rollouts commonly run 12 to 18. Treat every duration below as indicative, not a quote.

Phase 1: Discovery and process mapping

Map the processes the ERP has to support, not the ones the org chart implies, with the people who actually do the work.

Phase 2: Project governance and team structure

Name the sponsor, the steering committee, and one internal project lead who isn't also doing their old job, with a decision-escalation path in writing.

Phase 3: Data audit and cleansing

Pull the real state of your master data before you plan the migration. This phase routinely runs longer than expected, because nobody looked closely at the data in years.

Phase 4: Configuration and the customization budget

Build the phase-one scope as configuration first. Every requirement configuration can't meet goes on a priced customization list, reviewed before it's built.

Phase 5: Integration build

Build to the integration boundary defined earlier, including what happens when two systems disagree, since integrations are often the last thing tested and the first to break at go-live.

Phase 6: Testing, UAT, and a parallel run

Run structured UAT against real scenarios, and where the cutover model calls for it, a parallel run processing real transactions in both systems. This is the phase most likely to get compressed when the schedule slips, and the one that most directly prevents a bad go-live.

Phase 7: Training, cutover, and go-live

Train on the configured system with real data, not a generic demo. Freeze the old system, load reconciled opening balances, and go live on the agreed date, not an aspirational one.

Phase 8: Hypercare and the first post-go-live close

Staff dedicated support for the first several weeks, not a normal ticket queue, and budget extra hands for the first month-end close run entirely in the new system.

Phase	Owner	Duration (indicative)	Output
1. Discovery and process mapping	Process owners, project lead	2 to 6 weeks	Current-state processes, documented
2. Governance and team structure	Project sponsor	1 to 2 weeks	Steering committee, escalation path
3. Data audit and cleansing	Data domain owners	3 to 8 weeks, often longer	Cleansed master data, dead-record list
4. Configuration and customization budget	Partner or admin	4 to 12 weeks	Configured scope, priced customization list
5. Integration build	IT lead, partner	3 to 10 weeks, parallel with Phase 4	Working integrations at the boundary
6. Testing, UAT, parallel run	Process owners, project lead	3 to 6 weeks	Signed-off tests, reconciled output
7. Training, cutover, go-live	Project lead, department leads	1 to 3 weeks	Trained users, live system
8. Hypercare and first close	Project lead, partner	4 to 8 weeks	Stabilized system, first period close

Implementation approaches at a glance

The rollout model shapes the plan above more than any other choice, and it belongs in evaluation, not after signature.

Approach	How it works	Best for	Main risk
Big bang	All modules and entities cut over on one date	Single-entity orgs with clean, documented processes	One bad cutover disrupts the entire business at once
Phased by module	Finance goes live first, then inventory or HR	Tolerating old and new systems side by side	Data flows between both systems mid-project, doubling integration work
Phased by entity or site	One entity or location goes live as a pilot, others follow	Multi-site businesses proving the model once first	The pilot entity absorbs a disproportionate share of the pain
Hybrid	Core finance and a pilot entity go big bang, other sites phase in after	Multinational orgs balancing speed and risk	The "temporary" hybrid state can quietly become permanent

Per Panorama's 2026 data, more than a quarter of multi-entity ERP projects now use this hybrid pattern, the single most common approach for multi-entity organizations.

Data migration: the part that actually breaks go-live

Data migration gets treated as a technical task handed to the systems integrator. It's really a business decision about what the new system needs to know on day one, and it deserves its own plan.

Decide what migrates and what gets archived. Moving everything "just in case" is expensive, and it's what makes a new system slow and cluttered on day one.

Data category	Migrate	Archive (read-only)	Special handling
Open transactions	Open AR/AP, open POs, open sales orders, active inventory	Closed and paid transactions past retention policy	Opening balances load fully reconciled, not as one lump entry
Master data	Active customers, vendors, items, employees, chart of accounts	Inactive records, known duplicates	Deduplicate before load; a vendor imported twice means two payment histories
Transaction history	Current fiscal year detail, for audit continuity	Prior years beyond retention requirement	Keep the legacy system read-only, don't default to "migrate everything"
Manufacturing data	Current bills of materials and routings	Discontinued SKUs, obsolete routings	Validate against current engineering records
Work in progress	Open projects and work orders	Completed projects	Decide explicitly: finish old-system work, or migrate mid-stream

Reconciliation is the gate, not a formality. Before cutover, every migrated balance, aging, and trial balance has to tie back to the legacy system to the cent, signed off by finance, not just the team that moved the data. A mismatch found after go-live is far more expensive to trace than one caught the week before. Migrating accounting software specifically, rather than a full ERP? The accounting software migration guide covers the same discipline in more depth.

How to decide: a decision framework

If your situation is...	Then do this
Single entity, one country, under 100 employees	Target a 3 to 6 month rollout: self-implement or vendor onboarding, big bang or phased by module
Multiple entities or currencies now, or planned within two years	Build the multi-entity data model on day one; retrofitting it later is close to re-implementation
Manufacturing or distribution with real inventory complexity	Prioritize native MRP or warehouse functionality; phase inventory as its own go-live
No named internal project owner, none planned	Stop and fix that first; the single most common thread behind the failures above
Migrating off years of undocumented customization	Budget extra discovery time to reverse-engineer what the old customizations do first
A tight date driven by fiscal year-end or a parent mandate	Cut scope, not testing or the parallel run; a smaller phase one beats a rushed full one
Still unsure you need a full ERP yet	Revisit when to move off free or lighter tools first
No experience running a change this size	Bring in a partner for governance and change management, even if an admin handles configuration

Cost: what to expect

License cost is the number everyone asks about first, and it's usually the smaller one. Implementation, migration, integration, and internal time nobody budgets actually determine whether the project lands on budget.

What's genuinely published, and what isn't. Most ERP vendors keep pricing behind a sales call. Two vendors often assumed quote-based actually publish list prices.

Vendor	Published price	Billing
Microsoft Dynamics 365 Business Central	Essentials $80/user/month, Premium $110/user/month, Team Members $8/user/month	Per user, paid yearly
Odoo	One App Free at $0 (one app, unlimited users); Standard and Custom are priced per user, but the figure personalizes by region and first-year discount and didn't resolve consistently across fetches	Per user per month
Oracle NetSuite	Quote-based, no public list price	n/a
SAP Business One	Quote-based, no public list price	n/a
Sage Intacct	Quote-based, no public list price	n/a
Acumatica	Quote-based, priced by application and resource consumption, not per seat	n/a
Epicor, Infor	Quote-based, no public list price	n/a

Implementation cost is what actually moves the budget, and there's no single clean ratio to cite for it. Panorama's 2026 report tracks project duration and overrun causes, not a published implementation-to-license multiple, so treat any ratio you read elsewhere as a planning bracket, not a citation. As a working range, partner fees for a mid-market implementation commonly land between one and three times the first year's license cost, depending on configuration versus custom build. Get three fixed-scope quotes before anchoring on any single number.

What drives the bill up	Why it inflates the quote
Customization instead of configuration	A future upgrade cost, not only an implementation-time one
Migrating from multiple legacy sources	Each extra source system multiplies mapping and cleansing work
Integration count and complexity	Often quoted separately; a base fee usually assumes a clean, unintegrated core
Entities and currencies in phase one	Multi-entity consolidation is genuinely harder to configure and test
Change management and training depth	Often the first line cut, and the one whose absence shows as poor adoption later
Internal staff backfill	Hours your team isn't doing its day job rarely appear on the invoice, but they're real

Budget the internal cost the same way: a project lead at roughly half their time, a data owner per domain during audit and testing, and hours from every department lead who signs off. None of that appears on the partner's invoice. For the multi-year picture including support and upgrades, see the software total cost of ownership guide, and use the SaaS vendor evaluation scorecard to structure the contract.

Still comparing licence cost: the best NetSuite alternatives, the best Odoo alternatives, and Odoo vs. Sage Intacct vs. NetSuite.

Frequently asked questions

How long does an ERP implementation actually take?

Panorama's 2026 data puts the median at 9 months, skewed toward mid-market and larger organizations. A smaller, single-entity company can go live in 3 to 6 months; large, multi-entity, multi-country deployments commonly run 12 to 18.

How much does implementation cost compared to the license?

There's no single authoritative published ratio. As a working range, mid-market implementation and partner fees commonly land between one and three times the first year's license cost. Get fixed-scope quotes from at least three partners rather than trusting a rule of thumb.

Should we go big-bang or phased?

Big bang suits smaller, single-entity organizations with clean processes. Phased suits organizations that can run two systems side by side and want to de-risk each stage. A hybrid, big-bang for core finance and a pilot entity with other sites phased in after, is now the most common pattern among multi-entity organizations.

What's the single biggest predictor of an ERP project going well?

A named, accountable owner who isn't the implementation partner, plus a go-live date set by testing readiness rather than a fiscal deadline. Every other failure pattern above gets caught when someone internal has the standing to catch it.

How much of our old data should we actually migrate?

Migrate open transactions, active master data, and the current fiscal year's detail. Archive the rest read-only, and reconcile every migrated balance against the legacy system before cutover, signed off by finance.

Do we need an implementation partner, or can we self-implement?

Under roughly 25 to 50 seats, one entity, and a straightforward process, a competent admin can self-implement on vendor documentation. Multiple entities, real manufacturing complexity, or billing integrations are where a partner earns its fee, mainly for governance and change management rather than configuration alone.

Treat the decisions as the deliverable

Teams that get ERP implementation right spend their early effort on decisions, not configuration: the chart of accounts, which processes need to change, who owns each piece of master data, and what "done" means for phase one. Configuration is the part a competent partner executes quickly once those decisions exist, and the part that takes months when they don't.

About the author

Calvin D.

Head of Enterprise Solutions

Calvin D. is Head of Enterprise Solutions at Rework, with 5+ years and 40+ enterprise engagements spanning 20 to 500+ user deployments. Calvin helps Heads of Operations, IT Directors, and VPs connect CRM, workflow automation, and data into one stack that actually fits together. Readers get field-tested architecture decisions they can apply as their teams scale.

View full profile LinkedIn