WNC upgrade Vs Migration

[rnoah]

All,

Wanted to advice with you about interesting situation i've faced lately.

one of our customers would like move into windchill 11.1 M030, from Windchill 10.2 M030.

we proposed them the "regular" method - using upgrade process.

however, they are more interested in "Migration". meaning installing Windchill as Vanila, define the system from scratch ( product, revision scheme, workflow, permission, security, etc ) and then use WBM in order to load the data from current system.

The main purposes of this are:

1. review and updating all company standard and regulation into the system.

2. dumping the "garbage" in the system ( they use it for more that 12 years ).

Do you see any REAL benefit from the "Migration" process ? to my view all the things they would like to achieve are possible & easier to do before/after the upgrade is done. that way you avoid the complexity and risk involved.

What do you think about the situation ? how would you handle it ?

[mmeadows-3]

This is a relatively common request and the listed reasons are valid.  Sometimes getting to a configuration that can be understood and managed going forward is justification enough.  Upgrade brings along all history, including/especially:

• Objects that can't be deleted (e.g. contexts, domains, etc.)
• Items that can't be purged/deleted or purged easily (e.g. CAD Data).
• Legacy business configurations and configuration changes over time that don't match the current or desired business configuration (e.g. revision/numbering schemes, context/folder structures, etc.).

Business configuration cleanup can be surprisingly difficult.  For example, reordering or swapping out revision series isn't trivial and may require customization.

Early configuration mistakes, mergers, and lessons learned over time can make cleanup a lengthy and tedious process.  Just access permissions cleanup is a lengthy process that can leave confusing legacy artifacts (e.g. deprecated folder, context, shared team domains) for future administrators.

In most of these cases, it is easier to start from a known position (new installation) and define new/clean revision series, contexts, access permissions, etc. that meet current business requirements than to try to reverse engineer and alter an existing configuration.

That said, selecting the correct path depends on the current system configuration, the desired changes, and the overall cost to get there.  Gather the as-is and to-be configurations and validate viability of the path and results before dismissing either solution.

Hope this helps.