Transition and cutover

How an IFS-to-D365 programme actually runs: estate discovery, the eight migration waves and their dependency order, testing strategy, mock cutovers, IFS-specific traps — EAM depth, mixed-mode manufacturing, project-driven production, and site/company structures — and the seven programme stages from orient to stabilise.

What you will be able to do

• Inventory an IFS estate across all five customisation surfaces before the design phase begins
• Sequence data migration waves to satisfy every dependency
• Design a four-corner reconciliation that meets audit requirements
• Identify the IFS-specific traps and make the corresponding architecture decisions before build begins

Introduction

An IFS-to-D365 programme is a full-system replacement, not a feature migration. Every business process the organisation runs through IFS must be redesigned, tested, and cut over to D365 — including IFS's deepest capabilities in EAM, project management, and mixed-mode manufacturing, which typically exceed a naive D365 setup and require…

IFS estate discovery: what to inventory

Before design begins, the IFS estate must be fully inventoried. Estate inventory work runs in parallel with the initial architecture workshops in the Discover phase.

Programme stages: orient through stabilise

The programme runs through seven sequential stages. The stage names are used consistently throughout this learning site:

Data migration waves and dependency order

The eight-wave structure is dependency-driven. Each wave's output is a prerequisite for the next wave's load:

Testing strategy and mock cutovers

System Integration Testing (SIT) — functional testing of the configured D365 solution against the agreed design. SIT tests each process end-to-end (procure-to-pay, order-to-cash, maintenance work order, project billing) in a controlled environment with test data. SIT is run by the programme team against functional test scripts.

IFS-specific traps and architecture decisions

Four IFS-specific situations require explicit architecture decisions before the Build phase begins. Each has proven to be a programme accelerator when decided early and a source of significant rework when decided late.

Target stack and programme vocabulary

The playbook is explicit that the move is from an IFS-centred estate to a modular Microsoft cloud estate, not from one monolith to another. The target stack should be read by layer:

Knowledge check

Summary

An IFS-to-D365 programme is manageable when its distinctive characteristics are understood and addressed before the build phase begins. IFS's depth in EAM, projects, and mixed-mode manufacturing creates scope that a conventional ERP migration playbook does not fully anticipate.