{"id":3667,"date":"2005-06-08T09:31:16","date_gmt":"2005-06-08T16:31:16","guid":{"rendered":"https:\/\/www.caddmanager.com\/CMB\/?p=3667"},"modified":"2019-07-01T09:39:32","modified_gmt":"2019-07-01T16:39:32","slug":"migration-madness-part-five","status":"publish","type":"post","link":"https:\/\/www.caddmanager.com\/CMB\/2005\/06\/migration-madness-part-five\/","title":{"rendered":"Migration Madness – Part Five"},"content":{"rendered":"
This entry is part 5 of 6 in the series Migration Madness<\/a><\/div>\n

When to make the move<\/strong><\/h2>\n\n\n\n

I have gotten a few comments back from readers about the decreased span of time between software versions put out by Autodesk.  If you review the AUGI survey on Migration at http:\/\/www.augi.com\/surveys\/archive\/cadmgmtsurvey-0505.pdf<\/a> you will see that 67% of the respondents would agree that releases are happening too fast.  Even so, a majority (54%) of users on subscription migrate as the software ships or within 3 months.  Non-subscription users migrate every few years. This is a huge gap. Let\u2019s examine some of the reasons for migrating and when it should be considered.
<\/p>\n\n\n\n

Timing<\/strong>
<\/p>\n\n\n\n

The timing of the move may help you to get the best results.  So move when it makes sense:
<\/p>\n\n\n\n

Before the next project starts.  This may be an opportune time to get the most impact of the upgrade to productivity.  Appling the new tools to the next project may give you the boost in effectiveness needed to cushion the strain of moving.
<\/p>\n\n\n\n

After Training. This may be the most opportune time to make a move forward.  Training should be done right before you deploy. Keeping the concepts and methods fresh in the mind of the users will help.
<\/p>\n\n\n\n

When demanded.  Often the client or project will demand that you make a move.  To get a project or contract many owners or Project Managers will agree to use a specific version of software or a tool that is only available in a newer release.  You may be forced into making the change.

<\/p>\n\n\n\n

Where to start<\/strong>
<\/p>\n\n\n\n

Start the migration with your best users.  Let them have the software earlier. Give them Beta software if need be.  Let them test it out in a real world environment, but not on real project files.

<\/p>\n\n\n\n

You have a choice to make.  Do you migrate a small team or the whole office?  This would most likely be your call. Get some input from other firms that have done the migration already.  I would recommend that you take this tack\u2026 The bigger the firm \u2013 the smaller the migration group. Smaller groups are easier to manage.  It is easier to fix problems and learn lessons to apply to the larger group.

<\/p>\n\n\n\n

Line up support before you start.  Get Management behind you before you make any move at all.  Do not move until they understand the issues and are supporting your efforts.  Don\u2019t forget about Vendors. They have special knowledge about the tools you use.  How they interact with other tools. How they interact with hardware. They have had other clients that have been down this road before.  Tap into them.
<\/p>\n\n\n\n

What to pack and how to pack it<\/strong><\/h2>\n\n\n\n
  1. Make a list of what you think you need to get the job done and check it twice.  Use this list to think through the issues. Include the following:
    1. Your custom tools and programs<\/li>
    2. Your blocks<\/li>
    3. Your Standards<\/li><\/ol><\/li>
    4. Review the list for areas of concern and modifications needed.  Think about what would impact the users if it is not prepared beforehand.  What will they need to stay productive? What will they miss the most?<\/li>
    5. Copy only your best guess at the files they will need.  Place them in a new area for the new release. You will have a mixed house of old tools and new tools.  Old files and new files. Make sure that you keep them separate. Edit the new files and test them fully.  Let your best users test them. Get second opinions.<\/li>
    6. Migrate only the needed items as they are needed.  The point is to jettison the old stuff as you move forward, leaving to old files behind unless they are needed.<\/li>
    7. Prep the machines before the move.  Load and test all of the software. Keep notes of what works and what doesn\u2019t.  Remember that each user may need a differing set of software. Each blend of tools needs to be tested.  Define a standard platform for the install. Create a step by step list of loading the tools. In what order?  What custom configurations? What personal setting will be needed? How do you migrate the old setting?<\/li>
    8. Prep the Users
      1. Training<\/li>
      2. Your Support teams \u2013 either tech support personnel or users who can help out.<\/li>
      3. Hand holding \u2013 don\u2019t overestimate the users understanding of the process.<\/li><\/ol><\/li>
      4. Prep Management.  Let them know that you are moving far in advance of the move itself.  Keep them informed as the date approaches. Provide information about the impact.  Provide updates as the progress moves ahead.<\/li><\/ol>\n\n\n\n

        By planning well and executing with effectiveness, you can make a great move.<\/p>\n
        ","protected":false},"excerpt":{"rendered":"

        This entry is part 5 of 6 in the series Migration Madness<\/a><\/div>

        When to make the move I have gotten a few comments back from readers about the decreased span of time between software versions put out by Autodesk.  If you review the AUGI survey on Migration at http:\/\/www.augi.com\/surveys\/archive\/cadmgmtsurvey-0505.pdf you will see that 67% of the respondents would agree that releases are happening too fast.  Even so, […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[13],"tags":[],"series":[95],"class_list":["post-3667","post","type-post","status-publish","format-standard","hentry","category-cad-management","series-migration-madness"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.caddmanager.com\/CMB\/wp-json\/wp\/v2\/posts\/3667","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.caddmanager.com\/CMB\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.caddmanager.com\/CMB\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.caddmanager.com\/CMB\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.caddmanager.com\/CMB\/wp-json\/wp\/v2\/comments?post=3667"}],"version-history":[{"count":1,"href":"https:\/\/www.caddmanager.com\/CMB\/wp-json\/wp\/v2\/posts\/3667\/revisions"}],"predecessor-version":[{"id":3668,"href":"https:\/\/www.caddmanager.com\/CMB\/wp-json\/wp\/v2\/posts\/3667\/revisions\/3668"}],"wp:attachment":[{"href":"https:\/\/www.caddmanager.com\/CMB\/wp-json\/wp\/v2\/media?parent=3667"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.caddmanager.com\/CMB\/wp-json\/wp\/v2\/categories?post=3667"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.caddmanager.com\/CMB\/wp-json\/wp\/v2\/tags?post=3667"},{"taxonomy":"series","embeddable":true,"href":"https:\/\/www.caddmanager.com\/CMB\/wp-json\/wp\/v2\/series?post=3667"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}