When to delay an ERP migration

Most mid-market ERP migrations don't fail because the new system is wrong. They fail because the organization wasn't ready, and nobody admitted it out loud until eighteen months and two million dollars had been spent.

Heartwood has been on the inside of seven ERP replacements through the advisor panel's combined experience. Four went well, one was a grind that eventually stabilized, and two were canceled mid-flight after significant spend. The decision that mattered most in every case was the one almost no one framed as a decision: whether this year was actually the year.

This is the checklist we now use: seven signals that say delay. If three or more are true, the migration is almost certainly going to hurt more than it helps. That doesn't mean never. It means not yet.

1. Your current system is stable, just ugly

"Stable but ugly" is the single most over-cited reason to replace an ERP. The finance team hates the reporting. Operations routes around it. Sales has built their own system in a spreadsheet. All true. None of it means you have to replace the ERP this year.

The real test: in the past 12 months, has the current ERP caused a business outage, a compliance failure, a material reporting error, or a direct loss of a customer? If not, the case for migrating now is weaker than the sales team replacing it will tell you.

2. You're in the middle of another major change

If you're in the first year of a new leadership team, a recent acquisition that hasn't finished integrating, a PE transition, or a business model pivot, delay. ERPs touch every department. They force every process to get documented, re-examined, and rebuilt. Doing that in parallel with a second change program is how you end up with both initiatives failing.

3. Your IT team is under-resourced for the next 12 months

A typical mid-market ERP migration consumes 30 to 50% of one senior IT person's time for 12 to 18 months, plus partial capacity from at least three others. If your IT team is already firefighting (keeping the network up, handling an M365 migration, defending against a ransomware attempt), adding ERP on top will cause something to break.

The right answer is not to staff up temporarily and push through. The right answer is to stabilize the current load, hire thoughtfully, and start the ERP work from a position of capacity.

4. You don't have a finance leader who will own it

ERPs are finance systems. If your CFO or Controller views the ERP as "IT's project," cancel. Or delay. Either way, do not start. The single highest-correlation predictor we've seen for a successful ERP migration is a finance leader who personally owns the outcomes. They don't just attend the meetings. They make the hard calls on scope, configuration choices, and when to say no to a business user's request.

5. Your data is a known disaster and nobody has cleaned it

Every ERP vendor says, "We'll clean the data during implementation." They mean, "We'll migrate what you give us." If your current system has duplicate customer records, inconsistent product codes, or a chart of accounts that's grown organically for fifteen years, that mess is going to the new system unchanged. Only now it's also the new system's first impression.

A six-month data cleanup before selection is not a delay. It's prerequisite work. You'd also be shocked how often the cleanup reveals that the current system's real problem was garbage data, not the system itself.

6. Your process owners can't describe how things work today

Ask your operations leader to walk you through the order-to-cash cycle. If the answer is mostly, "Talk to Karen, she handles it," you have a tribal knowledge problem, not an ERP problem. No implementation partner will fix that for you. They will document what Karen says, ship it, and move on. The processes you didn't understand before will now be encoded in software that's harder to change.

Run process-mapping workshops first. Yes, it costs time. It costs less than the implementation you're about to do without them.

7. The business case is "we should be on the cloud"

Modernization is not a business case. "Save 200 finance hours a month," "reduce close from 12 days to 5," "enable multi-entity consolidation for the two acquisitions we're planning" are business cases. If the answer to "why now" is a vague appeal to keeping up, the project is starting from a weak position that no vendor or consultant will strengthen for you.

What to do with the year you gain

A delay isn't a pass. It's a redirect. Use the year to do the work that would have slowed the migration anyway: clean the data. Document the processes. Hire the finance leader who will own it. Run a proof-of-concept on two or three finalists with real data, not a canned demo. Build the business case in dollars, not adjectives.

When you come back in twelve months with those pieces in place, the migration you eventually run will be materially different: shorter, cheaper, and vastly more likely to hit the outcomes you actually wanted.

The honest version of the conversation

The hardest part of this is not the checklist. It's telling the CEO who wanted ERP on the board deck by the end of the year that you're recommending another lap. That conversation is easier when you bring a replacement plan ("Here are the three things I want to accomplish this year that make next year's migration 70% more likely to succeed") than when you arrive with just a delay.

The ERP replacement you don't do this year is the one that doesn't waste two million dollars. That's the business case for waiting, and it's the one nobody gets to read in a glossy vendor brochure.