Agile programmes that finish on schedule tend to share the same handful of habits, and they are not the ones teams expect. Profile before mapping. Archive more than feels comfortable. Load in dependency order. Rehearse at full volume. Reconcile everything.
The difference between a programme that lands and one that drags is rarely tooling or budget. It is a small set of decisions taken early, each of which looks optional at the time.
Profile before mapping. Mapping from the data dictionary maps fields that nobody populates and misses the ones that carry the real meaning. Profiling reports actual usage by class, with fill rates and value distributions, which usually removes a substantial share of the attributes from scope immediately and focuses the business conversation on what is left.
Archive more than feels comfortable. The instinct is to migrate everything, because deciding what to leave behind feels like a risk. It is the more expensive instinct. Carrying a decade of superseded revisions and closed changes into a cloud PLM costs licensing, load time and daily noise, and an archive answers the same questions for a fraction of the price.
Then: load in dependency order, rehearse at full volume rather than on a sample, and reconcile every object family rather than spot-checking a few parts. None of these is clever. All of them are routinely skipped, and skipping them is what turns a twelve-week programme into a twenty-four week one.
Each one costs something early and saves more later.
Every number in the plan traceable to a profiling result rather than to an estimate from item counts.
Sign and version it, then track changes as amendments, so cycles stay comparable and differences are explainable.
Duplicate manufacturers and orphaned components are cheaper to fix in Agile than to carry through every cycle as a transformation rule.
Flex-field meanings, retention obligations and item numbering each need a person, not a committee, with a date.
Size it in week one and plan the bulk transfer ahead of cutover, because it cannot be compressed by adding people.
Spot checks find obvious breakage. Only reconciliation by family finds the ten thousand records that were never submitted.
Where each one earns its keep.
Profile rather than survey. Name the decision owners. Size the vault before anyone commits to a date.
Work from measured attribute usage, decide the exceptions explicitly, then sign and version the result.
Encode dependency order into the load sequence, and put cleansing rules in the transformation layer rather than in spreadsheets.
Full volume, three times, with the reconciliation pack produced each time exactly as it will be at cutover.
Gate between stages, reconcile every family, then archive the remainder and retire the source.
Each of these costs something early and is routinely skipped under schedule pressure. Each one, skipped, shows up later as rework that costs several times what it saved.
They are listed in rough order of how often we see them omitted.
Common, expensive, and entirely predictable.
Produces a mapping for fields nobody uses and misses the flex fields carrying the real data.
Pays cloud licensing to hold a decade of superseded revisions, and slows the new system for every user, every day.
Proves the logic works and tells you nothing about whether the load fits in the window.
Profiling before mapping. Everything downstream depends on knowing what is actually in the instance: which classes and subclasses are in use, which attributes are genuinely populated and on what proportion of records, how deep the structures go, how large the vault is, and what condition the data is in. Mapping built on the data dictionary rather than on measured usage maps fields nobody populates and misses the flex fields that carry the business-critical values.
Less than most teams first assume. What operations genuinely need is current released revisions, live structures, current approved sources and open changes. Superseded revisions, closed changes, retired products and their documents are better preserved in an archive, where they remain searchable, cost a fraction to hold and do not slow the new system. Migrating everything is the expensive instinct, and it is the default only because deciding what to leave behind feels risky.
Both, split by who can fix it. Issues with a clear owner in the business, such as duplicate manufacturer records or orphaned components, are cheaper to fix at source in Agile, because the fix is made once rather than re-applied as a rule in every cycle. Issues that are structural, such as normalising values or resolving overlapping effectivity, belong in the transformation layer where the rule is versioned and applied identically every time.
At least three full-volume rehearsals before cutover. The first finds dependency problems and produces the first honest durations. The second proves the fixes and the attachment strategy at real volume. The third is a clean run against the clock, producing the reconciliation pack exactly as it will be produced on the night. If the third rehearsal is still eventful, the cutover date is wrong.
Size the vault in week one and treat it as the critical path until proven otherwise, because it usually is. Decide scope deliberately rather than defaulting to all of it: not every historical attachment needs to be in the new PLM, and many belong in the archive. Move the bulk ahead of cutover so only a delta is handled in the window, and verify checksums on arrival rather than assuming a transfer of that size completed cleanly.
Give them decisions rather than status. Business input is concentrated in a few high-value places: what the flex fields mean, where the migrate-or-archive boundary sits, whether item numbers change, and which retention obligations apply. Each is a decision with a name and a date against it. Programmes that ask the business for general engagement get general attention; programmes that ask specific people for specific decisions get answers.
Send us the plan. We will tell you where it looks solid, which assumptions we would test first, and what we would expect profiling to change.