CRM platform migration

The problem

The client, an adult-education provider, runs an on-premises installation of Microsoft Dynamics CRM. Support for that version is ending and keeping the infrastructure running keeps getting more expensive, so the system and its data are moving to Dynamics 365, with Dataverse as the data platform in the cloud.

My role

I work on the project as a consultant from Cegeka, in a team of around eight people: Cegeka consultants and key people on the client’s side.

I have been involved from planning and analysis through to running and validating the data loads. In practice that means:

• writing the migration scripts and tools that transform the data and load it into Dataverse
• mapping the old data model onto the new one, including relationships between entities that the old system never stored explicitly
• keeping the data consistent and correct, with tests and documentation
• troubleshooting issues as they come up, and coordinating with the client and the rest of the team

Approach

Entity mapping

Entity mapping decides where each table and field of the old system goes in the new data model, or whether it is still needed at all.

Around 130 entities were in scope, covering most of the old data model. Most tables and fields mapped one to one onto entities and attributes in Dataverse; a few needed custom mapping because the two data models differ. The analysts did most of the functional mapping, and the development team turned it into the scripts and tools that load the data.

Cleansing

Cleansing fixes or removes data that does not fit the rules of the new system.

The usual suspects were duplicate records, missing mandatory fields and inconsistent formats. We handled them with a mix of automated scripts and manual review before loading. It was a small part of the overall effort, but it matters for the quality of the data in the new system.

Standard tables with built-in logic

Some of the standard Dynamics tables run built-in plugins that cannot be switched off. Those plugins expected data that our standard migration process did not provide, so imports into those tables failed.

Instead of forcing them through the standard route, we gave these tables their own: we merged some import phases so related data arrived together, and matched records on custom external IDs instead of the usual keys.

Working out contact roles

The old system did not store roles such as teacher or student directly. They had to be inferred from almost 19 rules and criteria.

I worked with the analysts on practical ways to recognise each role, then implemented the rules, wrote tests for them and documented them. To check the results, we picked a fixed set of reference contacts whose full history in the old system we knew exactly. When every reference contact came out of the migration with the expected roles, we knew the rules held.

Status

As of October 2026 the migration is still in progress, with go-live planned for later in 2026.

What I learned

Thorough mapping and cleansing before the first load pays off. When the differences between the data models are well understood and the data is clean, far fewer problems show up during the migration itself.

A small set of reference records with a known history is a reliable way to check complex rules on data you cannot inspect by hand.

Good communication between analysts, developers and the client was essential to keep the migration coordinated and to solve issues quickly.