Data migration at one of Sweden's largest retailers – PDM v3, an 8‑step method and AI agents

Right now I'm leading the data migration in a large-scale business transformation at one of Sweden's largest retailers – 50+ stores plus e‑commerce, with an ERP migration from Microsoft Dynamics 365 Finance & Operations (F&O) to Dynamics 365 Business Central. The migration spans many data objects and business domains: members, products, suppliers, campaigns, sales history, stock balances and more.

This is the kind of engagement where structure is the difference between a calm go‑live and chaos. Here's how I work.

The framework: PDM v3 and a refined 8‑step method

I lean on the PDM v3 governance methodology, but the core of how I work is an 8‑step method I developed myself and have refined over the years of hands-on migration work. The idea is simple: every data object is taken through the same eight steps – from suppliers to loyalty points. That makes the work repeatable, measurable and easy to track in an overview matrix where each object's status is visible step by step.

1. Identify scope – decide which subset of data from the legacy system should actually be migrated.
2. Understand the data models – analyse the source model and the target model.
3. Map the fields – connect fields between source and target based on that analysis.
4. Build the migration script (ETL) – Python scripts that extract data from the source (Extract), transform it according to mapping rules and quality checks (Transform), and produce import files for the target system (Load).
5. Data cleansing – for each field, decide: clean it in the source, handle it in the transform step, or remediate after go‑live?
6. Test migration – the first load into a DEV environment, where business key users verify the result.
7. Broader test – a larger test migration in a TEST environment, where more of the business validates the migrated data.
8. Cutover planning – identify every activity for a correct migration at go‑live, including the sequence of bulk and delta loads around the go‑live moment.

The order is recommended, but in practice the steps often run in parallel and sometimes out of sequence depending on the business's availability. One object can be in test migration while another is still being mapped.

Steps 6 and 7 are owned by the business

One thing I want to be clear about: in steps 6 and 7, it's the business that validates – not the technology. AI and automation can load the data as many times as you like, but the question "is this correct?" has to be answered by people who know the business – the ones who immediately spot when a member record, a price or a campaign looks wrong. That's why step 6 runs in a DEV environment and step 7 in a TEST environment, with business key users in the driving seat. That's where trust in the data is built.

The AI workflow: several agents handling the repetitive work

What makes this migration faster than earlier projects is an AI‑assisted workflow I built. I've built my own MCP servers that connect the agents to the various databases, so they can read and understand the data models in the source and target systems. And with Hermes I give the agents feedback, so they improve bit by bit. By letting the agents handle the repetitive, time‑consuming work, I free up time for what genuinely needs me: the dialogue with the people in the organization. Specifically, they take care of:

• Mapping – proposing field mappings between source and target based on the data models and naming conventions.
• Profiling – mapping the source data, measuring completeness and flagging anomalies early.
• Verification – checking transformed data against quality rules and reconciling source against target.
• Testing support – generating test inputs and compiling discrepancies ahead of business review.

The agents come with proposals – not finished answers, and they don't do the whole job. Every mapping, rule and anomaly is reviewed and validated by me and the business before it's used. The point isn't to replace judgement, but to free up time for judgement: when the agents handle mapping proposals, profiling and reconciliation, we can spend our energy where it matters most – the business rules, the edge cases and the data‑quality decisions.

Automation scales the work. The method keeps it under control. The business decides whether it's right.

In summary

Large-scale retail migration isn't about a tool – it's about discipline made systematic: a proven methodology (PDM v3), the same eight steps for every data object, and automation that takes the repetitive work without taking ownership of validation away from the business. That's how a migration with hundreds of moving parts can go live calmly – without stress or nasty surprises.

Facing a similar transformation? Get in touch – I'm happy to share more about how the method could apply at your organization.