ERP Implementation

Six months after your ERP go-live, the finance team is still re-entering data from the legacy system every Monday morning because the data migration was 'mostly done' at launch. The implementation hit its timeline. The implementation wasn't finished. ERP implementation is the process of deploying an enterprise resource planning system in an organization, from initial discovery and scoping through configuration, data migration, testing, training, and go-live. It is one of the largest and riskiest technology projects most finance teams will take on, because the ERP becomes the system of record for financial data. When it goes wrong, core financial operations suffer: delayed closes, inaccurate books, and a team spending its first months on the new system doing manual workarounds instead of running the business. The scenario above is what happens when data migration is treated as a one-time task to ship and forget. In reality, migration has a long tail of validation, exception handling, and reconciliation work that continues well past go-live. Organizations that treat 'go-live' as the end of the implementation, rather than the start of the operational phase, consistently underestimate what it takes to reach steady-state operation.

The six phases of ERP implementation

Phase 1 (Discovery) establishes requirements: current-state process documentation, gap analysis against the system's native capabilities, and the decision about what to configure vs customize vs leave to a separate system. Phase 2 (Build) configures the system: chart of accounts setup, workflow configuration, integration development, and report building. Phase 3 (Data Migration) extracts, transforms, and loads data from legacy systems: customer and vendor master data, open AR and AP balances, fixed asset records, historical GL transactions (if needed for reporting), and inventory on-hand quantities. Phase 4 (Testing) validates the configured system against test scripts for every business process: unit testing of individual functions, integration testing of end-to-end workflows, and user acceptance testing with actual end users. Phase 5 (Training) prepares end users to operate the system. Phase 6 (Go-Live) cuts over to the new system and retires the legacy system. The two phases where most projects fail are data migration (Phase 3) and user adoption (Phase 5). Data migration fails because teams consistently underestimate how hard it is to transform data from one system's structure to another's. User adoption fails because training is scheduled late, compressed to save time, and delivered before users have hands-on practice with real data in a realistic environment.

Where it gets complicated

Data migration is underestimated for three consistent reasons. First, legacy data quality is worse than expected: duplicate vendor records, inconsistent customer naming, GL accounts mapped to the wrong categories, open transactions missing required fields. Cleaning this data before migration takes longer than anyone scopes. Second, the transformation logic is more complex than the initial mapping spreadsheet suggests: a flat GL account has to map to a multi-segment account structure, customer records from three different systems have to merge into one master record, and historical transaction references have to carry forward in a format the new system can process. Third, validation (confirming that migrated data matches the source system) is treated as a single pass instead of an iterative process that needs several cycles. User adoption is underestimated because training is planned as an event instead of a process. A two-day training session one week before go-live doesn't produce users who can run the system confidently under a real workload. The post-go-live tail, the period of heavier support, workarounds, and lost productivity after go-live, usually runs three to six months before users reach steady-state proficiency.

How platforms handle it

Implementation reference calls are the most valuable due diligence step when selecting ERP software, and the most underused. Vendors will provide reference customers on request, but they will provide their best ones. Structure the call to get past the prepared story. Ask: What were the original implementation timeline and budget, and what were the final ones? What was descoped from Phase 1, and why? What were the two or three biggest implementation challenges, and how did the implementation partner handle them? How would you rate the partner's project management against their technical capability? What was post-go-live support like in the first 90 days? What would you do differently? And the most telling one: when did the system actually replace the legacy system in daily operations, meaning when did the team stop going back to the old system for working data? That answer gives you the real implementation completion date, which often differs from the nominal go-live date. A reference customer who says 'we went live in March but we were still pulling from the old system for reports until August' is telling you the implementation took five months longer than the go-live date suggests.

Questions to ask

• What is included in the data migration scope: which data objects, how many years of historical transactions, and what validation method confirms that migrated data matches source data?
• What is the change management and training plan? Who delivers training, when is it scheduled relative to go-live, and what does the post-go-live hypercare period include?
• What is the escalation path if the implementation falls behind schedule? What triggers a scope change discussion, and what is the cost and timeline impact of common scope changes?
• How do you handle the go/no-go decision at cut-over? What criteria must be met before going live, and who has authority to delay go-live if they aren't met?
• What does post-go-live support look like? Who are the contacts, what is the response SLA for critical issues, and how long does the hypercare period run before moving to standard support?

Common mistakes

Underestimating data migration complexity is the mistake most likely to produce the scenario in the intro: re-entering data months after go-live. When migration is scoped as a three-week effort and takes three months, the timeline is under pressure, and the migration is often declared 'done' when it is complete enough to cut over, not complete enough to retire the legacy system. The result is a live ERP running alongside a live legacy system, with manual synchronization between the two until the migration work is actually finished. That state can last for months or years. The second failure is letting the go-live date drive scope instead of readiness. Teams under timeline pressure sometimes cut testing cycles, compress training, and declare go-live before user acceptance testing is complete, because the date is tied to a contract renewal, a board commitment, or a fiscal year start. A rushed go-live produces a system that technically works but isn't operationally ready: users don't know the workflows, reports haven't been validated, and integrations haven't been tested under real transaction volume. Fixing these problems after go-live costs significantly more than delaying go-live would have.

Comparing ERP platforms

Most of an ERP decision is settled by data model and entity structure, not by the feature list a demo walks through. Once ERP Implementation is settled as a requirement, read the ERP Software category guide for how the market splits, then weigh the NetSuite profile against the Sage Intacct profile on that requirement rather than on the feature list. Our OneStream pricing breakdown records what the vendor publishes and what is quote-based. The OneStream against Planful comparison sets two of them side by side on the same criteria. Before you book demos, put your own numbers through the ERP ROI calculator so the business case is written down before a vendor writes it for you.

ERP Implementation questions

Related terms

Chart of Accounts Mapping, Cloud ERP vs On-Premise ERP, and Enterprise Resource Planning (ERP) come up in the same workflow as ERP Implementation, and the rest of the ERP platforms cluster is indexed in the finance operations glossary.