The Rollout Habits That Separate ERP Projects That Work

Two regional healthcare staffing companies implemented the same ERP platform within four months of each other in 2025, through the same implementation partner, with nearly identical scope: financials, procurement, and a payroll integration. One went live on schedule and was running clean month-end closes within two months. The other slipped its go-live twice, ran a parallel legacy system for five months after the eventual cutover, and lost its original project sponsor to a different role halfway through. The software was not the variable. The rollout discipline was.

Phased go-live beats big bang for most organizations

A big-bang go-live, where every module and every location and every user switches over on a single date, is appealing on paper because it is faster and it avoids running two systems in parallel. It is also the higher-risk option, and it demands a level of testing rigor and internal change-management capacity that most organizations without a dedicated PMO do not actually have, even when the project plan assumes they do.

A phased approach, such as core financials first, then procurement, then a second location, then payroll, costs more in total elapsed time and in the overhead of running interim data bridges between old and new systems. What it buys back is the ability to catch a bad assumption in a contained blast radius. A chart-of-accounts mapping error discovered in week two of a single-location financials go-live is an afternoon of cleanup. The same error discovered on a big-bang go-live across four locations and three modules simultaneously is a multi-week fire drill, often with month-end close deadlines bearing down while the fix is still in progress.

The exception is genuinely small, simple organizations, generally under 30 users, one legal entity, and no significant multi-warehouse or multi-currency complexity, where the coordination overhead of a phased approach outweighs its risk-reduction value. Past that size, phasing is worth the extra calendar time in nearly every case.

Choosing which location or entity goes first also matters more than project plans usually acknowledge. The stronger pattern is to pick a location that is representative of the broader business, not the simplest one. Piloting at the smallest, least complex site produces a clean go-live that tells the team very little about how the system handles the complexity waiting at the other locations, and problems that should have surfaced in week two of a phased rollout instead surface in the final, most complex phase, when there is far less schedule buffer left to absorb them.

Executive sponsorship has to show up in decisions, not the kickoff deck

Every ERP project kickoff includes an executive sponsor slide. What separates a real sponsor from a ceremonial one is whether that person makes decisions during the project, not whether they show up to the first meeting. Two specific moments reveal the difference: scope disputes and resourcing conflicts.

When a department wants to add scope mid-project, such as a new report or a workflow change nobody flagged during requirements, a real sponsor either says no or explicitly approves the schedule and budget impact of saying yes. A ceremonial sponsor lets the project team absorb the decision, which is how scope creep quietly adds six weeks to a sixteen-week plan without anyone formally deciding it should.

The second moment is resourcing. Implementation projects need subject-matter experts, such as the accounts payable clerk who knows every vendor exception or the warehouse supervisor who knows why the current cycle-count process exists, pulled off their regular workload for real blocks of time, not squeezed in around their day job. A sponsor who protects that time, by explicitly reassigning the subject-matter expert's regular duties for the duration, is doing the job. A sponsor who tells a department head "just make it work" is not, and the project timeline absorbs the cost of that gap in testing quality and requirements accuracy.

Data migration needs a sign-off gate, not a deadline

Data migration is usually scheduled as a task with a due date: migrate customer master data by a fixed date. That framing treats migration as done when the data has moved, not when the data has been verified. The healthier pattern is a formal sign-off gate: a named business owner, not the implementation consultant and not IT, reviews a reconciliation report comparing record counts, key field values, and a sample of transactions against the source system, and signs off in writing before the migrated data becomes the system of record.

This catches problems a technical migration script cannot: a customer credit limit field that migrated technically correctly but was calculated differently in the old system, a product catalog where discontinued SKUs were excluded from the extract without anyone deciding that was the right call, or an open-invoice balance that reconciles in total but is misallocated across individual customer accounts. None of those are migration failures in a technical sense. All of them are the kind of thing that turns into a bad customer call three weeks after go-live if nobody with business context checked the data before cutover.

Super-user training needs to be a cadence, not an event

The standard training plan is a block of sessions in the two weeks before go-live, covering the system end to end, followed by nothing. This produces users who can operate the system on day one and have forgotten half of it by week three, because training delivered before there is any real data or real transactions to anchor it to does not stick the way training delivered against live work does.

A cadence model works better: initial training before go-live focused on core daily tasks only, a scheduled follow-up session two to three weeks after go-live once users have real questions from actual use, and a recurring office-hours slot for the first two months where super-users can bring specific problems as they come up. This costs more calendar time from the training lead but produces users who retain the material, because it is anchored to problems they have actually hit rather than a hypothetical walkthrough.

Watching for drift in the first 90 days after go-live

A go-live that looks clean in week one can still be quietly failing by week eight if nobody is tracking the right signals. Three metrics catch drift before it becomes a crisis: the count of manual workarounds still running outside the system, such as a spreadsheet tracking something the ERP was supposed to handle or a side process because a report never got built; the week-over-week trend in support ticket volume, where a healthy rollout shows a declining trend after the first two weeks while a flat or rising trend past week four usually means training gaps rather than new bugs; and whether month-end close is getting faster or staying stuck at the same elevated duration it hit during the first post-go-live close.

The staffing company with the rough go-live kept an informal list of things the team was "still doing in Excel because the new system doesn't do it yet" that grew from four items at go-live to eleven by week six, and nobody reviewed that list at a leadership level until a new controller asked for it three months in. Each item on a list like that is either a genuine gap that needs a fix, or a training gap where the functionality exists but nobody was taught to use it. The two require completely different responses, and a list nobody reviews cannot tell you which one you are dealing with.

Hypercare needs a defined end date and exit criteria

Hypercare, the elevated support period immediately after go-live when implementation consultants and super-users are on standby for fast issue resolution, is one of the most commonly under-planned parts of a rollout. "We'll support it closely for a while" is not a plan; it is a way for the period to either end too early, while real issues are still surfacing, or drag on indefinitely at a cost nobody budgeted for.

A better structure sets both a duration, commonly two to four weeks and sometimes extending through the first month-end close, and explicit exit criteria: a defined maximum count of open critical issues, a completed first month-end close with no manual workarounds outside the system, and a formal handoff meeting where support responsibility moves from the implementation team to standard operations. Every unplanned system outage during this window also has a cost worth tracking. The downtime cost calculator is a useful way to put a number on what a rocky cutover week is actually costing in lost productivity, which tends to make the case for adequate hypercare staffing much easier to justify internally than "it feels important."

The staffing company that ran a clean go-live had all four of these in place before day one: a phased rollout starting with financials only, a CFO sponsor who turned down two scope additions in writing during week six, a controller who personally signed off on the accounts receivable migration reconciliation, and a defined four-week hypercare period with a named exit meeting already on the calendar. None of that shows up in a vendor's product comparison sheet. It is the actual difference between the two outcomes.