ERP Implementation Guide

ERP implementation is the project of selecting, configuring, integrating and rolling out one system to run finance, purchasing, inventory, sales orders, projects or manufacturing in place of the separate tools and spreadsheets that ran them before. It fails more often from unclear processes, dirty data and thin ownership than from the software. This guide lays out the ERP implementation steps in order, the two workstreams most teams underestimate (data migration and integration), the pitfalls behind most failed projects, and what smaller companies tend to get right. The examples use Dynamics 365 Business Central, Dynamics 365 Finance and Supply Chain Management and SAP S/4HANA, but the method applies to any cloud ERP software.

The phases of an ERP implementation

Every methodology (Microsoft’s Success by Design, SAP Activate, a partner’s own) is a variation on the same sequence. The names change; the order and the sign-offs do not.

Phase	What happens	Key outputs	Who signs off
1. Business case and requirements	Why now, which processes are in scope, what the current systems cost in time and errors, what good looks like	Scope statement, process list, measurable goals, budget range	Executive sponsor
2. Selection	Shortlist, scripted demos with your own scenarios, reference calls, total cost of ownership over several years, implementation partner choice	Platform decision, contract, partner statement of work	Sponsor and finance
3. Planning and governance	Project manager, process owners per area, steering cadence, phased or single cutover, change control	Project charter, plan, RACI, risk log	Steering committee
4. Design (fit-gap)	Walk each process through the standard system; record fits, gaps, and whether each gap is a configuration, an extension, a process change or a workaround	Fit-gap register, design documents, security roles, reporting list	Process owners
5. Build and configure	Configuration, extensions (AL for Business Central, X++ for Finance and Supply Chain, ABAP or BTP for S/4HANA), integrations, reports	Configured environments, extension code, integration specs	Project manager, technical lead
6. Data migration	Scope, cleanse, map, mock loads, reconcile (details below)	Migration plan, mapping, reconciliation reports	Finance and process owners
7. Testing	Unit, integration, user acceptance against real scenarios, performance, and a full cutover rehearsal	Test scripts, defect log, rehearsal timing, go-live checklist	Process owners, QA lead
8. Training and change	Role-based training, super users per department, documentation, communication of what changes for whom	Training records, quick guides, support model	Process owners, HR or operations
9. Cutover and go-live	Transaction freeze, final data load, reconciliation, go or no-go decision on agreed criteria	Signed reconciliation, go-live approval	Steering committee
10. Hypercare and support	Daily issue triage through the first month-end close, then transition to a support model and a backlog for phase two	Issue log, support agreement, phase-two scope	Sponsor

Two notes on the table. Phases 6 and 7 run as workstreams across most of the project, not as single blocks at the end; the first mock data load should happen during design, not after build. And phase 10 is where budgets run out: reserve money and people for the first close, because the first close is the real acceptance test.

At three sizes the shape differs. A twenty-person distributor moving from accounting software to Business Central can compress phases 1 to 4 into a few workshops and go live in one cutover. A 300-person manufacturer on Dynamics 365 Finance and Supply Chain usually phases by site or by process (finance first, then supply chain). A division inside a group on S/4HANA inherits a template and spends most of its effort on local requirements, data and change.

Data migration

Data migration is the workstream most teams schedule last and discover first. Treat it as its own project with its own owner, and follow these steps.

1. Decide what to bring. Master data (customers, vendors, items, chart of accounts, employees) always. Open items (open invoices, purchase orders, sales orders, inventory balances) always. Historical transactions rarely: keep them in a reporting database or the old system in read-only mode. Full history costs more, slows the project and imports old errors.
2. Profile and cleanse at the source. Duplicate customers, inactive items, vendors with no tax ID, addresses in free text. Fix them in the old system or in a staging database before mapping, using the rules described in our data quality management guide. Migration is the best cleansing opportunity you will ever get, because the business is paying attention.
3. Map field by field. Source field, target field, transformation rule, default value, owner. Expect the target to have required fields the source never had (posting groups, dimensions, units of measure) and decide them with the process owner, not the developer.
4. Load with the platform’s tools. Configuration packages for Business Central, the Data Management Framework for Dynamics 365 Finance and Supply Chain, the Migration Cockpit for S/4HANA. For complex transformations, stage in SQL Server with Azure Data Factory or SSIS and load from there.
5. Run at least three mock loads. The first finds the mapping errors, the second finds the cleansing gaps, the third is a timed rehearsal of the cutover sequence. Each one ends with reconciliation.
6. Reconcile and sign. Trial balance to the penny, open receivables and payables by customer and vendor, inventory quantities and values by location, record counts per entity. Finance signs the reconciliation before go-live, and the signed report is kept for the auditors.

Freeze master data changes in the old system for the days between final extract and go-live, and publish the freeze dates to everyone who creates customers, items or vendors. The alternative is a list of records that exist in one system and not the other on day one.

Integration

A new ERP rarely replaces everything. CRM, e-commerce, warehouse management, payroll, banking, EDI partners and reporting usually stay, and each needs a connection. Inventory the integrations during design, decide the pattern for each, and build them with the same discipline as the ERP itself.

Pattern	Use it when	Examples
Native connector	The vendor supplies one and it covers your fields	Business Central to Shopify, Dataverse dual-write between Dynamics 365 Finance and Dynamics 365 Sales, bank feeds
API integration	Two systems, a clear owner per entity, modest volume	A custom web portal reading orders and stock from Business Central APIs; a .NET service posting invoices to S/4HANA
Middleware or integration platform	Several systems, transformations, retries and monitoring needed	Azure Logic Apps, Azure Integration Services, Power Automate, SAP Integration Suite, Boomi
File or EDI exchange	Trading partners with fixed formats	EDI 850 and 810 documents with retailers; bank payment files
Data platform	Reporting and analytics across systems	ERP data landed in a warehouse or Microsoft Fabric and modeled for Power BI, so reports do not run against the transaction database

Four rules keep integrations from becoming the long tail of the project. One system owns each entity; the others read it or request changes. Every interface is idempotent, so a retry does not create a duplicate order. Failures land in a queue someone monitors, with alerts, and every integration has a test script in the cutover rehearsal, including the EDI partner that only sends on Tuesdays.

Where a legacy application must stay alongside the ERP for a while, the options for wrapping, replacing or retiring it are covered in Legacy System Modernization: 6 Approaches Compared.

Pitfalls that cause ERP failures

• Copying the old process into the new system. The project becomes an expensive way to keep doing what you did. Fix: design to the standard process first and justify each deviation in the fit-gap register.
• Over-customization. Every extension is yours to test and maintain through every update. Fix: a rule that customization needs a written business case and a named owner.
• Underestimating data. Dirty data arrives on schedule and stops the project. Fix: a data owner, early profiling and three mock loads.
• No process owners. Decisions bounce to the consultants, who guess. Fix: one named owner per process area with time allocated to the project.
• Testing cut to protect the date. Defects move from the test log to the month-end close. Fix: the rehearsal and user acceptance testing are go-live criteria, not optional.
• Training as a one-day event. People go back to spreadsheets. Fix: role-based training close to go-live, super users in each department, and quick guides for the tasks each role does weekly.
• No budget after go-live. The first close exposes everything the project deferred. Fix: reserve people and money for hypercare and a phase-two backlog.
• Reporting as an afterthought. Leaders cannot see the numbers they used to see. Fix: list the reports in design and build the data model alongside the ERP.

Small-company wins: what smaller teams get right

Smaller companies have a structural advantage in ERP projects. Decisions take one meeting, the owner of a process is usually also the person doing it, and there is less legacy to protect. The projects that go well lean into that: they pick a system sized for the next few years rather than the next twenty, keep extensions to a handful, migrate open items rather than history, and go live in one cutover with a rehearsal behind it. They also treat the ERP as the system of record from day one and switch the old spreadsheets off, which is the step larger organizations find hardest.

Where PS3G fits

PS3G provides ERP implementation and consulting for organizations of every size: selection, implementation, extensions, integration, data migration, training and support for Dynamics 365 Business Central, Dynamics 365 Finance and Supply Chain Management, SAP S/4HANA and other cloud ERPs. We describe ourselves as Dynamics 365 and SAP specialists rather than by partner status, and we are vendor-neutral in selection. What distinguishes the work is the engineering around the ERP: the .NET applications, APIs, data platforms and automation that most projects need and most ERP partners subcontract. A small company usually needs a fixed-scope implementation with a rehearsal; a larger one usually needs a phased program with a dedicated team; a stalled project needs an independent review first.

Related reading

• Legacy System Modernization: 6 Approaches Compared (and How to Pick)
• Data Quality Management: Dimensions, Rules, Tools and Process
• ERP implementation and consulting

Frequently asked questions

What are the ERP implementation steps in order?

Business case and requirements, selection, planning and governance, design (fit-gap), build and configure, data migration, testing, training and change management, cutover and go-live, then hypercare and support. Data migration and integration run as workstreams across most of the project rather than as single steps, and the first month-end close after go-live is the real acceptance test.

How long does an ERP implementation take?

It depends on the number of entities and sites, the processes in scope, the amount of customization and integration, and the state of your data. A single-entity Business Central rollout with few extensions is a matter of months; a multi-entity Dynamics 365 Finance or S/4HANA program runs in phases over a longer period. Any consultant who quotes a duration before seeing your data is guessing.

What is the difference between Business Central and Dynamics 365 Finance and Supply Chain?

Business Central is Microsoft’s ERP for small and mid-sized companies: finance, inventory, purchasing, sales, projects and light manufacturing, extended in AL. Dynamics 365 Finance and Supply Chain Management (formerly Finance and Operations) serves larger, multi-country or manufacturing-heavy organizations with deeper configuration and X++ extensions. Both are cloud ERP software on Dataverse and the Power Platform.

Should we migrate historical transactions into the new ERP?

Usually not. Migrate master data, open items and opening balances, and keep historical transactions in a reporting database or in the old system in read-only mode for lookups and audits. Full history migration costs more, extends the project and imports old errors. Decide per data category with finance, and document the decision for the auditors.

Do we need an ERP consulting partner, or can we implement it ourselves?

Small companies with a simple scope and a strong internal owner can implement Business Central or a similar system with vendor documentation and limited outside help. Most organizations benefit from ERP consulting for the parts they do once and the partner does often: fit-gap, data migration, integration and cutover rehearsal. The critical thing is that process ownership stays with you either way.