Migration field notes.
Viewpoints and lessons from the field on industrial data migration: classic pitfalls, methodology and best practices.
- LOG_13
Data migration plan: the four lines everyone leaves out
Most migration plans are complete on paper and still miss the four things that decide the date: arbitration time, the delta window, the rollback call, and how many full passes the calendar actually allows.
Read the article → - LOG_12
Data migration strategy: the decision that is not the cutover
Big bang, phased and trickle describe how you switch over. The structural decision comes earlier: do you carry the source data model into the target, or rebuild for it. That one commits you for a decade.
Read the article → - LOG_11
Data migration testing: what a passing test actually proves
A load report showing 100% success is not a test result. It says the chain ran, not that the data is right. Four levels of testing, and what each one actually establishes.
Read the article → - LOG_10
Legacy data migration: reading meaning nobody wrote down
The documentation describes the system as it was in 2011. Everything since lives in the data itself, in overloaded fields and codes whose meaning drifted without anyone changing the column. Here is how to read it back.
Read the article → - LOG_09
SAP data migration: where the standard toolchain stops
The SAP Migration Cockpit handles the standard case well, and the standard case is not your case. Knowing exactly where the templates stop is what separates a two-month estimate from a nine-month one.
Read the article → - LOG_08
Validating a migrated BOM: opening the assembly is the test
A PLM load report says every object arrived. It says nothing about whether the assembly opens. On a product structure, the only acceptance test is an engineer resolving the top-level model in the target system.
Read the article → - LOG_07
How an asynchronous ETL chain works: optimization and flexibility
A synchronous ETL chain processes in batches and stops at the first blocker. By decoupling extract, transform and load, each record moves at its own pace, and the migration stops being a bottleneck.
Read the article → - LOG_06
The origins of MigQuest: a failed name, some quests, and a phoenix
Before MigQuest, there was DataMig. And before the phoenix, there was a team that already carried its name. The short story of a brand born from one simple idea: a migration is a rebirth.
Read the article → - LOG_05
The real cost of a failed migration
Documented migration fiascos run into tens, sometimes hundreds of millions. Against that, the cost of dedicated expertise. The real question is the price of going without it.
Read the article → - LOG_04
Windchill to 3DEXPERIENCE: native tools move your files, not your data
Migrating one PLM to another isn't copying files from one side to the other. It's rebuilding a structure. And that's exactly what native tools can't do.
Read the article → - LOG_03
S/4HANA is not ECC with a new name
Moving to S/4HANA changes the schema under your feet. Migrating your data without understanding that means loading valid content into a model that no longer expects it.
Read the article → - LOG_02
Data audit: the phase everyone overlooks
Before writing a single line of migration code, you have to face the data as it really is. It's the least spectacular phase, and the most decisive.
Read the article → - LOG_01
Why so many ERP migrations fail in production
Migrations almost never derail because of the target system. They derail because of the source data, and the moment its true state is discovered.
Read the article →