Most ERP transition postmortems land on the same conclusion: the software worked fine, the implementation partner did competent technical work, and the project still landed rough — over budget, past deadline, or live but limping through months of workarounds. The technology is rarely the actual cause. What determines whether an ERP transition succeeds is the operational groundwork done before a single screen gets configured: whether the processes being migrated were clean enough to migrate, whether the data was trustworthy, and whether the organization actually knew what it needed the new system to do. Skipping that groundwork doesn’t make the project faster — it just moves the pain from the planning phase, where it’s cheap to fix, to the go-live phase, where it’s not.
Key Takeaways
- Migrating a broken process into a new system just gives you a faster, better-documented broken process.
- Data cleansing is operational work, not an IT task, and it needs business-side ownership to happen properly.
- Requirements gathering should focus on decisions and exceptions, not just a feature checklist.
- Parallel running and a defined cutover criteria matter more than the go-live date itself.
- Post-go-live stabilization needs dedicated capacity — treating it as “business as usual” is a common and costly mistake.
Fix the Process Before You Migrate It
An ERP implementation is frequently treated as a technical migration: take what exists today and rebuild it in the new system. This is a mistake whenever “what exists today” includes workarounds, manual patches, or processes that only function because of a specific person’s tribal knowledge. Migrating those as-is means the new system inherits all the same inefficiencies, just with a more expensive platform underneath them. Before configuration begins, walk through every major process in scope and ask a simple question of each step: does this step exist because the business genuinely needs it, or because the old system couldn’t do something better? Steps in the second category should be redesigned, not replicated. This is uncomfortable because it’s slower and touches organizational habits, but it’s far cheaper to redesign a process on a whiteboard than to reconfigure a live system six months after go-live.
Data Cleansing Is a Business Responsibility, Not an IT Task
Data migration is usually scoped as a technical activity — extract, transform, load — and handed to IT or the implementation partner. But deciding what data is actually correct, what’s duplicated, what’s obsolete, and what business rules should govern the cleanup is a business decision, not a technical one. IT can tell you that there are 400 duplicate vendor records; only the business (accounts payable, procurement) can tell you which ones are real and how they should be merged. Practical steps that avoid the common failure mode of dumping messy legacy data into a clean new system:
- Assign named business owners for each major data domain (customer master, vendor master, chart of accounts, item master) responsible for cleansing decisions.
- Run the cleansing exercise well before the technical migration window — this is not something that can be compressed into the final weeks before cutover.
- Use the cleansing process as an opportunity to simplify structures that have accumulated complexity over years, such as an overgrown chart of accounts.
- Validate a sample of migrated records against source data after each migration test, not just after the final load.
Gathering Requirements Around Decisions and Exceptions
Standard requirements gathering tends to produce a feature checklist: the system needs to do X, Y, and Z. This misses the harder and more important question, which is how the organization actually makes decisions and handles exceptions in each process. Two organizations can have identical feature requirements and very different needs once you look at how approvals actually route, what happens when a transaction doesn’t fit the standard pattern, and who has authority to override a control. Spend requirements-gathering time specifically on:
- Approval hierarchies and delegation of authority — including edge cases like approver absence or emergency overrides.
- The realistic frequency and nature of exceptions to the standard process, not just the happy path.
- Reporting requirements from the actual consumers of the reports (board, lenders, operational managers), not just what the current system happens to produce.
- Integration points with systems outside the ERP scope, and what breaks if those integrations aren’t ready on day one.
Defining Cutover Criteria Before You Set a Go-Live Date
A go-live date set too early in the project, before it’s clear what “ready” actually means, creates enormous pressure to cut corners as the date approaches. A better approach is to define explicit, measurable cutover criteria upfront — data validation thresholds, number of successful parallel-run cycles, defect severity levels that must be resolved before go-live — and let the date follow from meeting those criteria, not the other way around. Parallel running the old and new systems for at least one full close cycle, ideally two, is one of the highest-value practices here: it surfaces discrepancies while the safety net of the old system still exists, rather than after it’s been decommissioned.
Planning Stabilization as Its Own Phase
The weeks immediately after go-live are treated, far too often, as a return to normal operations with a new tool. In practice, this period generates a disproportionate volume of support tickets, process questions, and minor configuration fixes, and the team handling it is usually the same team that just spent months in implementation and is now also expected to run the business as usual. Budget dedicated stabilization capacity for at least one to two full operating cycles post-go-live — extra support hours, a clear escalation path for issues, and realistic expectations set with the wider organization that some friction is normal and temporary. Treating stabilization as “done” the moment the system goes live is one of the most common ways a technically successful implementation still earns a poor reputation across the business.
Frequently Asked Questions
How far in advance should process redesign and data cleansing start before an ERP go-live?
For a mid-sized organization, starting this groundwork four to six months before the planned go-live is typical, and often longer for complex data domains like a fragmented chart of accounts or a large, messy customer master.
Who should own the ERP transition internally if not IT?
IT should own the technical implementation, but the overall transition should be led by a business-side program owner with authority across the functions affected, supported by named data and process owners in each domain. An IT-led transition tends to under-invest in the process and data groundwork described here.
What’s a realistic sign that we’re not ready for cutover?
If parallel-run results still show unexplained variances, if critical data validation hasn’t cleared agreed thresholds, or if high-severity defects remain open, those are signs to delay rather than push through on the original date. A short delay is far cheaper than a rushed cutover.
How long does stabilization typically take after go-live?
Most organizations see support volume and process friction settle down meaningfully within one to two full operating cycles, though full comfort with the new system, especially for less frequent processes, can take two to three quarters.
Related Reading
- Shared Services Design: Centralizing Without Losing Accountability
- FP&A Capacity Planning During Systems Transformation
- Learn more about our Finance & Operational Transformation services