We do not publish a price, because a price quoted before profiling is a guess wearing a number. What we can be precise about is which variables move the cost, by how much, and how to measure them against your own instance in a few weeks.
Two Agile instances with identical item counts routinely differ by a factor of three in effort, because the cost lives in configuration, data condition and attachment volume rather than in row counts.
Mapping complexity dominates. A clean instance with standard subclasses and few custom attributes maps quickly. An instance with forty accumulated subclasses and Page Two and Page Three fields carrying undocumented business data needs discovery work before mapping can even start, and that discovery is calendar time as much as effort.
Data condition is next. Duplicate manufacturers, orphaned components, invalid references and inconsistent attribute population each generate remediation work, and each generates it repeatedly across cycles if the fix is not made at source or encoded as a rule. Profiling quantifies this, which is the difference between a contingency and an estimate.
Attachment volume sets the schedule independently of everything else. A vault in the hundreds of gigabytes is a detail; a multi-terabyte vault with large CAD-related files drives extraction, transfer, verification and upload effort, and none of those compress by adding people. History scope then multiplies the lot: migrating ten years of revisions and redlines is a different programme from migrating current state.
Six areas that account for most of the effort on a typical programme.
Short, fixed and the best-value phase in the programme, because every later estimate depends on its output.
Usually the largest single line, driven by custom subclasses and undocumented flex fields rather than by volume.
Proportional to what profiling finds. Unquantified, it becomes the contingency that gets spent.
Extraction, transfer, verification and upload, scaling with vault size rather than with item count.
Each full-volume cycle costs real effort. Fewer cycles means lower cost and higher cutover risk; the trade is explicit.
Frequently forgotten at budget time, and frequently the line that pays for the rest in avoided licence and infrastructure cost.
Four weeks to a figure with evidence behind it.
Configuration, volumes, vault size and data condition measured against your own Agile system rather than a benchmark.
What migrates and what is archived, with volumes on each side, since this single decision moves cost more than any other.
Effort estimated against the measured attribute count and the actual quality findings, not against an average.
Rehearsals agreed explicitly as a risk decision with a cost attached, rather than assumed.
Licence, infrastructure, storage and support costs released by retiring Agile, set against the programme cost.
If you want a quick sense of where a programme will land before any profiling has run, these are the six questions worth asking. Each one moves the estimate materially.
None of them is about item count, which is the question most commonly asked first.
With very different amounts of evidence behind them.
Fast, free and routinely wrong, because it prices the variable that predicts effort least well.
Honest about the uncertainty and hard to govern. The uncertainty is not reduced, only transferred.
Two to four weeks of measurement producing a scoped figure with the drivers quantified and the assumptions stated.
It depends on six measurable things, which is why we profile before quoting rather than publishing a price. Mapping complexity, driven by custom subclasses and flex-field usage. Data condition, driven by duplicates, orphans and invalid references. Attachment volume. History scope, meaning how much moves rather than being archived. Cycle count. And whether archival and decommissioning are in scope. A two to four week assessment measures all six against your instance and produces a scoped figure with the assumptions stated.
Because it would mislead. Two instances with the same item count routinely differ threefold in effort, since the work lives in configuration and data condition rather than in rows. A per-item price either has to be set high enough to cover the worst case, which overcharges clean instances, or it gets revised upward once the real complexity emerges, which is worse than not quoting.
Mapping complexity, and specifically undocumented Page Two and Page Three attributes on custom subclasses. Each one needs discovery, a business decision about what it means, a target decision about where it goes, and then testing. An instance with forty custom subclasses and heavily used flex fields can carry several times the mapping effort of a standard instance with the same number of items.
It usually reduces the total, sometimes substantially. Migration effort scales with what you move, so a larger archive means a smaller migration, fewer objects through every rehearsal cycle and a shorter cutover window. Archiving carries its own cost, but per record it is far lower than migration, and it also reduces the ongoing cloud PLM licensing and storage you pay to hold history you never edit.
Everything the Agile environment consumes once it is retired: application and database licences, application and database servers, vault and database storage, backup and DR capacity, the patching and access-review effort, and the specialist time that keeps an ageing stack alive. For a long-running Agile instance that offset is frequently the strongest part of the business case, and it should be modelled explicitly alongside the programme cost rather than mentioned in passing.
Yes, and phasing by product line is the usual route. It spreads spend across financial periods and reduces risk per event, at the cost of a coexistence period that needs integration and governance. That coexistence has a real cost of its own, so phasing is a genuine trade rather than a free saving, and it is worth modelling both shapes before committing.
Start with the assessment. Two to four weeks against your own instance, and you get a scoped estimate with the drivers quantified and the assumptions written down.