ERP implementation changes how people do their work as well as where records are stored. Start by agreeing who approves purchases, changes stock, and corrects mistakes. Those decisions should shape configuration and testing, not wait until training.
Use this checklist as a control record. Assign an owner and evidence to each item, mark dependencies, and define exit criteria for every phase. Remove items that genuinely do not apply, but do not silently treat them as complete.
Related service: CRM, ERP & Web Application development- 01Establish governance and measurable scope.
- 02Map processes, roles, controls, and reports.
- 03Design environments, data, integrations, and extensions.
- 04Configure or build in reviewable increments.
- 05Migrate and test with increasingly realistic data.
- 06Rehearse cutover, train users, and make the go/no-go decision.
- 07Monitor production and transition to owned support.
SECTION 01
1. Governance, outcomes, and scope
Name an executive sponsor, accountable product owner, process owners, technical lead, data owner, security owner, test lead, change lead, and cutover manager. One person may hold several roles in a small organization, but each responsibility must still be explicit.
Define what the release changes and what it does not. Tie each requirement to an operational outcome and acceptance test. Keep a decision log, dependency register, risk register, and controlled backlog. A new request should show its impact on data, integrations, tests, training, schedule, and budget before approval.
SECTION 02
2. Solution, environment, and security design
Document modules, extensions, integration patterns, environments, deployment path, identity, roles, logging, backups, retention, and recovery. Decide which system owns every shared record. The design should explain how a failed sync is retried, reconciled, or handled manually without duplicating a transaction.
Keep development, test, training, and production responsibilities distinct. Use production-like roles and representative data in acceptance environments while protecting sensitive records. Review least privilege and segregation of duties with process owners; generic administrator access is not a substitute for a role model.
Source of truth
Name the owner for customers, items, prices, inventory, orders, invoices, and identity.
Environment path
Define how tested configuration and code move forward without manual drift.
Permission model
Test read, create, approve, export, correct, and administrative capabilities by role.
Operational visibility
Capture integration failures, processing delays, security events, and business exceptions.
SECTION 03
3. Data migration and integration readiness
Profile the source data before promising a migration date. Identify duplicates, missing identifiers, inconsistent units, invalid statuses, unmatched references, dormant records, and fields without an accountable owner. Decide which history is required for operations, audit, service, or reporting.
Run extraction, transformation, load, and reconciliation several times. Record row counts and control totals; sample important records with business owners; verify open transactions and balances; and measure whether the cutover can finish inside the available window. Treat each rehearsal as a chance to improve scripts and runbooks.
| Data set | Owner | Validation | Cutover rule |
|---|---|---|---|
| Customers and suppliers | Master-data owner | Identity, duplicates, addresses, tax/status fields | Freeze or controlled delta |
| Items and pricing | Product/pricing owner | Units, variants, effective dates, price rules | Approved version only |
| Open orders | Operations owner | Lines, allocations, status, totals | Reconcile both systems |
| Balances and open finance | Finance owner | Control totals and account mapping | Formal sign-off |
| History | Compliance/process owner | Completeness, retention, retrieval | Migrate or archive explicitly |
SECTION 04
4. Testing, acceptance, and training
Build tests from end-to-end processes, not isolated screens. Cover unit or configuration checks, system integration, security and role tests, migrated-data regression, performance, recovery, and user acceptance. Include happy paths, edge cases, correction flows, and external dependencies.
User acceptance is evidence that users, processes, and the solution can operate together. Give participants recognizable data and day-in-the-life scenarios. Track defects with severity, owner, target resolution, retest result, and release decision. Training materials should match the approved release rather than an earlier prototype.
- 01
Trace tests to approved requirements and processes.
- 02
Prepare production-like roles, data, integrations, and volume.
- 03
Run system integration and migration tests before UAT.
- 04
Record defects and retest evidence.
- 05
Obtain process-owner sign-off against explicit exit criteria.
SECTION 05
5. Cutover, go-live, and support checklist
Rehearse the complete cutover: final extraction, transformation, load, validation, configuration promotion, integration enablement, user activation, communication, and rollback or continuation decision. Assign timestamps, owners, dependencies, verification steps, and escalation contacts.
Before go-live, confirm support coverage, issue intake, monitoring, backups, recovery, vendor escalation, administrator access, knowledge transfer, and ownership of remaining defects. After launch, compare business controls and volumes with expected baselines. Close the project only after support ownership is accepted.
SECTION 06
Frequently asked questions
What is the first step in an ERP implementation?
Establish accountable governance and map the in-scope end-to-end processes, outcomes, exceptions, data, roles, and exclusions before configuring the product.
How many ERP migration test runs are needed?
There is no universal number. Repeat until scripts are stable, reconciliation passes, defects are understood, and the complete cutover reliably fits the approved window.
What should ERP user acceptance testing include?
Use realistic roles, migrated data, integrations, reports, happy paths, edge cases, corrections, and day-in-the-life processes tied to approved requirements.
Who makes the ERP go-live decision?
The agreed governance group should decide from evidence supplied by business, technical, data, security, test, change, and support owners—not from schedule pressure alone.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Dynamics 365 implementation guideMicrosoft Learn
- Test your Dynamics 365 solution before deploymentMicrosoft Learn
- Go-live readiness checklistMicrosoft Learn
- Environment strategy guidanceMicrosoft Learn
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy