Introduction
ERP implementations fail not because of bad software, but because of bad planning.
Companies that skip preparation, rush vendor selection, underestimate data migration complexity, or overlook change management often end up over budget, past deadline, and with a system their team resents using.
The good news: most of these failures are preventable. This checklist walks through 15 concrete steps you should complete before signing a contract and before your implementation partner begins day one.
This isn't theoretical. These steps reflect what works in real implementations—both the practices that deliver results and the shortcuts that create problems down the road. At Modax Consulting, we've used variations of this framework across dozens of Dynamics 365 implementations, and it's the foundation of what we call the Modax ProWay methodology.
Phase 1: Preparation & Assessment (Steps 1–5)
Step 1: Define Your Business Case
Document why you're implementing ERP. Not the generic "we need better visibility" answer, but the real business drivers.
Are you consolidating fragmented systems (QuickBooks plus a separate inventory tool)? Improving cash flow visibility across locations? Enabling revenue growth through e-commerce or geographic expansion? Reducing manual processes like a monthly close that takes 5 days? Ensuring compliance with audit trail requirements or tax reporting?
Your business case justifies the project cost and timeline. When the implementation gets difficult (and it will), your business case reminds leadership why the investment was necessary. It also helps your implementation partner prioritize features correctly.
Deliverable: One-page business case document signed by CFO/COO and CEO.
Step 2: Assess Your Current State
Map your current systems, data, and processes honestly. Don't sanitize this. Include the workarounds, shadow databases, and manual steps that actually happen day-to-day.
Document every system currently in use (accounting, inventory, CRM, HR), the number of users and concurrent transactions by process, data volume (customers, SKUs, transactions per month), critical integrations (payment processors, banks, third-party tools), current pain points, compliance requirements, and known data quality issues like duplicate customers or inconsistent account coding.
This inventory becomes your migration roadmap. It also reveals scope creep before it happens. If you discover you're running 47 different cost center codes across your business, you'll deal with that complexity during implementation planning, not after.
Deliverable: Current state assessment document with system diagram, data inventory, and critical processes listed.
Step 3: Identify Your Core Team
Assign dedicated people to the implementation who represent each major business function. These people will be your "power users"—they'll configure the system, test it, and train everyone else.
Your team should include a Finance lead (Controller or accounting manager who owns GL, AP, AR, cash flow setup), an Operations lead (COO or operations manager who owns processes and go-live readiness), an IT lead (infrastructure owner or CTO who owns integrations and security), Business Function Leads (one per major process area like inventory, manufacturing, or projects), and an internal Project Manager. That last role is critical: your PM should represent your interests, not the vendor's—those interests might not always align.
ERP implementations are 70% people and process, 30% technology. Your core team must be released from normal duties during implementation, not running "ERP on the side while managing quarter-end close." Too often, implementations fail because the project owner is spread too thin to give the ERP the attention it demands.
Deliverable: Project team roster with names, roles, estimated time commitment (15 to 25 hours per week typical), and sign-off from their functional leaders.
Step 4: Build Your Requirements Document
Create a structured list of what your business needs from the ERP. Not software feature lists—business requirements.
Organize requirements by functional area. Under Accounting and Finance, cover automated journal entries, multi-entity consolidation, foreign exchange handling, intercompany billing, and real-time bank reconciliation. Under Inventory and Supply Chain, address lot and serial number tracking, FEFO or FIFO logic, perpetual or periodic inventory, multi-warehouse transfers, and landed cost allocation. Under Operations (manufacturing, projects, service), include bill of materials management, work order costing, resource scheduling, project accounting, and quality management workflows. Under Integrations, identify which systems must connect and data sync frequencies. Under Compliance and Audit, define audit trail requirements, role-based access control, data retention policies, and regulatory reporting needs.
A solid requirements document prevents scope creep during implementation. It also gives you a clear basis for vendor evaluation. If your requirements say "FEFO lot tracking is required" and a vendor doesn't offer it natively, that's a deal-breaker you discover early, not six weeks into implementation.
Deliverable: 10 to 20 page requirements document organized by functional area. Nothing longer—if you need 50 pages, you're over-specifying.
Step 5: Establish Your Budget & Timeline
Build a realistic budget that covers all the real costs. Software licensing typically represents 10 to 20% of total budget. Implementation services (your partner's labor) are the largest expense at 50 to 65%. Infrastructure (cloud hosting, network, security, integrations) runs 5 to 10%. Internal resources (your team's time during implementation) account for 5 to 15%. Training and change management take 5 to 10%. And you need 10 to 15% contingency for unknowns—because there are always unknowns.
For timeline expectations: small businesses under 50 users at a single location typically go live in 8 to 16 weeks. Mid-market companies (50 to 300 users, 2 to 5 locations) need 16 to 28 weeks. Complex implementations with multi-entity requirements, heavy customization, or legacy data often run 28 to 52 weeks.
These are realistic. "3-month implementations" for mid-size companies are either incomplete or under-specified. On platforms like Dynamics 365 Business Central, 8 to 12 week implementations are achievable for straightforward deployments—but only when both the partner and the client execute the preparation steps above.
Deliverable: Budget spreadsheet approved by CFO; timeline roadmap approved by CEO and key stakeholders.
Phase 2: Vendor Selection (Steps 6–8)
Step 6: Create a Vendor Shortlist
Narrow your options to 2 to 3 vendors based on your requirements, not hype or logo value.
Evaluate on functional fit (does the platform handle your core requirements out of the box?), implementation timeline, pricing transparency (can they quote fixed fees?), reference customers similar to your size and industry, partner ecosystem availability in your region, and vendor financial stability.
Evaluating 10 vendors wastes time. A focused shortlist of 2 to 3 vendors—based on functional requirements, not RFP responses—accelerates selection and surfaces decisions faster. For most SMBs, that shortlist almost always includes Dynamics 365 Business Central for its speed-to-value and Microsoft ecosystem integration.
Deliverable: Shortlist document (1 to 2 pages per vendor) with functional fit assessment, pricing range, and implementation partner options.
Step 7: Request Proposals & Do Reference Calls
Get written proposals from your shortlist. Then call 3 to 5 reference customers from each vendor—not vendor-provided references, but customers you find yourself through your network.
Ask references: How long was your implementation, and did it stay on schedule? What surprised you? What would you do differently? How responsive is vendor support post-go-live? Would you recommend this vendor to someone in your situation? What's the user adoption curve?
Vendor demos are sales pitches. Reference calls tell you what actually happens on the ground. A vendor might claim 12-week implementations, but if three reference customers say theirs took 24 weeks, that's your real data point.
Deliverable: Proposal summaries plus reference call notes. Common themes should emerge quickly.
Step 8: Negotiate & Sign Contracts
Before signing, lock in fixed-price implementation scope (with clear change order process), timeline and milestones, post-go-live support (typically 30 to 90 days intensive then transition to SLA-based support), training hours and documentation, data migration responsibilities, and success criteria (what does "go-live" actually mean?).
Watch for red flags: "implementation scope is flexible" (it's not—define it now), pricing tied only to software licensing with no implementation detail (watch for surprise bills), no defined timeline or milestones, or requests for 50%+ payment upfront.
Deliverable: Signed contract plus statement of work with defined scope, timeline, pricing, and success criteria.
Phase 3: Detailed Planning (Steps 9–11)
Step 9: Create Your Data Migration Plan
Map out which data migrates from old systems to the ERP, and how. Decide what migrates (GL balances, all transaction history or just open items, customer master, inventory quantities), how much historical data to bring (last 3 years? 7 years?), whether to use a "big bang" cutover or phased approach, and whether to clean data during migration or migrate as-is.
Data migration is the number one reason implementations slip. Poor data equals poor system output. The promise of "we'll fix the data after go-live" never materializes—users are already live and dealing with daily operations.
Budget 4 to 8 weeks and a dedicated data person for this phase. On Dynamics 365 platforms, tools like RapidStart (for Business Central) and Data Management Framework (for Finance & Operations) streamline the process, but they still require clean source data and careful mapping.
Deliverable: Data migration plan including data sources, mapping, cleanup approach, cutover strategy, and timeline.
Step 10: Design Your Configuration & Customization Strategy
Decide what you'll configure in the ERP using built-in features versus what you'll customize through code.
Configuration is the healthy path: setting up GL account hierarchies, defining approval workflows, configuring user roles, setting up tax rules, defining inventory valuation methods. Customization is the expensive path: custom fields, custom reports, custom business logic, custom integrations.
The rule of thumb: aim for 80% configuration, 20% customization. If you're looking at 50%+ customization, you've probably picked the wrong vendor. This is one reason configuration-driven approaches matter. Platforms and extensions that let you achieve specialized behavior through setup—rather than code—keep implementations faster, cheaper, and easier to maintain long-term.
Deliverable: Configuration and customization roadmap.
Step 11: Plan Change Management & Training
Build a structured plan for communicating the change, training users, and supporting adoption.
Your communications plan should address when users find out about the project (early is better), how you handle fears about job security or changing metrics, how you celebrate post-go-live wins, and regular update cadence (weekly is typical).
For training, use a layered approach: super-user training first (your core team learns and becomes internal trainers), then role-based training (each user learns workflows relevant to their job), timed just-in-time (1 to 2 weeks before go-live when it's fresh), with post-go-live help desk and office hours.
Track success metrics: user adoption rate by role 30 days post-go-live, system stability and bug fix velocity, and process efficiency gains like monthly close cycle time.
Deliverable: Change management and training plan with communication calendar, training schedule, and success metrics.
Phase 4: Implementation & Execution (Steps 12–15)
Step 12: Run a Pilot Build
Before deploying to all users, run a 2 to 4 week Pilot Build to validate configuration, test data migration, and surface issues early.
Scope the pilot around one complete end-to-end process (order-to-cash, procure-to-pay, or plan-to-produce). Include 10 to 20 power users from the core team working in a sandbox environment. The goals are to validate configuration, identify missing features, test data migration quality, and catch change management gaps early.
A pilot catches mistakes when they're cheap to fix. Finding a data migration issue during Pilot Build takes 1 day to fix. Finding it after go-live takes 10 days and causes fire drills.
This is core to the Modax ProWay approach—every implementation we manage includes a structured Pilot Build phase before any production deployment. It's the single most effective risk reduction technique in ERP implementation.
Deliverable: Pilot Build summary with configuration lessons learned, data quality findings, and user feedback.
Step 13: Refine Based on Pilot Feedback
Incorporate lessons from the pilot. Configuration adjustments, workflow tweaks, role assignments, data quality fixes, and training material updates all happen here.
The key principle: adapt business processes to fit the system, not the reverse. When the pilot reveals that a current process doesn't map cleanly to the ERP, the right answer is usually to adjust the process. Customizing the ERP to match legacy processes creates maintenance debt you'll carry for years.
Deliverable: Pilot feedback summary and refinement plan.
Step 14: Execute Full Data Migration & Final Testing
Perform full data migration into the production environment. Then run parallel testing: old system and ERP side-by-side, with users verifying that outputs match.
Your testing checklist should confirm that financial accounts balance (GL matches old system), customer and vendor masters are accurate, open transactions migrated correctly, inventory quantities are accurate by location and lot/serial where applicable, historical reports reproduce correctly, and integrations are working (payment processors, bank feeds, EDI connections).
Allocate 3 to 4 weeks for parallel testing. Users should test their actual workflows with real data, not sample data. Have someone dedicated to logging and triaging test issues.
Deliverable: Testing summary report with sign-off from Finance (GL balances confirmed) and Operations (inventory, orders, key processes accurate).
Step 15: Go-Live & Immediate Post-Go-Live Support
Switch users to the ERP with the implementation team on-site or on-call for intensive support.
The go-live sequence: day before, load final production data, run final tests, back up the old system, and brief users. Day of, cut over and monitor stability with the vendor team available. Days 1 through 7, intensive monitoring and real-time troubleshooting. Weeks 2 through 4, shift from crisis mode to normal operations as users get comfortable. Months 2 through 3, the vendor reduces presence and focus shifts to optimization. Month 3 onward, transition to standard support SLA.
Success criteria: users can complete core processes in the new system, GL balances correctly, month-end close completes on schedule, no critical functionality gaps forcing workarounds, and 80%+ active user adoption in their functional areas.
Go-live is not "launch and walk away." The first 30 days determine success or failure.
Deliverable: Go-live checklist, post-go-live support plan, success metrics tracking.
Common Mistakes to Avoid
Scope Creep is the silent killer. "While we're implementing, let's add this extra feature" sounds harmless, but every change request adds weeks and cost. An additional two-week scope change becomes a four-week delay when compounded with testing and training adjustments. Prevent it with a change control board—any scope change requires written approval with explicit timeline and budget impact.
Insufficient Testing creates go-live disasters. Edge cases and errors that didn't appear in the pilot emerge when real volume hits. "Users will figure it out" is not a testing strategy. Allocate 3 to 4 weeks for parallel testing with actual workflows, not sample data.
Ignoring Change Management is the most common failure mode we see. Technical cutover happens on schedule, but users aren't ready because training was last-minute and communications were sparse. Users resist change—without active change management, they work around the ERP using spreadsheets and shadow systems, which is exactly what you were trying to eliminate.
Poor Data Quality undermines everything. Data migrated as-is without cleanup means bad data in, bad decisions out. Users lose confidence in the system. Allocate 4 to 6 weeks specifically for data cleanup during planning.
Weak Project Governance lets projects drift. No clear owner, decisions that take weeks, stakeholder alignment that's assumed rather than confirmed. Assign a single project sponsor (usually COO or CFO) with decision-making authority, and establish weekly steering committee meetings.
Timeline: What to Expect
For a typical mid-market company (100 users, single location), a realistic 24-week implementation follows this pattern: Weeks 1 through 4 focus on assessment and planning—requirements, current state analysis, vendor selection, and contracting. Weeks 5 through 8 cover detailed planning—data mapping, configuration design, training plans, and change management setup. Weeks 9 through 16 are the build phase—core configuration, customizations, data migration setup, and pilot preparation. Weeks 17 through 19 are Pilot Build—running the pilot, gathering feedback, refining configuration and training. Weeks 20 through 22 cover testing and migration—full data migration, parallel testing, final adjustments. Weeks 23 through 24 and beyond are go-live and stabilization.
On Dynamics 365 Business Central, straightforward implementations for smaller companies often compress this to 8 to 16 weeks. The platform's configuration-first design and strong partner ecosystem (including methodologies like Modax ProWay that build on Microsoft Sure Step) make this acceleration possible without cutting corners.
Final Thoughts
ERP implementations succeed when they're treated as strategic business projects, not IT projects. That means leadership commitment, dedicated team members, serious data cleanup, active change management, and collaborative vendor partnerships.
The 15 steps above aren't theoretical. They're the difference between implementations that deliver value and implementations that frustrate teams and underdeliver on ROI.
Ready to start planning your ERP implementation? Our team at Modax Consulting has managed dozens of Dynamics 365 implementations across Business Central and Finance & Operations. We use the Modax ProWay methodology—built on Microsoft Sure Step and refined through real-world experience—to deliver predictable, successful go-lives. Schedule a readiness assessment → and let's discuss your specific situation.