ERP Go-Live & Hypercare.

The first 90% of an ERP rollout is project management. The last 10% is operations. You’re not building the system anymore — you’re cutting over from the old one, stabilizing the new one, and absorbing the work that the team can’t yet do in the new system.

This phase has its own failure modes. Cutover plans that look fine on paper hit reality and require improvisation. Hypercare tickets pile up faster than the team can process them. The training that seemed adequate in UAT turns out to be inadequate when the AP team is processing month-end close in a system they’ve used for two weeks. The project sponsor wants daily updates that the project team can’t generate without taking time away from fixing things.

PD’s ERP template is built for these constraints.

The cutover plan has its own workspace in PD. Every step is documented; every owner is identified; every dependency is tracked. The rollback plan is part of the cutover plan, not a separate document.

What’s distinct in PD vs. a generic project tool is that the cutover plan is informed by Atlas — prior cutover plans for similar engagements, with the steps that went wrong flagged. You’re not designing the cutover from scratch; you’re designing it from the portfolio.

Hypercare tickets are categorically different from project tasks. They’re shorter-lived, higher-frequency, often urgent, often resolved without writing anything down. The result is that the firm’s accumulated hypercare wisdom is lost the moment the senior consultant rolls off.

PD treats hypercare tickets as first-class artifacts. Each ticket has a category, a resolution, and a link to the originating workflow. The patterns are surfaced in Atlas — at similar engagements, this ticket type was the most common in the first 14 days; here’s how it was resolved. The output is that the second engagement’s hypercare runs materially smoother than the first.

The most consequential change-management work happens in the go-live window. The training that was adequate is now exposed as inadequate. The resistance that was suppressed in UAT surfaces in production.

PD’s Change Management module is configured for the go-live window. The ADKAR scores update in real time; the resistance log captures the actual concerns staff are raising; the training tracker drives the make-up sessions. The output is that adoption issues are visible and addressable in week one of hypercare, not week six.

Hypercare isn’t a single phase — it’s a structured 30/60/90 day cadence. Each milestone has its own checklist. The 30-day milestone is about stability — are systems running, are tickets being processed? The 60-day milestone is about adoption — is the team actually using the new system or running parallel processes? The 90-day milestone is about handoff — is the system in steady-state ownership?

PD’s template enforces this cadence. The milestones are phase gates. The checklists are completed and signed off. The handoff to steady-state ownership is a deliverable, not an assumption.