An ERP implementation partner helps translate your business requirements into a configured, tested, and supported system. The engagement may include process design, data migration, integrations, training, and cutover. Those responsibilities must be explicit in the proposal; the title alone does not guarantee them.
OPS provides ERP assessment, selection, and implementation services. This guide is our recommended buying framework, informed by the official implementation guidance linked below. It is not a ranking of suppliers or a claim that every project needs the same scope.
Buy a delivery plan, not a demonstration
A polished demonstration shows that a product can perform selected tasks. It does not establish that your data is ready, your controls are configured, your people can use the system, or a supplier will stay accountable after launch.
Microsoft's implementation strategy guidance treats process design, migration, integration, testing, security, cutover, and adoption as implementation work. That document concerns Dynamics 365 specifically. Its explicit work categories are useful questions for other ERP proposals, not a universal certification standard.
Ask candidates to explain what must change in the business, what stays standard, and what remains uncertain. A partner who identifies a genuine gap before contract signature is giving you useful information. A promise that every requirement is easy needs supporting evidence.
What the partner should deliver
Scroll to read all columns.
| Workstream | Evidence to request | Business responsibility |
|---|---|---|
| Requirements | A prioritized process and control register, with assumptions and exclusions. | Approve priorities and name process owners. |
| Solution design | A documented configuration and integration design. | Accept process changes and resolve policy questions. |
| Data migration | Mappings, cleansing rules, rehearsal results, and reconciliation. | Own source-data quality and financial sign-off. |
| Testing | Traceable cases, defects, exit criteria, and acceptance evidence. | Allocate users and approve readiness. |
| Adoption | Role-based training, administrator guidance, and support handover. | Make time for learning and assign ongoing owners. |
| Cutover | A timed plan, dependencies, rollback decisions, and escalation contacts. | Authorize the transition and business contingency. |
This is an OPS evaluation checklist. The actual division of work should be agreed for your project, including any separate integration, infrastructure, or change-management suppliers.
Evaluate the people who will do the work
Use this checklist with each shortlisted partner, and request the answers in writing.
- Name the delivery lead and the people responsible for functional design, integrations, testing, and training.
- Ask how the team will demonstrate knowledge of your accounting and operating processes.
- Confirm which work uses subcontractors, who controls their access, and who remains accountable.
- Ask how named-team substitutions are handled and who resolves disagreements between suppliers.
- Check product credentials and partner status, then request references from a comparable operating context.
- Ask references about migration, testing, unexpected scope, and support after launch.
Make migration and testing visible early
Data work is often hidden behind the phrase "we will import it." Ask what will be migrated, what will remain in an archive, and how balances, stock, open orders, and historical records will be reconciled. Your business owners need to understand the tradeoffs before a final cutover schedule is promised.
Microsoft's data migration guidance identifies discovery, mapping, transformation, loading, testing, and validation as planned activities. Use that as a reminder to ask for a rehearsal and an explicit sign-off method.
Testing must include real business paths and exceptions. A successful login or an invoice created with clean sample data is insufficient. The testing strategy guide distinguishes integration, system, acceptance, and regression testing and ties cases to business processes. Agree which tests your project needs and who accepts the results.
Compare contracts on the same basis
Require each bidder to list included entities, locations, users, modules, interfaces, migration objects, training, and support. If one proposal omits an integration or assumes your team performs all data cleansing, the totals are not comparable.
For fixed-fee work, inspect assumptions, acceptance milestones, and the change process. For time-based work, inspect estimates, reporting, budget controls, and the method for authorizing additional effort. Neither commercial model eliminates uncertainty. It should make uncertainty visible and manageable.
Ask what happens if a key assumption is wrong. Specify ownership of custom code and configuration, administrator access, documentation, and the practical handover if you change suppliers. Do not leave exit requirements until the relationship is under strain.
Define completion before the launch date
A date is not an acceptance criterion. Microsoft's go-live checklist includes acceptance, migration validation, external dependencies, change readiness, and operational support. Use these categories to agree what must be true before the system becomes the operating record.
Keep a defect register with the business impact, owner, workaround, and acceptance decision. Define the stabilization period, ongoing support owner, and escalation route before the project team steps back.
Common questions
Should we choose the software before the partner?
Start with requirements. You may evaluate platforms and delivery partners together, but do not let a partner's preferred product substitute for fit assessment. Use the same workflows when comparing Odoo and NetSuite.
Can one partner own everything?
Possibly, depending on capability and scope. Even then, your business retains decisions about priorities, policy, data quality, and acceptance. Document the responsibility split instead of assuming outsourcing removes it.
What is a warning sign in a proposal?
Unspecified migration, testing, support, or change control deserves investigation. Ask for clarification rather than assuming a low price includes those activities. A useful proposal makes both the work and its exclusions understandable.
Start with a clear brief
Bring OPS the current process problems, critical workflows, known data issues, and operational constraints. Our ERP Solutions practice can help frame requirements, compare approaches, and stay through implementation. The first decision is what the project must achieve, not which demonstration looks most complete.