What an ERP Consulting Engagement Looks Like From Kickoff to Go-Live

An ERP consulting engagement typically runs from structured kickoff through discovery, solution design, build and data migration, testing and UAT, cutover, and a defined hypercare window after go-live. For a focused mid-market scope, that path often takes roughly four to nine months end to end; a tight first phase can land in eight to twelve weeks when requirements and data are ready. The consulting firm owns methodology, configuration quality, and facilitation. Your team owns process decisions, data integrity, and adoption. When either side blurs those lines, projects slip long before cutover weekend.

This guide walks the engagement the way practitioners actually run it: phase by phase, with deliverables, RACI, duration benchmarks, decision forums, risk signals, and what good looks like after the system goes live. If you are evaluating firms, use it as a checklist against proposals. If you already hired one, use it to hold the work accountable.

Direct answer: kickoff to go-live in one view

A well-run ERP consulting engagement is an operating-model program, not an IT install. Industry write-ups and partner methodologies (Microsoft’s long-running Sure Step lineage and later Success by Design practices for Dynamics, plus Odoo’s partner implementation methodology with gap analysis, iterative cycles, and go-live) all describe the same spine, even when phase names differ:

• Pre-engagement / diagnostic — process reality, constraints, rough scope and success metrics before anyone locks a platform or price.
• Kickoff and governance — sponsor, client PM, functional leads, consultant lead, steering cadence, RACI, change-control rules.
• Discovery and design — requirements, target processes, module map, integration architecture, acceptance criteria.
• Build and data migration — configuration, approved custom work, trial loads, reconciliations (migration starts early, not at the end).
• SIT, UAT, and training — integration proof, real-user scenarios, role-based training, formal go/no-go.
• Cutover and go-live — freeze, final load, dual-run or big-bang switch, rollback plan.
• Hypercare and stabilization — elevated support for weeks (commonly two to twelve, often thirty to ninety days on complex rollouts), daily triage, adoption reinforcement, then handoff to steady-state support.

Public guidance from mid-market implementation firms consistently places small cloud deployments around two to four months, mid-market programs around four to nine months, and multi-entity or heavily customized programs at twelve months or more. Configuration and UAT are where most schedule slip shows up when discovery was thin. For cost context alongside timeline, see Flectic’s ERP implementation cost guide for SMEs and the companion piece on implementation economics.

The engagement starts before you sign

A credible ERP engagement begins with structured discovery, not a product demo. If the first artifact you see is a deck about the firm’s preferred platform, treat that as a sales motion, not a diagnostic. Platform choice should follow process understanding.

In proper discovery, the consultant maps current workflows, finds where data breaks (often between accounting, CRM, and operations), and quantifies the cost of doing nothing. Before you can judge a five- or six-figure proposal, you need a concrete picture of manual reconciliation, delayed close, inventory error, and rework. That business case is what sponsors defend when the project hits friction later.

Flectic’s free discovery and readiness conversations exist for this reason: make the cost of disconnected systems concrete before anyone sells modules. Pair that with the ERP readiness 90-day playbook so your internal team arrives with cleaned data owners, decision rights, and realistic capacity.

Phase-by-phase: deliverables that prove the work is real

Vendor methodologies rename phases (Sure Step’s Diagnostic → Analysis → Design → Develop → Deploy → Operate; Odoo’s gap analysis, kick-off, iterative implementation cycles, go-live). Buyers should care less about labels and more about exit criteria. Below is the engagement shape most mid-market programs should insist on.

1. Kickoff and governance (about one to two weeks after contract)

Purpose. Align people, power, and rules before configuration starts.

Consultant owns. Project plan baseline, RAID log (risks, assumptions, issues, dependencies), workshop calendar, environment strategy, communication plan.

Client owns. Named executive sponsor, client-side project manager, functional leads with time reserved, single point of contact for decisions, access to systems and sample data.

Exit criteria. Signed RACI, steering-committee schedule, scope baseline, success metrics in business language (close cycle days, inventory accuracy, order-to-cash time), change-control process in writing.

Decision forum. Steering committee (biweekly or monthly) for scope, budget, go/no-go. Working group (weekly) for blockers. No “side decisions” in Slack that never hit the baseline.

2. Discovery and requirements (typically two to four weeks)

Purpose. Document how work runs today and what “better” must mean.

Deliverables. Process maps for priority chains (order-to-cash, procure-to-pay, inventory, project accounting), requirements register with must/should/could, integration inventory, data-quality profile, measurable success criteria.

Failure mode. Compressing this into a single call. Scope surprises then land in build, where they are expensive.

3. Solution design (typically three to five weeks, can overlap discovery)

Purpose. Translate requirements into a buildable design that prefers standard product over custom code.

Deliverables. Solution design document, module and app map, integration architecture, customization register with business justification, security roles outline, reporting list for day-one vs later, UAT scenario outline.

Discipline that saves money. Adopt standard functionality unless a requirement is a true differentiator. Every bespoke build becomes permanent tax on upgrades, testing, and support — a pattern long-time operators still warn about when teams customize the ERP to legacy habits instead of simplifying the process.

4. Build and configuration (typically four to eight weeks for a focused mid-market scope)

Purpose. Configure modules, build only approved customizations, and prove integrations in a non-production environment.

How strong teams work. Short, reviewable increments. Functional leads validate as you go, not only at the end. AI-assisted tooling in 2026 can compress documentation, test scripts, and standard config work; it does not replace architectural judgment or ambiguous requirement resolution. Senior consultants still own decision points.

At Flectic, accelerated delivery is structured that way: AI shortens build work; senior consultants remain accountable for scope and quality. A first usable phase in eight to twelve weeks is realistic for focused scope — not for “everything everywhere” multi-module launches.

5. Data migration (parallel from early discovery through cutover)

Purpose. Move trusted masters and balances into the new system with evidence, not hope.

Workstream, not afterthought. Profile and cleanse legacy data, map fields, run multiple trial migrations, validate with data owners, reconcile financial balances before sign-off. Start cleansing while design is still open. Dirty data is one of the most common causes of go-live slip across mid-market guides published in 2025–2026.

Exit criteria. Signed reconciliation packs for critical masters and balances; known exceptions documented with owners.

6. Testing: SIT and UAT (typically three to five weeks, longer if integrations are heavy)

Purpose. Prove the system works as a chain, then prove users can run the business.

SIT. Modules and integrations work together under controlled scripts.

UAT. Real users run end-to-end business scenarios. Defects logged with severity. Formal exit based on residual risk — not on the calendar date marketing wanted.

Training. Role-based, not “everyone sits through every module.” Superusers embedded in each department. This is inseparable from ERP change management: people adopt processes under load, not slide decks.

7. Cutover and go-live (typically two to four weeks of intense prep around a go-live window)

Cutover choices.

• Big bang — entire organization switches on one date. Cleaner long term; highest weekend risk. Fits smaller or single-site scopes.
• Phased — by module, site, or process. Contains risk; temporary dual-process cost. Common for mid-market.
• Parallel — old and new run together for a period. Maximum safety, maximum cost and staff load.

Must exist before go-live weekend. Scope freeze, final migration runbook, communications plan, support roster, severity definitions, rollback criteria even if you never use them. Go/no-go is a business decision led by the sponsor with consultant evidence — not a sales milestone.

8. Hypercare and post-go-live (plan two to twelve weeks of elevated support; complex programs often thirty to ninety days)

Go-live is a milestone, not the finish line. Hypercare is structured stabilization: daily triage, business-led prioritization, visible metrics, and decision-makers who can approve fixes without waiting for the next steering cycle. Independent firms such as Panorama Consulting stress that hypercare fails when it is treated as a generic ticket queue instead of operational control by workstream (finance, order-to-cash, procure-to-pay, inventory, reporting, security and interfaces).

What hypercare should include.

• Daily stand-up for the first one to two weeks, then taper.
• Severity model in business language (revenue risk, customer impact, close disruption).
• Floor or virtual superuser support so users do not invent shadow spreadsheets on day three.
• Workstream checklists: opening balances and posting integrity; order and invoice flow; PO–receipt–invoice matching; inventory movements; report trust; access and interface health.
• Clear exit criteria into steady-state support (stable close, backlog trend down, adoption thresholds met).

Many engagements still hand you a PDF and a support email at go-live. A better model funds hypercare and early optimization inside the original scope — or at least prices it before cutover so it is not an ambush SOW. After stabilization, optimizing ERP after go-live is where reporting, automation, and AI features actually pay off.

Client vs consultant RACI (who really owns what)

Blurred ownership is how engagements stall. Use a simple RACI and enforce it in steering minutes.

Executive sponsor (client — Accountable). Business case, budget protection, escalations, go/no-go authority.

Client project manager (client — Responsible for internal delivery). Calendar, stakeholder attendance, decision turnaround, internal change communication.

Consulting engagement lead / solution architect (consultant — Responsible for delivery quality). Methodology, design integrity, configuration standards, risk surfacing, cutover readiness assessment.

Functional consultants (consultant — Responsible). Workshops, configuration, unit testing, defect fix for their areas.

Functional leads / process owners (client — Accountable for process truth). Confirm as-is and to-be, sign design, own UAT scenarios and acceptance.

Data lead (client — Accountable for data quality; consultant supports). Cleansing decisions, master-data standards, reconciliation sign-off.

Change / training lead (often client with consultant support). Role maps, training plan, adoption metrics, hypercare floor support.

Steering committee (joint — Accountable for scope and risk). Approve change requests, re-baseline timeline, accept residual risk at go-live.

What the client must never outsource entirely. Process decisions, data ownership, and “definition of done.” Consultants facilitate; they cannot know your exception logic better than your controllers and operations managers.

What the consultant must never hide. Capacity assumptions, offshore vs senior staffing after kickoff, and the real impact of every “yes we can” customization. If the seller disappears after signature and juniors own design, expect rework.

For partner evaluation on Dynamics programs specifically, the Business Central implementation partner guide complements this engagement view.

Duration benchmarks by complexity

Use ranges, not promises. Overlap is normal; the sum of phases is not the calendar if streams run in parallel.

• Simple / focused cloud scope (core financials, limited integrations, clean data): often about ten to sixteen weeks kickoff to go-live when decisions are fast.
• Mid-market / moderate (financials plus inventory or light manufacturing, a few integrations, moderate data cleanup): commonly four to nine months.
• Complex (multi-entity, multi-currency, heavy custom, many integrations, phased sites): twelve to twenty-four months or longer for full scope; still better as phased value releases than one big-bang fantasy.

What actually moves the calendar.

1. Scope and module count.
2. Customization volume.
3. Data quality.
4. Client decision latency and key-user availability.
5. Third-party integration owners who are not on your payroll.

If a proposal quotes under eight weeks to a production multi-process system with dirty data and no client PM, treat it as marketing. If it quotes eighteen months for a single-entity standard finance rollout, treat it as padding or under-resourcing.

Risk register: signals to watch from week one

Keep a living risk list. Review it every working-group meeting. Typical mid-market risks:

• Unwritten scope. Verbal “we’ll include that” items that never hit the SOW.
• Platform-first selling. Solution chosen before requirements.
• Key-person dependency. One superuser or one consultant carries the design.
• Data denial. “We’ll clean it later” until trial migration fails.
• Testing theater. UAT without real scenarios or without exit criteria.
• Change underfunded. Training cut to protect budget; adoption dies after go-live. Public commentary and consulting research still put a large share of ERP programs off plan on time, budget, or outcomes when people and process work is treated as optional — often cited in the fifty-plus percent range depending on source and definition of failure.
• Hypercare as afterthought. No daily triage model, every ticket “critical,” business owners unclear.
• Heroics as a plan. Overtime-only delivery that burns the team before month three of live operations.

Mitigations are boring and effective: written baselines, change control, multiple trial migrations, business-severity defect triage, and a hypercare roster named before cutover.

Platform choice sits inside the engagement — not above it

Dynamics 365 Business Central is often the stronger fit when complex financial reporting, Microsoft ecosystem depth, or later Field Service / Sales layering matter. Odoo often wins when broader operational coverage at lower total cost is the priority — supply chain, manufacturing, marketing, and related apps.

Neither answer is free of methodology. Dynamics partners lean on Microsoft-aligned frameworks (Sure Step heritage and Success by Design practices). Odoo partners lean on gap analysis, a strong single point of contact, and iterative implementation cycles described in Odoo’s own methodology materials. The engagement quality matters more than the logo if discovery and hypercare are weak.

The ERP selection path walks the decision in depth. Short version: if the CFO owns the pain, Business Central frequently leads; if the COO or VP of Operations owns the pain, Odoo’s operational breadth often makes more sense — after requirements are mapped.

Questions to ask before you sign

These separate firms that can deliver from firms that can sell.

Who owns the project after kickoff? Name the engagement lead. Confirm they review design decisions. Ask what percentage of build hours are senior vs junior or offshore.

What does phase one deliver, and in which week range? Demand named deliverables and exit criteria, not “agile collaboration.”

How are scope changes priced and approved? Documented change control, or silent accumulation until invoice day.

When does data migration start, and how many trial loads are planned? One load at the end is not a plan.

What does hypercare include, for how many weeks, with what staffing? Daily triage? Business workstream owners? Exit criteria?

How is change management funded? Ten to fifteen percent of implementation effort toward communication, training, and adoption is a common planning benchmark in serious programs; zero is a red flag.

Show me an engagement of similar size and industry. Specifics beat generic logos.

How AI changes the engagement in 2026 — and what it does not

AI has compressed parts of build: standard configuration assistance, documentation drafts, test script generation, mapping suggestions. That can shorten timelines and lower pure labor cost when firms pass efficiency through.

AI has not replaced:

• Scope judgment and trade-off calls.
• Process redesign politics.
• Data ownership and reconciliation sign-off.
• Cutover risk decisions.
• Accountability when production breaks on Monday morning.

Ask how AI changes your timeline and cost, not what the marketing name of the copilot is. If the story is “same price, more junior staff, magical AI,” you are funding their margin, not your speed.

For a grounded view of AI in delivery practice, see AI in ERP at Flectic.

What a healthy engagement feels like

You know the engagement is healthy when the consultant pushes back on requests that will create downstream pain — not to be difficult, but because they understand your processes well enough to protect the design.

You know it is unhealthy when every request is “yes,” followed by a change order, or when steering meetings become status theater without open risks.

The best engagements feel like a senior operating partner who knows Business Central or Odoo deeply, forces clarity early, and is still reachable in hypercare when finance finds the exception that UAT never covered.

That is what ERP consulting should look like from kickoff to go-live: a governed path of deliverables and decisions — not a software install with a kickoff call attached.

If you want a structured view of what an engagement would look like for your company size and stack, Flectic’s ERP services and free discovery conversations are the practical next step — no obligation to proceed.

Frequently asked questions

What does an ERP consulting engagement typically look like from kickoff to go-live? Kickoff sets governance, RACI, and success metrics. Discovery and design lock processes, modules, integrations, and acceptance criteria. Build and parallel data migration produce a working non-production system. SIT and UAT prove technical and business readiness. Cutover switches production under a runbook. Hypercare stabilizes operations for weeks afterward. Mid-market programs commonly span four to nine months; focused first phases can complete in roughly eight to twelve weeks when scope and data are ready.

What deliverables should each phase produce? Kickoff: RACI, plan, RAID log, success metrics. Discovery: process maps and requirements register. Design: solution design, integration architecture, customization register. Build: configured environments and integration builds. Migration: trial loads and reconciliation packs. UAT: signed scenarios and residual-risk log. Cutover: runbook, go/no-go decision, communications. Hypercare: daily triage metrics and exit to steady-state support.

Who owns decisions — client or consultant? Clients own process truth, data quality, and go/no-go. Consultants own methodology, configuration quality, and facilitation. Steering owns scope and budget trade-offs. If the consultant is deciding your chart of accounts without finance sign-off, governance is broken.

How long should hypercare last? Plan at least two to six weeks of elevated support for simpler scopes; many mid-market and complex programs need four to twelve weeks, sometimes thirty to ninety days. Duration should be driven by operational risk and adoption capacity, not by a minimum line item in a proposal. Exit when severity-one issues are rare, close can complete, and users stop inventing parallel processes.

What is the difference between UAT and hypercare? UAT is pre-go-live proof under controlled scenarios. Hypercare is post-go-live stabilization under real volume, time pressure, and exception chaos. Passing UAT does not eliminate hypercare; it only reduces how severe hypercare should be.

Big bang or phased go-live? Small, single-site, clean-scope programs can use big bang carefully. Mid-market multi-process programs usually phase by module, site, or process to contain risk. Parallel run is safest and most expensive. Choose based on risk appetite and staffing, not on vendor preference alone.

How does ERP consulting differ from “implementation services” on a price sheet? Implementation services can mean configuration hours only. A consulting engagement should include discovery judgment, design trade-offs, risk management, change support, and post-go-live accountability. If the SOW is silent on those, you bought labor, not an engagement.

What budget range should SMEs expect? Project-based mid-market consulting often lands roughly in the tens to low hundreds of thousands of dollars depending on scope, platform, integrations, and data quality — with implementation services frequently the largest line after software. Quotes far below that range usually cut scope, seniority, testing, or hypercare. Quantify the cost of the current mess first so the investment has a denominator.

How do I prepare before kickoff? Name a sponsor and client PM, free key-user time, start data profiling, list integrations and reporting must-haves, and read a practical readiness sequence such as the 90-day ERP readiness playbook. Firms can accelerate configuration; they cannot invent clean masters or executive attention you never allocated.