Implementing an ERP system is a complex process that involves hundreds of people—both within the company and on the side of the implementation partner.
Experts consider it one of the most challenging projects a business can undertake, often compared to the construction of a new production facility.
Because of this, the implementation must be conducted in an organized manner, following established principles and—whenever possible—using standardized documentation templates. This structured approach is known as an ERP implementation methodology.
For Dynamics 365 for Finance and Operations, Microsoft recommends the Microsoft Dynamics Sure Step methodology.
Sure Step is based on standards established by the world’s largest project management organization, the Project Management Institute (PMI), and is also fully compatible with PRINCE2 practices.
Both PMBOK and PRINCE2 are methodologies for managing all types and sizes of projects. Microsoft Dynamics Sure Step, on the other hand, is a strictly standardised methodology for the implementation of a specific product family - ERP and CRM systems. Within it, there are several variations, depending on the size of the company and the approach chosen:
They differ in the number of tasks envisaged, documents, degree of formalisation, etc. In the remainder of this article, we will outline the basic tasks involved in a standard Microsoft Dynamics 365 for Finance and Operations (formerly AX) implementation project.
Our company has over 20 years of experience in the implementation of ERP management systems, during which it has completed over 100 projects. We have participated in projects of the most varied scale, from the rollout of an international implementation where 1 person worked in the Polish branch, to the implementation of multi-branch companies with dozens of production facilities in Poland and beyond with several hundred concurrent users. For many years we used our own methodology based on general standards for ERP implementation, and since the advent of Sure Step methodology we have relied on it. We have been involved in the implementations of many of the world's largest Microsoft Dynamics partners, from the DynamicsPact group and beyond, working to a wide variety of methodologies. All of this has taught us that it is important for the success of a project to be based on a standard, such as Sure Step, on the one hand, and on the other hand, to select from it those elements that will be most appropriate for a particular situation. The scope of the implementation, the size of the client and also its organisational culture must all be taken into account. Therefore, the methodology presented below should be considered as a starting point for discussion at the project organisation stage.
The Sure Step methodology divides implementation into five separate phases:
In the Analysis phase, detailed business process analyses are carried out. Consultants conduct a business process analysis workshop with members of the Implementation Team to document and model the future process flow.
This workshop is divided into two rounds:
The result of the business process analysis workshop is the Analysis Report. It includes, among other things, an inventory of the processes covered by the system, their target flow, information about the processes and an extended description of the requirements, where needed
During the Analysis phase, the most important set of activities is to collect and document the Customer's business requirements and conduct a Matching Analysis. The requirements are documented in a Matching Worksheet, which contains all of the federated requirements for the System, along with an assessment of which requirements require modification of the System. Requirements are documented during the Target State and Requirements Analysis workshop. The set of requirements collected after the workshop is the input to the Matching Analysis, performed by consultants. As a result of it, the Matching Sheet is updated with information on whether a given business requirement is met using the standard functionality of the System (“Fit”) or requires programming modifications (“Gaps”).
The goal of the Design Phase is to define how the identified business requirements will be implemented. This phase includes configuring the Microsoft Dynamics system and designing specific customizations necessary to meet the requirements gathered during the Analysis Phase. These customizations may range from simple user interface adjustments (e.g., form layouts) and report modifications to the development of complex new functionalities. This phase also involves designing integration mechanisms (interfaces) and required elements for data migration. The Design Phase is based on the deliverables produced during the Analysis Phase.
The purpose of Implementation Team training during the Design Phase is to increase the effectiveness of modeling workshops by educating team members who will actively participate in making implementation decisions, including new business process flows.
Participants undergo detailed training in relevant areas. Whenever possible, training is conducted using a preconfigured environment with sample company data. Where this is not feasible, a standard dataset is used.
After the training sessions, design workshops take place to review and update the business process models agreed upon during the Analysis Phase. At the same time, the Requirements List is updated to include any missing elements discovered during the training, following the established change management procedures.
During the Design Phase, configuration of the system’s standard functionalities begins, including the setup of supporting dictionaries.
Where possible, some of this configuration is completed prior to the training sessions in order to prepare a sample training environment. The remaining configuration is performed after the business process review workshops.
Configuration is carried out under the guidance of functional consultants, with the participation of key users—for example, by preparing and populating various data dictionaries.
For key decisions, a parameterization design is prepared and documented in the Functional Design Document (FDD)—for example, the number and structure of financial dimensions to be used.
During the design workshops, held after the Implementation Team training, identified functional gaps are reviewed. Where possible, the consultant presents alternative solutions or potential customizations. These are documented in the Functional Design Document and can also be detailed in follow-up sessions.
For more complex customizations, a Technical Design Document is prepared, outlining the technical aspects of the required development.
Where applicable, testing of standard system functionalities and additional modules is conducted. This involves unit testing of individual functions in areas where configuration is already in place.
If necessary, test scenarios for more complex customizations are created to support unit testing. These scenarios are included in the corresponding Technical Design Document.
For integration requirements identified in the Analysis Phase, a detailed design of integration components and interfaces is developed.
Functional Design Document (FDD): detailed target business process flows in the system, a list of organizational changes resulting from the implementation, data loading strategy for system go-live, proposed security roles and access levels
Technical Design Documents
Test Scenarios
Integration and Interface Design
The objective of the Preparation Phase is to build and test the system components, including custom developments and interfaces. The main deliverable of this phase is a fully configured system, including the implemented customizations and developed integration/interface code.
To ensure the system has been prepared in line with the design assumptions, data migration tests, process tests, and iterative testing are conducted. Test scenarios for performance testing and user acceptance testing are also prepared.
During this phase, the configuration of the standard system and any additional modules in the relevant area is completed. Final details of the new developments are agreed upon and documented as development requests. These requests must be approved by both Project Managers (Client and Partner side).
The Preparation Phase is the primary phase for development work, during which the customizations are implemented in accordance with the approved development requests. This includes both coding and unit testing of individual functions.
During the System Preparation Phase, training documentation is created. Depending on prior arrangements, specialized training materials are prepared. These materials often include recordings made using the built-in Task Recorder in Dynamics 365. The videos are accessible directly within the system, and based on them, step-by-step documentation can be generated in Word format. Not all instructions must be created as videos.
Additionally, Integris provides a standard training manual for general user training, which covers system navigation, filtering, tools, creating self-service reports, alerts, integration with Excel, and other general functionalities.
Next, key user training is conducted on the prepared system.
Once configuration and development are complete, Solution Testing is carried out. This includes testing business processes, integrations, and data migration (described in detail below). In this phase, User Acceptance Test (UAT) scenarios are also prepared. These scenarios will later be used to confirm the system supports standard business operations under realistic conditions.
Process testing is performed by the client’s key users, supported by consultants, to ensure that the system is prepared to execute processes as designed. An example would be testing the “Order-to-Cash” process. Testing is carried out in a test environment using sample client data.
Each key user participating in testing may have a different idea of how a specific functionality should work. Therefore, it's crucial that they familiarize themselves with the finalized designs from the Design Phase, as documented in the Functional Design Document (FDD). This helps distinguish real system errors from discrepancies between the designed functionality and individual expectations, which should be submitted through the change management process.
It’s important to be aware that some testers may approach the new solution with resistance or skepticism. Avoid confrontation and instead encourage open feedback and comments on the testing outcomes. Keep in mind that process testing is not performance testing, so an excessive number of users should not be involved at once.
Any functionality changes proposed during testing must be submitted through the established change management procedure.
The final goal of process testing is to confirm that the configured functionalities, along with any customizations, have been verified from a business perspective and that their operation is confirmed to be correct. Features that cannot be tested individually should be verified during integration testing.
Integration tests focus on end-to-end business processes. For example, this could include comprehensive testing of merchandise workflows such as Order-to-Cash and Procure-to-Pay. These tests are carried out by key users, supported by consultants, in a test environment with security roles enabled. It is important to have role-based access control in place during these tests, as user permission settings are also being validated.
The purpose of integration testing is to verify all aspects of the system, including all integrated components with external systems.
These tests validate whether migrated data can be used in standard processes (e.g., issuing invoices for imported customers and items). Any issues should be documented, but testing should continue despite errors for as long as feasible. This approach increases the efficiency of the defect resolution process.
Production-ready system for User Acceptance Testing
User Acceptance Test (UAT) scenarios
During the System Go-Live – User Acceptance Testing Phase, a trial launch of the system is performed. This phase includes final actions leading to the transition to the new Microsoft Dynamics system. It begins with key user training and user acceptance tests. After the completion of acceptance tests, a decision is made whether to proceed with go-live or postpone it until any critical issues are resolved.
Key activities in this phase include end-user training, final data migration, and the actual transition to the new production system. During this phase, the Go-Live Plan is finalized and executed, covering all necessary steps to enable the go-live. Key users prepare end-users for the system go-live and conduct their training. After acceptance testing is completed, the decision to proceed or delay go-live is made based on the resolution of critical problems.
The technical team prepares the production environment for go-live.
Once acceptance tests are finalized, data migration is carried out according to the data migration project schedule.
A final audit of the production environment is performed, along with the final approval of system readiness.
Another important activity in this phase is knowledge transfer, according to the plan established during the design phase.
End-user training is aimed at preparing users to work with Microsoft Dynamics. All training participants are required to familiarize themselves in advance with the relevant process descriptions. Key users, who conduct the training sessions, are responsible for ensuring this. This familiarization may also occur at the beginning of the training, where the key user explains how and why processes will be changing. Training should be conducted as close as possible to the production go-live to avoid knowledge erosion. Role-based training is recommended, allowing end-users to acquire knowledge that closely reflects their day-to-day responsibilities.
Key users prepare work instructions for end-users based on the documentation created by Integris in earlier project phases.
Due to the importance of training all employees who will work with the new system, it is necessary to schedule sessions and reserve sufficient time in advance. Participation in training is mandatory and must be documented. Participants should also have an opportunity to evaluate the training, e.g., through a training evaluation form.
The System Go-Live is the culmination of all project activities. Readiness is verified before go-live using a previously prepared checklist. The actual go-live is carried out according to the agreed plan. After go-live, any issues are reported through the agreed support procedure.
The following actions must be completed:
Post-go-live support planning
Definition of emergency contacts and escalation procedures
Completion of the end-user training plan – only trained users are permitted to work with Dynamics 365, especially in the early stages of production use
Organizing a Steering Committee meeting to approve the system go-live
Verification of the presence of all required customizations and interfaces
Preparation of data for the opening balance
Final data migration to the production environment typically consists of several stages:
Some data is entered manually during earlier phases (e.g., model groups, item groups, delivery terms)
Master data (e.g., chart of accounts, customers, vendors, item records) can be imported in advance. This data must be cleaned beforehand, meaning that client personnel review it to remove inconsistencies, fill in missing information, and improve overall quality.
Transactional data (e.g., open customer/vendor transactions, inventory levels) is imported as close as possible to the system go-live
Certain data, such as the opening balance of financial accounts, may be transferred after go-live
Once data is loaded into the system, the Client’s Project Manager ensures—based on feedback from key users—that all balances and data are correct. If the data is loaded and verified as error-free, the system is considered ready for go-live. Where possible, consultants should perform a cross-check using data from the legacy system.
A production-ready Microsoft Dynamics 365 for Finance and Operations system
The Operational Phase includes activities related to post-go-live support and project closure.
In the initial period, Integris consultants, as part of post-go-live support, assist users by providing short training sessions, guidance, and expert knowledge for a defined period. During this time, the system is handed over to users to ensure they feel confident in continuing to use it independently. This support is provided both onsite and remotely, via phone or remote connection.
This period is critical and requires efficient issue management and resolution. Any prior oversights or insufficient training may make this phase very exhausting for all participants.
It is essential that the Client and Partner Project Managers enforce the use of the Support Portal for submitting all requests and issues.
At the same time, the system is handed over to post-go-live support, under the conditions defined in the service agreement.