ERP Implementation Guide: Phases, Timeline, Cost and ROI

One of the most useful projects for thinking about ERP implementation was not called an ERP project. Shinseung, one of South Korea’s top-10 tax accounting firms, ran contract management and payments on paper and manual workflows. Savvycom built the firm a custom financial management system for the contract lifecycle, client billing and automated payments. It then moved more than 4,000 legacy contracts into the new system. The screens were the visible deliverable. The migration and the payment integration made the system usable on day one. Nobody trusts a finance platform with half its contracts missing.

The same holds for ERP at almost any size. ERP implementation is the project of planning, configuring, integrating and rolling out an enterprise resource planning system, then moving the business onto it. An ERP is the shared platform that runs finance, procurement, inventory, sales, HR and production on one data model. Picking the software is a small slice of the work. Most of the effort and risk sit in data, integrations and the people who have to change how they work.

This guide answers the 13 questions mid-size buyers in Asia-Pacific ask most often about ERP implementation. It also says plainly where the evidence behind each answer comes from.

1. What is ERP implementation and what does it include?

The software arrives mostly ready. Your company does not: its chart of accounts, its pricing rules, the spreadsheet the warehouse supervisor actually trusts. A complete scope has eight workstreams, and contracts that leave any of them vague breed change orders.

1. Process design (fit-gap). Workshops map order-to-cash, procure-to-pay, record-to-report and, for manufacturers, plan-to-produce. Each gap gets a decision: adopt the standard process or change the system.
2. Configuration. Entities, currencies, tax codes, approval chains and warehouses, set up without code.
3. Customization and extensions. Code for the gaps configuration cannot close. Build it beside the core through APIs so upgrades stay cheap.
4. Integrations. CRM, warehouse, e-commerce, banking, payroll, MES and tax systems. On most mid-size projects this is the largest block of build effort.
5. Data migration. Cleansing, mapping and loading master data and open transactions, with reconciliation proof.
6. Testing. Integration, performance and user acceptance testing (UAT) on real data volumes.
7. Training and change management. Role-based training, plus the slower work of retiring the old spreadsheet.
8. Cutover and hypercare. The go-live runbook, a legacy freeze and four to twelve weeks of intensive support.

One terminology note, since it trips up RFPs: ERP is not enterprise risk management (ERM), even though the acronyms get swapped in procurement documents.

2. What are the phases of an ERP implementation?

The two horizontal tracks matter more than the six boxes. Most ERP plans list data migration as a step near the end, and that is exactly why it goes wrong. By the time someone finds duplicates in the item master, the test cycle is already booked.

Each phase should hand over something concrete before the next one starts:

• Discovery: a business case with measurable targets, an integration inventory and a budget range the board has seen.
• Design: signed process designs and a fit-gap log where every gap has a decision attached.
• Build: working configuration and integrations, demonstrated to key users in sprint reviews.
• Testing: UAT run by the business on migrated data, signed off by each process owner.
• Cutover: a rehearsed runbook with timings and a go or no-go checklist.
• Hypercare: a clean first close, first payroll and first full order cycle.

Good delivery teams repeat import testing and migration checks several times before production data is loaded. They keep cycling through testing, training and releases during rollout. That loop is less glamorous than the phase names, and it is where data surprises get caught.

3. How long does an ERP implementation take for a mid-size company?

These are planning ranges, not promises. They assume a dedicated project owner, available key users and a vendor that starts with discovery. A shorter timeline usually means a narrower scope than the sales deck implies.

Module count moves the date less than four other variables do:

1. Decision latency. If the steering committee meets monthly and a pricing rule takes three meetings to settle, a quarter is gone.
2. Key-user availability. Staff who close the books by day and test at night do both badly.
3. Data readiness. Clean master data shortens each mock migration from weeks to days.
4. Integration count. Ten live interfaces make a different project from three, even with identical modules.

4. How much does ERP implementation cost, and what are the hidden costs?

Generic ERP cost ranges mix a 50-user finance rollout with a multi-plant program. Pricing the team you would actually need is more useful. The table shows a typical team for that mid-size scope.

Planning range, not a quote. Excludes licenses or subscriptions, platform-certified functional consultants, infrastructure, your internal staff time and contingency.

For reference, Savvycom’s Vietnam-based engineering runs $25 to $45 per hour in 2026, with senior AI and data roles reaching $55. Team mix, seniority, engagement length and how much of the work is fixed-scope all move the final number within that band.

Licenses or subscriptions sit on top, priced per user or module by the vendor. If your platform needs certified functional consultants for core configuration, price them separately. CRM deserves its own line too, and the Salesforce implementation cost breakdown by region shows how differently that piece prices.

The hidden costs that show up in month seven

• Data cleansing. Deduplicating customers and items and rebuilding the chart of accounts is labor, often your own. It is almost never in the vendor quote.
• Backfill for seconded staff. Someone covers the key users’ day jobs, or the day jobs slip.
• Integration upkeep. Every interface needs monitoring, and a fix when the other system changes its API.
• Extended hypercare. Plan for four weeks, budget for twelve. The first quarter-end close is where loose ends surface.
• The upgrade tax. Code that modifies the ERP core gets retested, sometimes rewritten, at each vendor release.
• License tier creep. “Read-only” users turn out to need approval rights and a pricier license.

5. Should we customize an off-the-shelf ERP or build a custom ERP?

The honest default is “buy and configure.” Mature suites already handle the general ledger, payables and standard inventory well. A custom build will not match them in its first two years. The real decision is how to handle what the suite does not cover.

Shinseung shows when custom wins. The scope was narrow and contract-centric: contract lifecycle, billing tied to those contracts and integrated payments. A tax firm’s service model does not map neatly onto a manufacturing-flavored suite. For a distributor with standard order-to-cash, the same decision would be hard to defend. The guide to custom ERP software development covers the pros, cons and cost of the build route.

Manufacturers who would rather compare established suites first can start with the shortlist of ERP systems for manufacturing.

6. How do we migrate data from legacy systems into a new ERP?

The sequence below holds for an ERP, a core banking platform or a custom finance system:

1. Inventory and profile. List every source, spreadsheets included. Profile each for duplicates, blanks and orphan records before anyone writes a mapping.
2. Decide what moves. Master data and open transactions move. Closed history usually travels as balances, with the detail archived read-only.
3. Assign data owners. IT can move data. Only a named business owner can say the customers, items, vendors and accounts are right.
4. Map and transform. Field-level rules, version-controlled and reviewed like code.
5. Rehearse. Two or three full mock loads, each reconciled on record counts, control totals and open balances, plus key-user spot checks.
6. Freeze, load, keep a way back. Freeze legacy master data and load during cutover. Keep the old system read-only, with a tested rollback plan, until the first close passes.

Two Savvycom projects show the pattern at different scales. For Shinseung, the team migrated more than 4,000 legacy contracts while wiring in payment processing, so contracts, billing and payments landed in one place. The Shinseung tax firm case study has the details. For a leading Cambodian commercial bank, the team migrated more than 300,000 records from a monolithic legacy setup to microservices. That work ran under a zero-data-loss requirement, with full validation and a rollback contingency, while branch services kept running (Cambodian banking case study). Neither was an ERP in name. Both had the failure modes an ERP migration has.

7. Which ERP integrations (CRM, WMS, accounting, MES) are hardest and why?

Two engineering choices keep integrations quiet after go-live. The first is a governed layer in the middle. In the Cambodian bank program, a WSO2 API gateway made every service talk through one controlled layer. The second is idempotent, replayable messages. A confirmation sent twice is booked once, and a failed one is replayed rather than retyped.

The plant-floor side has its own rules. The guide to manufacturing operations software explains where MES ends and the ERP begins, and how machine data should reach both.

8. What team roles does an ERP project need on the client and vendor side?

Client roles get underestimated. Vendors can add people. Only you can supply the ones who know why the credit note process has that extra approval step.

Vendor effort shifts by phase. Analysts dominate design, developers dominate build, and QA engineers and trainers carry the final third.

9. Why do ERP implementations fail, and how do we reduce the risk?

Gartner research predicts that by 2027, more than 70% of recently implemented ERP initiatives will not fully meet their original business case goals. It names alignment with corporate strategy as a top predictor of success. Note the wording. Most ERP failures are quiet: the system runs, and the promised benefits never arrive.

The causes that recur across ERP post-mortems each have a countermeasure that works:

1. A business case nobody can measure. “Better visibility” cannot fail, so it cannot succeed either. Write three to five numeric targets with owners, such as closing the books in five working days.
2. Sponsorship that ends at kickoff. When finance and operations disagree, someone senior must decide within a week. A steering committee with a fixed cadence and a decision log is cheaper than any tool.
3. Key users on top of day jobs. Backfill them. It costs less than a second UAT cycle.
4. Customization by default. Ask of every gap: what would adopting the standard process cost the business? Many gaps disappear.
5. Data left until the end. Run the first mock migration before build finishes, and track data quality as a project KPI.
6. Go-live chosen by calendar. Go live on criteria (UAT passed, reconciliations signed, users trained), within a date window.

Programs in trouble can be recovered. McKinsey’s account of how METRO got its ERP transformation back on track describes cutting program duration by around 30%. It also reports savings of up to 25% of program costs after resetting C-suite sponsorship, team ownership and KPI tracking. None of those fixes were technical.

Before signing with any vendor, run the self-check below.

10. Big-bang or phased rollout: which fits our business?

Big-bang concentrates risk into one weekend and avoids months of temporary interfaces between old and new systems. Phased rollout spreads the risk, but pays for it with those interfaces and a longer program. The factors below show which way your business leans.

If four or more rows point the same way, follow them. If the table splits, the hybrid is usually right. Finance core and master data go live at once for every entity, so there is one ledger from day one. Warehouse, production or field service modules then roll out by site. Multi-plant suppliers, like those covered in the guide to ERP for automotive manufacturers, almost always land here. One plant’s stoppage ripples into customers’ just-in-time schedules.

11. How do we measure ERP ROI after go-live?

The common ROI mistake is not a bad formula but a missing “before” number. Three months after go-live, nobody remembers how long the close used to take. Capture baselines during discovery and freeze them.

Keep the arithmetic plain. Annual quantified benefit minus annual run cost, set against the one-time implementation cost, gives a payback period a CFO can audit. At 90 days, check stability and adoption, not ROI. By six months the process KPIs should be moving; by twelve, working capital and cost effects become visible.

Automation around the ERP often produces the clearest numbers. Savvycom built an AI document intelligence platform for a U.S. healthcare organization. It feeds validated data from forms and clinical notes into the client’s EMR, ERP and accounting systems. It cut manual data entry by 50 to 70% against the client’s pre-automation baseline. The AI document intelligence case study shows how validation and human-review routing work.

12. What should we look for in an ERP implementation partner in APAC?

A group with entities in Singapore, Thailand and Vietnam faces different e-invoicing rules and data protection regimes. A partner who knows one market will learn the others on your budget.

• References you can call. Two clients at your size, asked what went wrong rather than whether they are happy.
• Certification, stated plainly. Is the partner certified for your platform, and who does core configuration? A partner that blurs this will blur other answers.
• Integration and data evidence. An integration architecture and a reconciliation pack from a past migration are harder to fake than a slide.
• Discovery before a fixed price. A fixed price before discovery usually means change orders later.
• Named team and support terms. Project manager and lead architect in the contract, plus hypercare length and support hours across your time zones.

13. How is AI being used inside ERP systems in 2026?

Gartner predicts that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in 2025. The useful buyer question is not whether the ERP “has AI.” It is which uses are mature enough for a business case.

1. Document capture. The most mature use. OCR and language models read invoices and forms, validate them against master data and post them, routing low-confidence items to a person.
2. Anomaly detection. Duplicate invoices, odd journal entries or changed vendor bank details get flagged before payment. It points auditors at the right lines; it does not replace controls.
3. Forecasting. Demand and cash forecasts need a couple of years of clean history, which a brand-new ERP does not have yet.
4. Natural-language reporting. Plain-language questions for managers, still dependent on a governed data model underneath.
5. Task-specific agents. Drafting purchase orders, matching receipts, chasing approvals. This is early, and the agents that work have narrow scope and hard write limits.

For an ERP project starting in 2026, design for AI without betting the business case on it. That means clean master data, documented APIs, role-based approvals and an audit log.

Frequently asked questions

Can we keep our current accounting software and add an ERP around it?

Yes, for a transition period, but two systems of record rarely pay off for long. A separate general ledger means a permanent integration to maintain and a reconciliation at every close. Most mid-size companies move the ledger into the ERP in the first wave and keep the old package read-only for history.

How much time will our own staff spend on an ERP project?

Plan for one full-time project owner, plus key users giving 30 to 50% of their time during design and testing, rising near cutover. Finance usually carries the heaviest load. Companies that do not backfill those people tend to see slower decisions, thinner testing and a longer stabilization period after go-live.

What happens during hypercare after ERP go-live?

Hypercare is the four to twelve weeks after go-live when the implementation team stays on high alert. The team fixes defects and answers user questions. It also watches critical events such as the first payroll run, the first month-end close and the first large order batches. Hypercare ends when ticket volume and severity stabilize.

Is cloud ERP or on-premise ERP better for a mid-size company in APAC?

Cloud ERP is the default for most mid-size companies in 2026, because the vendor handles upgrades, hosting and security patching. On-premise or private hosting still makes sense where data residency rules, unreliable plant connectivity or heavy legacy customization apply. Check where the vendor hosts data for every country you operate in.

Can an offshore team in Vietnam implement our ERP?

An offshore team in Vietnam can handle most build work in an ERP program, including integrations, custom modules, data migration scripts, testing and reporting. Design workshops, key-user training and cutover weekends work better with people on site or in your time zone. Most programs therefore pair an onshore lead with an offshore delivery team.

Where Savvycom fits in an ERP program, and where it does not

Savvycom is a Vietnam-headquartered software engineering company, founded in 2009, with ISO 9001 and ISO 27001 certification and offices across Asia-Pacific and the US. In an ERP program, its strength is the engineering around the core. That means integrations, custom modules, data migration and reconciliation, and test automation, delivered through its ERP implementation and customization services.

For many mid-size companies, the practical arrangement is a pairing. A certified platform partner owns core configuration and licensing, and Savvycom carries integrations, extensions, data migration and testing.