The conversion process needs to be tested and perfected somehow.  This might be done through some sort of prototyping or it might be done first with a very small number of users that have more flexibility to work around any problems.

Limoncelli supports a one-some-many approach for rollouts.  The rollout starts with one server with very limited usage or a single desktop or some other relatively isolated resource.  Hopefully, these resources are almost entirely used by people such as sys admins.  Then when it is working for this resource the rollout should be implemented for a slightly larger test group.  These users are also likely to be very capable of working around any shortcomings of the conversion on their own.  There is almost inevitable debugging for a large variety of reasons.  Then the rollout should be implemented for increasingly larger groups that increase in size with each successful step.

While sys admins want their rollouts to be seamless and hopefully invisible to the end users, eventually the end users need to know about them.  The end users need to know how the rollout will take place and how it will affect them.  For example, if the conversion requires

• service outages
• changes to end user's machines
• visits to offices
• etceteras directly affecting end users

you need to make sure you directly interact with these users to let them know the specifics.  By doing this you are also likely to encounter end users that make use of the services in ways you never anticipated.  This is often important even if the conversion occurs seamlessly.

It is almost always important to minimize intrusiveness in order to cause the fewest interruptions to end users and services as reasonable.  The sys admins need to seriously think about how implementation durations can be shortened.  They also need to try and schedule these interruptions to have the least impact on continuing operations.  An end user that is interrupted just once for a short period of time is very likely to prefer it to anything other than no interruptions.

It is also important to be prepared for the eventualities of impacting end users use methods.  Will they need training?  How comfortable are they with the new changes?  Do the changes improve their productivity?

Another major issue to consider can be described as whether to perform particular tasks in pillars or layers.  Limoncelli describes working in layers as performing the task for all of the customers before moving to the next task and doing that for all of the customers.  The pillars approach is defined as performing all of the tasks for each customer and then moving to the next.

For many sorts of conversions, the pillars approach is better because it is likeliest to minimize intrusiveness to the end users.  Each end user is affected at some very specific points in time.  If it took long the conversion would never be completed for everyone.  Tasks that are not intrusive to the end users, such as creating accounts on a server, can be more appropriately performed in layers.  With a pillars approach you may be able to schedule only one period with each customer rather than many small ones.  For most end users, one intrusion is preferable to many small ones.

Sites as sophisticated a major e-commerce sites can also think about such issues.  They may well desire to complete all changes on one server at a time thus never greatly reducing their site's productivity.

Flash cuts are usually considered to be total system changes done for everyone at the same time.  In almost all instances it is highly desirable to avoid these sorts of changes.  If just about anything goes wrong the changeover period will at best be just prolonged.  If there are worse problems it may be that the site is without certain essential services for quite some time.  It is usually preferable to leverage particular features of one's site to do one-some-many changes or more smoothly rollout the changeovers.

Sometimes it is important to make use of both the new and old services simultaneously to encourage users to changeover.  Allowing such adoption periods need to be handled carefully so that users do not become recalcitrant or obstreperous.  This approach is commonly used in the telephone industry when changing things like area codes.  The system users are likely to be able to use both the old and new area code for a period of time.  Even after this, the phone company may set up a message that tells a caller that the area code has changed.

Though, on the other hand, sometimes flash cuts work and are necessary. If this is going to be the case then there must be considerable planning.

As we keep mentioning in other contexts, it is important to have a backout plan.  If a conversion fails then there needs to be a way to restore the affected services to what they were before the conversion was initiated.  Sometimes this requires the sys admins to attempt to get both running simultaneously.

As always, one needs to address the issue of when to implement a backout plan assuming one has one as an option.  It is likely to be important to primarily set certain basic parameters associated with these sorts of decisions before starting the conversion.

The Icing.  In some settings it may be necessary in addition to desirable to be able to implement instant rollbacks.  How this can be implemented depends on the situation.  It is pretty much essential to leave many aspects of the old systems in place in some ways.

It can also be important to look for products and vendors that produce upgrades and enhance scalability rather than require conversions.  Some conversions can be avoided with good planning.  It is important to know the future directions of a firm as best you may when you are making purchases.

You might also be able  to avoid certain sorts of conversions by building modularity, certain types of compartmentalization, centralization or adaptive control systems.

It is also always important to remember that you are paying money to a vendor for a product.  You need to make sure you can make use of vendor support.