ERP implementation and cloud ERP modernisation: a practitioner's guide for 2027

Quick answer: ERP implementation is the programme of selecting, designing, configuring, migrating data to and adopting an enterprise resource planning system that runs finance, procurement, supply chain and often HR on one ledger. For a large organisation it typically takes 12 to 36 months, costs two to four times the software subscription over the first three years, and succeeds or fails on process design and data quality rather than on the vendor chosen.

Across Australia and New Zealand a large share of enterprise and government ERP estates is approaching a forced decision. SAP's mainstream maintenance for ECC ends in 2027, on-premise Oracle E-Business Suite and JD Edwards instances are ageing, and the mid-market suites bought in the 2010s have been customised to the point where upgrades are no longer practical. Cloud ERP is the default destination, and the implementation is usually the largest single investment a finance function will sponsor this decade.

This guide is for CFOs, CIOs, finance systems leads and programme directors who have to make that investment land. It covers how to run ERP selection, what a credible ERP implementation plan contains, how to think about cost and timeline without a vendor in the room, the modernisation options for legacy ERP, and the reasons programmes fail that rarely appear in the business case.

What is ERP implementation, and how is cloud ERP different?

An ERP system implementation replaces or consolidates the systems of record for the general ledger, accounts payable and receivable, fixed assets, procurement, inventory, projects and, depending on scope, payroll, manufacturing and asset management. "Implementation" covers the whole arc: selection, design, build and configuration, data migration, integration, testing, training, cutover and the stabilisation period after go-live.

Cloud ERP changes the shape of that arc in three ways:

• Configuration over customisation. Multi-tenant SaaS suites (Workday, NetSuite, Dynamics 365, SAP S/4HANA Cloud Public Edition, Oracle Fusion) restrict code-level changes. Processes have to fit the product's standard model or be handled through extensions and integrations. This is the single biggest cultural shift for organisations used to bending the system to the business.
• Continuous releases. The vendor pushes updates two to four times a year. Regression testing becomes an ongoing operational capability, not a project activity.
• Subscription economics. Capital expenditure shifts to operating expenditure, and the cost of carrying unused modules or excess user licences is visible every year.

The alternative paths — private cloud hosting of an existing suite, or a "hybrid" of SAP S/4HANA Private Edition under RISE — keep more flexibility and more of the legacy problem. They are legitimate choices for complex manufacturers and asset-intensive operators, but they should be chosen deliberately, not as a way to avoid redesign.

How do you run an ERP selection process?

Selection is where most of the later pain is either prevented or locked in. A disciplined ERP selection process has five steps.

1. Define the operating model and process scope first. Which processes will be global and standard, which will tolerate local variants, and which are out of scope. If you have not done this, the vendor demos will do it for you. The companion guide on the finance transformation roadmap and operating model explains why this comes first.
2. Write scenario-based requirements, not feature checklists. A 900-line spreadsheet of "must have / nice to have" rows produces identical vendor scores. Twenty to thirty end-to-end scenarios drawn from your actual pain points (intercompany settlement across four entities, a grant-funded project with milestone billing, a purchase order with partial receipt and a price variance) separate products quickly.
3. Shortlist to three and run scripted demonstrations. Vendors demonstrate your scenarios on your sample data, scored by the people who will use the system. Record the sessions.
4. Evaluate the implementation partner at the same time as the software. For most suites the partner determines the outcome more than the product. Assess the named team, not the firm's credentials, and insist on reference calls with organisations of similar complexity in your region.
5. Negotiate the commercial model before announcing a winner. Subscription tiers, user definitions, environment counts, data storage, integration platform costs and price escalation clauses all carry more weight over five years than the headline discount.

ERP selection criteria that matter in 2027

• Fit to standard process — Why it matters: Every customisation is permanent cost · What to test: Percentage of your scenarios handled without extension
• Data model and reporting — Why it matters: Determines whether finance gets insight or extracts · What to test: Build a board-pack view live in the demo
• Integration platform — Why it matters: Cloud ERP sits in an ecosystem of planning, payroll, CRM, WMS · What to test: Evidence of integrations with your actual adjacent systems
• Localisation — Why it matters: GST, BAS, Single Touch Payroll Phase 2, Payday Super, NZ GST and payday filing, Peppol e-invoicing · What to test: Ask for Australian and New Zealand reference sites
• Release management — Why it matters: Quarterly updates need testing · What to test: Vendor's release notes, test-automation tooling, sandbox strategy
• Partner depth in your region — Why it matters: Offshore-only delivery raises timezone and knowledge risk · What to test: Named consultants, their tenure, local bench
• Total cost over five years — Why it matters: Subscription is the smaller half · What to test: Model subscription + implementation + internal team + run cost
• Resilience and regulatory fit — Why it matters: APRA CPS 230 material service provider obligations for regulated entities; data residency · What to test: Hosting region, exit provisions, SOC 2 / ISO 27001 evidence

What does a realistic ERP implementation plan look like?

A credible ERP implementation plan is organised by release, not by module. The phases below are typical for a large Australian organisation moving to cloud ERP.

• Mobilise and design — Duration (large enterprise): 3-6 months · What has to be true at the end: Global process design signed off; chart of accounts and master data standards final; integration inventory complete
• Build and configure — Duration (large enterprise): 4-8 months · What has to be true at the end: System configured to design; integrations built; data migration tooling proven on a full trial load
• Test — Duration (large enterprise): 3-5 months · What has to be true at the end: Multiple full cycles of system, integration and user acceptance testing; a parallel month-end run
• Cutover and go-live — Duration (large enterprise): 4-8 weeks · What has to be true at the end: Cutover rehearsed at least twice; hypercare team staffed; rollback criteria agreed
• Stabilise and optimise — Duration (large enterprise): 3-6 months · What has to be true at the end: First quarter-end closed on time; backlog of deferred items prioritised; project team handed to run team

Three planning decisions shape everything:

• Big bang or phased. A single go-live is faster and avoids a long period of running two ledgers with interim integrations, but concentrates risk. Phasing by entity or by process (finance first, supply chain later) reduces risk at the cost of temporary complexity. Organisations with more than a handful of entities or geographies usually phase.
• Data migration scope. Migrating ten years of transactional history into a new structure is expensive and rarely used. Most programmes migrate open items, balances and two to three years of summarised history, and archive the rest in a queryable store.
• Integration strategy. Count the integrations early. Enterprise programmes routinely discover 60 to 150 interfaces, many undocumented. An integration platform and a clear owner for each interface should exist before build starts.

How much does ERP implementation cost, and how long does it take?

Nobody can quote a dollar figure without knowing scope, but the ratios are stable enough to plan with.

• Implementation services run one to three times the first-year subscription for a standard-fit deployment, and higher where there is heavy integration or manufacturing scope. Partners quoting below this range have usually assumed scope you will have to add back.
• Internal cost is routinely underestimated by half. Backfilling subject-matter experts, a full-time programme team, change management and testing resources typically match or exceed the external services spend.
• Run cost rises before it falls. Subscription plus an integration platform plus a managed-services partner for release testing is frequently more than the maintenance on the legacy system for the first two years; the savings come from decommissioned point solutions, fewer manual processes and avoided upgrades.
• Timeline: a mid-sized single-entity organisation can go live on a SaaS suite in 6 to 12 months. A multi-entity enterprise or a government agency should expect 18 to 36 months end to end, with phased go-lives. Vendor-published averages tend toward the shorter end because they describe the build phase, not the programme.

A practical rule for the business case: model total cost of ownership over five years, include the internal team at full cost, and assume the first year of run cost exceeds today's. If the case only works with optimistic assumptions about licence counts or headcount reduction, it will not survive the steering committee in year two.

What are the options for modernising legacy ERP?

Not every legacy ERP needs replacing on the same clock. The options for ERP modernisation sit on a spectrum.

• Re-implement on cloud ERP ("greenfield"). Clean design, standard processes, the opportunity to drop decades of customisation. Highest change effort and highest payoff. The right answer where the current system has been heavily customised and the operating model is changing anyway.
• Technical migration ("brownfield"). Move the existing configuration and data to the new platform, for example an SAP ECC to S/4HANA system conversion. Faster and less disruptive, but carries the legacy design forward. Appropriate where processes are already reasonably standard and the forcing function is support end-of-life.
• Selective transition ("bluefield"). Migrate a cleaned subset of configuration and data. A pragmatic middle path for large SAP estates, though it needs specialist tooling and a partner who has done it before.
• Hollow out the core. Keep the legacy ledger, but move planning, close management, procurement or expense management to best-of-breed cloud tools integrated around it. Buys time and delivers visible wins — the FP&A and AI in financial planning guide covers the planning layer — but does not remove the end-of-life problem.
• Lift to hosted infrastructure. Move the existing instance to a hyperscaler or vendor-managed cloud. Lowest effort and lowest value; sensible only as a bridge with a dated exit plan.

For supply-chain-heavy organisations there is a further question: whether to use the ERP's own demand, supply and warehouse modules or integrate specialist platforms. The guide to AI demand planning and S&OP sets out how practitioners make that call.

Why do ERP implementations fail?

Programmes rarely fail on technology. The patterns below recur across industries and vendors.

1. Design by demo. The organisation skips operating model and process design, so the vendor's default configuration becomes the design and legacy workarounds are rebuilt on top of it.
2. Data left to the end. Master data cleansing, deduplication and ownership are treated as a migration task rather than a workstream that starts in month one. Trial loads fail late, go-live slips, and the new system inherits the old data problems.
3. Customisation creep. Each "we can't change that process" is accepted individually; collectively they turn a SaaS deployment into a bespoke build with a quarterly regression nightmare.
4. Under-staffed business team. The partner supplies consultants; the organisation fails to release its best people from their day jobs. Decisions stall and testing is superficial.
5. Testing compressed to protect the date. A fixed go-live date and a late build mean user acceptance testing and the parallel close are cut. The first real month-end becomes the test.
6. No stabilisation budget. Funding ends at go-live. The deferred-item backlog, the integration fixes and the retraining have no owner, and the business concludes the system "doesn't work".
7. Weak governance of the partner. No independent assurance, milestone payments not tied to acceptance, and change requests that are approved without reference to the original scope.

How do you choose an ERP implementation partner?

• Assess the people, not the logo. Request CVs of the named solution architect, finance lead and integration lead, and the right to approve replacements.
• Check regional and industry references. A partner strong in US retail may have no bench in Australian public sector, utilities or aged care, each with distinct localisation and funding rules.
• Insist on a fixed-scope design phase with a priced build. Time-and-materials for the whole programme removes the partner's incentive to control scope.
• Tie payments to accepted milestones, including a parallel close and a successful mock cutover.
• Separate assurance from delivery. An independent quality assurance role reporting to the steering committee, whether internal or a third party, catches the problems the delivery partner is incentivised to minimise.
• Plan the handover to run. Agree during selection who will handle release testing, minor enhancements and support after stabilisation, and what it will cost.

Key takeaways

• ERP implementation is decided in selection and design: write the operating model and scenario-based requirements before the first vendor demo.
• Choose the implementation partner's named team as carefully as the software, and tie payment to accepted milestones including a parallel close.
• Budget on ratios: services at one to three times first-year subscription, internal cost matching external, and run cost above legacy for the first two years.
• Treat data and integrations as day-one workstreams, not migration tasks.
• Decide the modernisation path — greenfield, brownfield, bluefield, hollow-out or rehost — deliberately, against the degree of customisation and the operating model change you actually want.
• Fund stabilisation and release testing; a cloud ERP is a capability to run, not a project to finish.

Join your peers at the Finance Technology and Transformation Summits 2027

Clutch Events runs free-to-attend, practitioner-led summits for finance and finance technology leaders in large enterprises and government. Upcoming: Brisbane Finance Technology and Transformation Summit 2027 — 14 April 2027 · Sydney Finance Technology and Transformation Summit 2027 — 12 May 2027 · Melbourne Finance Technology and Transformation Summit 2027 — 16 September 2027. See all upcoming events. More guides at the Clutch Events insights hub.