Moving from Dynamics AX to D365: A Roadmap for Energy Companies

One of the first decisions in an AX-to-D365 initiative is how the organization defines the project.

If it is treated primarily as a technical upgrade, the natural tendency is to reproduce the existing environment: the same processes, reports, integrations and customizations, implemented on newer technology.

That can miss much of the opportunity.

ERP environments evolve over many years. Processes change. Organizational structures change. New systems are introduced. Reports proliferate. Customizations that once addressed legitimate requirements may no longer be necessary.

Before determining what moves to Dynamics 365, organizations should understand how the business operates today and what it will require tomorrow.

For energy companies, that assessment should include both standard enterprise processes and industry-specific requirements across finance, capital programs, joint ventures, operations, procurement and reporting.

Long-running AX environments can accumulate significant complexity.

That may include custom code, third-party solutions, integrations, reports, workflows, data interfaces and manual processes that have grown around the ERP platform.

Not everything deserves to move forward.

A structured discovery process should establish what exists, why it exists, who depends on it and whether the underlying requirement still applies.

A useful classification is:

Retain — the requirement remains valid and the existing approach continues to make business sense.

Replace — Dynamics 365 or another modern platform capability can address the requirement more effectively.

Redesign — the business requirement remains, but the process should be approached differently.

Retire — the functionality, report, integration or customization is no longer required.

This analysis helps prevent the new environment from inheriting unnecessary complexity simply because it existed in AX.

Energy organizations frequently operate with requirements that do not fit neatly within a generic ERP implementation model.

Depending on the organization, these can include joint venture accounting, authorization for expenditure, capital and project structures, equipment-related processes and specialized financial reporting.

These requirements should not be treated as exceptions discovered late in implementation.

They should be identified during solution design and considered alongside the core Dynamics 365 architecture.

For organizations using EnergyCONNECT, modernization also requires understanding how existing energy-specific functionality maps into the target Dynamics 365 environment.

This is where industry knowledge becomes particularly important. A technically valid configuration is not necessarily an effective operating solution if it does not reflect how the energy business actually works.

Customization is often one of the most consequential areas of an AX modernization.

Existing customizations may represent genuine business requirements. Others may exist because older versions of AX lacked functionality that is now available through Dynamics 365, related Microsoft technologies or updated business processes.

The wrong question is: "How do we migrate this customization?"

A better question is: "What business requirement caused us to build this, and what is the best way to address that requirement today?"

That distinction can materially change the target architecture.

Every customization carried forward introduces something that must be designed, developed, tested and supported. Modernization therefore provides an opportunity to deliberately evaluate the value and necessity of each one.

The goal is not zero customization. The goal is intentional customization.

Data migration and integration are sometimes treated as technical workstreams that can be finalized after functional design.

In complex ERP transformations, that can create problems.

An AX environment may exchange information with operational applications, banking platforms, reporting tools, production systems, procurement applications, document-management solutions and other enterprise technologies.

Those connections influence solution design.

The same is true for data.

Organizations need to determine what historical information should migrate, how data quality issues will be handled, how opening positions will be established and what information can remain available through archival or reporting approaches.

Migration rehearsals should also occur early enough to expose problems before cutover.

Data and integration are not simply deployment activities. They are fundamental parts of the transformation architecture.

ERP testing should demonstrate that the organization can operate successfully — not simply that individual configurations work.

That means testing complete business scenarios across functional areas and connected systems.

For an energy organization, a single business process may cross several parts of the environment before reaching the general ledger or management reporting.

Testing therefore needs to consider end-to-end business processes, integrations, migrated data, security and roles, financial outcomes, industry-specific functionality, reports and reconciliations, and exception scenarios.

User acceptance testing is particularly important because it brings business ownership into the validation process.

Testing should not be viewed as the final checkpoint before deployment. It should progressively build confidence in the solution throughout implementation.

Go-live is where technology, data, people and operations converge.

A strong cutover plan identifies what must happen, when it must happen, who owns each activity, what dependencies exist and how readiness will be evaluated.

For an AX-to-D365 transformation, cutover may involve final data migration, reconciliation, integration transitions, user access, business communications, operational readiness and decisions about when legacy transactions stop and the new environment begins.

These activities require coordination across the organization — not only within the project team.

A technically ready system does not automatically mean the business is ready to operate it.

The implementation does not end when Dynamics 365 becomes operational.

Users need support. Issues need prioritization. Processes may require adjustment. Reporting requirements continue to evolve. Additional opportunities for optimization emerge once the organization is operating in the new environment.

Organizations should determine before deployment how the environment will be supported and governed after go-live.

That includes ownership of enhancements, issue management, release planning, security, integrations and ongoing improvement.

Modernization should establish a platform the organization can continue to develop — not simply complete a migration project.