A short, evidence-based assessment against your own Agile instance. Volumes, structure depth, custom classes, flex-field usage, data quality and vault size measured rather than estimated, so the plan that follows is built on numbers.
Item count is the number everyone quotes and the one that predicts effort least well. What actually drives an Agile programme is configuration and data condition, and neither is visible from the outside.
Two instances with the same item count can differ by a factor of three in effort. One has a handful of standard subclasses and clean manufacturer data; the other has forty subclasses accumulated over fifteen years, Page Two and Page Three fields carrying business-critical data under names like Text01, and four spellings of the same manufacturer. Only the second one has a discovery problem, and only profiling reveals which you have.
Attachments are the other multiplier. A vault of a few hundred gigabytes is a detail; a multi-terabyte vault with large CAD-related files sets the schedule for the whole programme, because extraction, transfer, integrity checking and upload all scale with it and none of them can be compressed by adding people.
The assessment measures both, plus the data-quality issues that will otherwise surface during a cutover rehearsal: orphaned components, duplicate manufacturers, invalid references, attributes populated inconsistently across revisions, and overlapping effectivity ranges.
A fixed set of deliverables, not a slide deck of generalities.
Every object family in scope with its measured volume, so scope conversations are about real numbers.
Which attributes are populated, on which classes, with what cardinality, including the flex fields nobody has documented.
The specific issues found, quantified, each with a proposed remediation route and an owner.
A recommended boundary between what belongs in the new PLM and what belongs in the archive, with volumes attached.
Phases, durations and the dependencies that will actually constrain the schedule, including vault throughput.
What could go wrong, how likely it is against your data, and what would reduce it.
Two to four weeks, mostly read-only, with limited demand on your team.
Read-only access to the Agile database and vault, or to a replica, plus a short workshop on target intent and retention expectations.
Automated profiling across configuration, volumes, documents and data condition, producing measured figures rather than samples.
Working sessions with engineering, quality and procurement on what the flex fields mean and which history genuinely has to move.
The migrate-or-archive boundary drawn with volumes attached, and the mapping effort estimated against measured complexity.
Deliverables handed over and walked through, including the risks and what would move the plan in either direction.
Assessments rarely confirm the original assumption. In most engagements at least two of the findings below move the scope, the schedule or the shape of the programme.
That is the point of running one: the cheapest time to discover any of these is before the plan is committed rather than during rehearsal two.
Three ways to decide how big this is.
Fast, free and routinely wrong, because it prices the number that predicts effort least well.
Every surprise lands when the plan is already committed and the mitigation options have narrowed.
Two to four weeks and a set of measured numbers, against a programme that typically runs twelve to twenty-four.
Configuration, volumes, documents and data condition. Configuration means Agile version, the classes and subclasses actually in use, Page Two and Page Three field usage by class, and custom relationship types. Volumes means items, revisions, structure headers and components, manufacturers, manufacturer parts, AML entries and change orders by type. Documents means vault size, file count, type distribution and how attachments spread across items, revisions and changes. Data condition means the specific quality issues that would otherwise surface during a cutover rehearsal.
Two to four weeks from connection to report. Most of the elapsed time is profiling and the interpretation sessions rather than waiting on your team; the demand on your side is typically a few hours from engineering, quality and procurement, plus whatever your process requires to grant read-only access. Larger estates with multiple Agile instances sit at the longer end.
Read-only access to the database and vault, and a replica is preferred where one exists. Nothing is written, no schema changes are made and no triggers are added. Where production access cannot be granted at all, the assessment can run against a recent restored copy, with the caveat that data-condition findings then reflect the copy's date rather than today's.
The assessment still pays for itself, because most of what it measures is source-side and target-independent: what you have, in what volume, in what condition, and which parts of it genuinely need to move. That evidence improves the target decision rather than depending on it. Target-specific mapping effort is the one part that firms up once the target is chosen.
It gives you the inputs that determine cost and an indicative range, rather than a fixed price on day one. Cost on an Agile programme is driven by mapping complexity, data-quality remediation and attachment volume, and all three are measured during the assessment. That is what turns an estimate with a wide band into one you can plan against.
That is the point of it. It is deliberately scoped as a short, self-contained engagement with defined deliverables so it can inform the decision rather than assume it. A common outcome is a change of shape rather than a go or no-go: organisations frequently discover that far less has to move into the new PLM than they assumed, and that the sensible split is a smaller migration plus a larger archive.
Two to four weeks, read-only against your own instance, with an object inventory, attribute map, data-quality register and a migrate-or-archive recommendation at the end.